잡 콘텐츠

Zuul 잡은 Ansible 플레이북으로 구현됩니다. Zuul은 잡에 사용될 저장소를 준비하고, 필요한 Ansible 롤을 설치한 후 잡의 플레이북을 실행합니다. 필요한 초기 설정이나 아티팩트 수집은 해당 잡 자체의 책임입니다. 이러한 유연한 구조 덕분에 거의 모든 종류의 잡을 Zuul에서 실행할 수 있으며, 기본 제공 기능도 포함되어 있습니다. Zuul은 이를 기반으로 확장할 수 있는 표준 잡 라이브러리를 제공합니다.

작업 디렉터리

각 잡을 시작하기 전에 Zuul 익스큐터는 해당 잡과 관련된 모든 콘텐츠를 저장할 디렉터리를 생성합니다. 여기에는 Zuul이 Ansible을 구성하고 실행하는 데 사용하는 접근 불가능할 수 있는 일부 디렉터리와, 잡이 읽기 및 쓰기 가능한 work/ 하위 디렉터리 트리가 포함됩니다. 디렉터리 구조는 다음과 같습니다:

work/

잡의 작업 디렉터리입니다.

work/src/

잡을 위해 준비된 git 저장소가 포함됩니다.

work/logs/

잡의 Ansible 로그가 기록되는 위치입니다. 잡에서 생성한 다른 로그도 여기에 저장할 수 있습니다.

Git 저장소

work/src 의 git 저장소에는 잡의 required-projects 섹션에 지정된 모든 프로젝트의 저장소와, 해당 목록에 포함되지 않은 경우 큐 항목과 연결된 프로젝트가 포함됩니다. 제안된 변경 사항의 경우, 해당 변경 사항과 파이프라인 큐에서 그 앞에 있는 모든 변경 사항은 각 저장소의 대상 브랜치에 이미 병합된 상태로 준비됩니다. 변경 사항이 속한 프로젝트는 해당 변경 사항의 브랜치가 체크아웃되며, 다른 프로젝트들도 동일한 브랜치가 존재하면 해당 브랜치를 체크아웃합니다(존재하지 않으면 대체 브랜치 또는 기본 브랜치를 사용합니다). 잡이 여러 브랜치에서 작업해야 하는 경우, 이 git 저장소에서 적절한 브랜치를 체크아웃하면 Zuul이 테스트하는 예상 미래 상태를 반영하고 모든 의존성이 포함된 상태를 보장할 수 있습니다.

git 저장소에는 추측 기반 병합(speculative state)의 이전 변경 사항을 가리키는 참조가 설정된 origin 원격이 존재합니다. 예를 들어 git diff origin/<branch>..<branch> 명령을 사용하면 테스트 중인 변경 사항을 확인할 수 있습니다. 단, origin URL은 가짜 값(file:///dev/null)으로 설정되어 있어 저장소 상태를 갱신하는 데 사용할 수 없으며, 로컬 저장소는 항상 최신 상태로 보장됩니다.

저장소는 소스 연결의 정규화된 호스트 이름에 대응하는 디렉터리 구조로 파일 시스템에 배치됩니다. 예를 들어:

work/src/git.example.com/project1
work/src/github.com/project2

이는 git.example.com에 연결된 project1과 GitHub의 project2를 포함하는 잡에서 생성되는 디렉터리 구조의 예시입니다. 이러한 구조는 동일한 이름의 프로젝트 간 충돌을 방지하며, Go와 같은 일부 언어 환경에서는 이 형식의 저장소 구조를 요구합니다.

이 git 저장소는 익스큐터에 위치합니다. 대부분의 잡에서 유용하게 사용하려면 빌드 노드에도 존재해야 합니다. 표준 라이브러리의 base 잡(zuul-base-jobs documentation 참조)은 저장소를 잡의 모든 노드로 복사하는 사전 플레이북을 포함합니다. 이러한 동작을 보장하려면 항상 이 베이스 잡을 상속하는 것이 권장됩니다.

변수

Ansible에서 사용할 수 있는 변수에는 여러 출처가 있습니다: 잡에 정의된 변수, 시크릿, 사이트 전역 변수 등이 있습니다. 우선순위는 다음과 같습니다:

1. Site-wide variables

2. Job extra variables

3. Secrets

4. Job variables

5. Project variables

6. File variables

7. Parent job results

즉, 다른 변수와 동일한 이름의 사이트 전역 변수는 해당 값을 덮어쓰며, 마찬가지로 시크릿은 동일한 이름의 잡 변수를 덮어쓰고, 잡 변수는 부모 잡에서 반환된 데이터보다 우선합니다. 각 출처는 아래에서 설명합니다.

사이트 전역 변수

Zuul 관리자는 시스템에서 실행되는 모든 잡에서 사용할 수 있는 변수를 정의할 수 있습니다. 이러한 변수는 정적으로 정의되며 잡에 의해 변경될 수 없습니다. 정의 방법에 대해서는 Administrator’s Guide 를 참조하십시오.

잡 추가 변수

잡 정의에서 job.extra-vars 속성을 사용해 지정한 추가 변수는 Ansible에서 사용할 수 있지만 인벤토리 파일에는 추가되지 않습니다.

시크릿

Secrets 는 Ansible에서 사용할 수 있는 변수로도 제공됩니다. 잡 변수와 달리 인벤토리 파일에는 추가되지 않으므로, 디버깅을 위해 인벤토리 파일을 보관하더라도 시크릿이 노출되지 않습니다. 그러나 Ansible에서는 일반 변수처럼 사용할 수 있습니다. 시크릿은 변수의 집합이므로, 템플릿에서는 딕셔너리 구조로 나타납니다. 딕셔너리 이름은 시크릿 이름이며, 그 구성원은 시크릿에 정의된 개별 항목입니다. 예를 들어 다음과 같이 정의된 시크릿은:

- secret:
    name: credentials
    data:
      username: foo
      password: bar

템플릿에서는 다음과 같이 사용할 수 있습니다:

{{ credentials.username }} {{ credentials.password }}

시크릿은 해당 시크릿을 사용하는 잡 정의와 연결된 플레이북에서만 사용할 수 있습니다. 자식 잡이나 잡 변형(job variant)과 연결된 플레이북에서는 사용할 수 없습니다.

잡 변수

잡 정의에서 job.vars 속성을 사용해 지정한 변수는 Ansible 호스트 변수로 제공됩니다. 이 변수는 인벤토리 파일의 all 호스트 그룹 아래 vars 섹션에 추가되므로 모든 호스트에서 사용할 수 있습니다. 잡의 vars 섹션에 지정한 이름으로 참조하면 됩니다.

프로젝트 변수

프로젝트 정의에서 project.vars 속성을 사용해 지정한 변수는 job variables 와 동일한 방식으로 Ansible 호스트 변수로 잡에 제공됩니다. project-template 에 설정된 변수는 해당 템플릿이 프로젝트에 포함될 때 프로젝트 변수로 병합됩니다.

- project-template:
    name: sample-template
    description: Description
    vars:
      var_from_template: foo
    post:
      jobs:
        - template_job
    release:
      jobs:
        - template_job

- project:
    name: Sample project
    description: Description
    templates:
      - sample-template
    vars:
      var_for_all_jobs: value
    check:
      jobs:
        - job1
        - job2:
            vars:
              var_for_all_jobs: override

파일 변수

프로젝트 저장소에서 로드된 파일에 지정된 변수(job.include-vars 속성 사용)는 job variables 와 동일한 방식으로 Ansible 호스트 변수로 잡에서 사용할 수 있습니다.

부모 잡 결과

잡은 자신에게 의존하는 다른 잡에서 나중에 사용할 수 있도록 Zuul에 데이터를 반환할 수 있습니다. 자세한 내용은 반환 값 를 참조.

Zuul 변수

Zuul은 잡 정의에 지정된 변수뿐만 아니라 Zuul 자체에서 제공하는 일부 변수도 Ansible에 전달합니다.

파이프라인이 특정 동작에 의해 트리거되면, 파이프라인 구성에 따라 다양한 항목이 큐에 추가됩니다. 예를 들어 새로운 변경 사항이 생성되면 해당 변경 사항이 파이프라인 큐에 추가될 수 있으며, 태그가 푸시되면 해당 태그가 파이프라인 큐에 추가될 수 있습니다.

항목(item)은 일반적으로 하나의 git 참조를 의미하지만, 변경 사항 간 순환 의존성이 있는 경우에는 여러 변경 사항으로 구성될 수 있습니다.

이러한 항목에 대한 정보는 잡에서 사용할 수 있습니다. 파이프라인 큐에 추가된 모든 항목은 하나 이상의 git 참조를 나타내므로, 항목 유형에 관계없이 공통 속성이 존재합니다. 그러나 일부 속성은 참조 유형에 따라 달라질 수 있습니다. 참조의 유형은 다음과 같습니다:

Change

저장소에 대한 변경 사항입니다. 대부분의 경우 아직 저장소에 병합되지 않은 git 참조를 의미합니다(예: Gerrit 변경 사항 또는 GitHub pull request).

Branch

브랜치의 최신 팁을 나타냅니다. 변경 사항이 병합되거나 직접 푸시되어 브랜치가 업데이트되었기 때문에 큐에 추가되었을 수 있습니다. 또는 브랜치의 현재 상태를 검증하기 위해 타이머에 의해 큐에 추가되었을 수도 있습니다.

Tag

git 태그를 나타냅니다. 태그가 생성되거나 삭제되어 큐에 추가되었을 수 있습니다.

Ref

변경 사항, 브랜치, 태그에 해당하지 않는 git 참조를 나타냅니다.

단일 참조를 가진 큐 항목에 대해 빌드가 실행되는 경우, 아래 값은 비교적 단순합니다. 그러나 큐 항목이 순환 의존성에 포함된 여러 변경 사항을 나타내는 경우에는 상황이 다소 복잡해집니다. 이 경우 동일한 잡이 순환에 포함된 서로 다른 변경 사항에 대해 여러 번 실행될 수 있습니다. 이때 아래의 많은 속성(zuul.change, zuul.project 등)은 해당 빌드에 할당된 특정 변경 사항을 기준으로 설정됩니다. 반면 잡이 중복 제거(deduplicated)된 경우에는 하나의 빌드가 여러 변경 사항에 대해 동시에 실행됩니다. 이 경우 해당 값을 위해 트리거된 변경 사항 중 하나가 임의로 선택됩니다. 가능하다면 Zuul은 원래 해당 항목을 큐에 추가하게 만든 변경 사항을 사용하려고 하지만, 항상 가능한 것은 아니므로 그 동작에 의존해서는 안 됩니다.

잡 참조

위에서 설명한 잡의 선택된 참조와 관련하여 다음 변수를 사용할 수 있습니다:

zuul

zuul.project

잡의 프로젝트. 잡이 단일 변경 사항에 대해 실행되는 경우 해당 변경 사항의 프로젝트가 됩니다. 순환 의존성 큐 항목에서 동일한 잡이 서로 다른 변경 사항에 대해 여러 번 실행되는 경우, 이 값은 해당 빌드에 할당된 특정 변경 사항의 프로젝트로 설정됩니다. 잡이 중복 제거된 경우에는 잡을 트리거한 큐 항목의 변경 사항 중 하나가 임의로 설정됩니다.

다음 필드를 가지는 데이터 구조입니다:

zuul.project.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.project.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.project.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.project.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.project.src_dir

작업 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.branch

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목의 브랜치(refs/heads/ 접두어 제외)입니다.

Change

변경 사항의 대상 브랜치(refs/heads/ 접두어 제외)입니다.

zuul.change

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 식별자입니다.

zuul.message

해당 변경 사항의 커밋 또는 풀 리퀘스트 메시지를 base64로 인코딩한 값입니다. 사용 시 ansible에서 b64decode 필터를 사용하십시오.

경고

이 변수는 사용 중단 상태이며 향후 버전에서 제거될 예정입니다. 대신 zuul.change_message 를 사용하십시오.

zuul.change_message

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 커밋 또는 풀 리퀘스트 메시지입니다. Zuul이 Ansible을 실행할 때 이 변수는 !unsafe YAML 태그가 지정되어 Ansible이 값을 보간(interpolate)하지 않도록 합니다. 단, 디버깅 및 확인을 위해 빌드 워크스페이스에 생성되는 inventory.yaml 파일에는 !unsafe 태그가 포함되지 않습니다.

zuul.change_url

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 소스 위치 URL입니다. 예: https://review.example.org/#/c/123456/ 또는 https://github.com/example/example/pull/1234.

Branch

브랜치의 커밋 브라우저 URL입니다.

Tag

태그의 커밋 브라우저 URL입니다.

Ref

참조의 커밋 브라우저 URL입니다.

zuul.patchset

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 패치셋 식별자입니다. 변경 사항이 수정되면 이 값은 달라집니다.

zuul.project

항목의 프로젝트. 다음 필드를 가지는 데이터 구조입니다:

zuul.project.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.project.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.project.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.project.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.project.src_dir

원격 호스트에서 원격 사용자의 홈 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.oldrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 이전 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 삭제로 인해 큐에 추가된 경우, 해당 태그의 이전 git sha가 여기에 포함됩니다. 태그가 생성된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 삭제로 인해 큐에 추가된 경우, 해당 참조의 이전 git sha가 여기에 포함됩니다. 참조가 생성된 경우에는 이 변수는 정의되지 않습니다.

zuul.newrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 새로운 리비전의 git sha가 여기에 포함됩니다. 항목이 타이머로 인해 큐에 추가되었고 타이머 트리거에 dereference 플래그가 설정된 경우에는, 큐에 추가될 당시 브랜치의 git sha가 포함됩니다.

Tag

항목이 태그 생성으로 인해 큐에 추가된 경우, 해당 태그의 새로운 git sha가 여기에 포함됩니다. 태그가 삭제된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 생성으로 인해 큐에 추가된 경우, 해당 참조의 새로운 git sha가 여기에 포함됩니다. 참조가 삭제된 경우에는 이 변수는 정의되지 않습니다.

zuul.commit_id

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

브랜치의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Tag

태그의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Ref

참조의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

zuul.tag

이 필드는 다음 항목 유형에 대해 존재합니다:

Tag

항목의 태그 이름(refs/tags/ 접두어 제외).

zuul.topic

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

변경 사항의 토픽(있는 경우).

zuul.ref

항목의 git 참조. 전체 경로 형식입니다(예: refs/heads/master 또는 refs/changes/…).

항목(Item)

큐 항목과 관련된 다음 변수를 사용할 수 있습니다:

zuul

zuul.items
Type: list

참고

zuul.items conflicts with the items() builtin so the variable can only be accessed with python dictionary like syntax, e.g: zuul['items']

이 변경 사항과 함께 테스트되는 참조를 각각 나타내는 딕셔너리 목록입니다.

zuul.items[].branch

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목의 브랜치(refs/heads/ 접두어 제외)입니다.

Change

변경 사항의 대상 브랜치(refs/heads/ 접두어 제외)입니다.

zuul.items[].bundle_id

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

변경 사항이 순환 의존성 사이클에 포함된 경우 해당 번들의 id입니다.

두 개 이상의 변경 사항을 가진 항목에서만 사용할 수 있습니다.

경고

이 변수는 사용 중단 상태이며 향후 버전에서 제거될 예정입니다. 대신 zuul.buildset_refs 를 사용하여 항목이 의존성 사이클에 해당하는지와 연관된 변경 사항을 식별하십시오.

zuul.items[].change

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 식별자입니다.

zuul.items[].change_message

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 커밋 또는 풀 리퀘스트 메시지입니다. Zuul이 Ansible을 실행할 때 이 변수는 !unsafe YAML 태그가 지정되어 Ansible이 값을 보간(interpolate)하지 않도록 합니다. 단, 디버깅 및 확인을 위해 빌드 워크스페이스에 생성되는 inventory.yaml 파일에는 !unsafe 태그가 포함되지 않습니다.

zuul.items[].change_url

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 소스 위치 URL입니다. 예: https://review.example.org/#/c/123456/ 또는 https://github.com/example/example/pull/1234.

Branch

브랜치의 커밋 브라우저 URL입니다.

Tag

태그의 커밋 브라우저 URL입니다.

Ref

참조의 커밋 브라우저 URL입니다.

zuul.items[].patchset

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 패치셋 식별자입니다. 변경 사항이 수정되면 이 값은 달라집니다.

zuul.items[].project

항목의 프로젝트. 다음 필드를 가지는 데이터 구조입니다:

zuul.items[].project.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.items[].project.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.items[].project.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.items[].project.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.items[].project.src_dir

원격 호스트에서 원격 사용자의 홈 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.items[].oldrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 이전 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 삭제로 인해 큐에 추가된 경우, 해당 태그의 이전 git sha가 여기에 포함됩니다. 태그가 생성된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 삭제로 인해 큐에 추가된 경우, 해당 참조의 이전 git sha가 여기에 포함됩니다. 참조가 생성된 경우에는 이 변수는 정의되지 않습니다.

zuul.items[].newrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 새로운 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 생성으로 인해 큐에 추가된 경우, 해당 태그의 새로운 git sha가 여기에 포함됩니다. 태그가 삭제된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 생성으로 인해 큐에 추가된 경우, 해당 참조의 새로운 git sha가 여기에 포함됩니다. 참조가 삭제된 경우에는 이 변수는 정의되지 않습니다.

zuul.items[].commit_id

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

브랜치의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Tag

태그의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Ref

참조의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

zuul.items[].tag

이 필드는 다음 항목 유형에 대해 존재합니다:

Tag

항목의 태그 이름(refs/tags/ 접두어 제외).

zuul.items[].topic

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

변경 사항의 토픽(있는 경우).

zuul.build_refs
Type: list

이 빌드와 연관된 참조를 각각 나타내는 딕셔너리 목록입니다. 일반적으로 이 목록에는 하나의 항목만 존재하지만, 큐 항목이 의존성 사이클인 경우 사이클 내 둘 이상의 항목이 잡 실행을 요청했고 잡이 중복 제거되었다면, 이 빌드가 실행되는 각 항목이 포함됩니다. 잡은 사이클의 모든 항목, 일부 항목 또는 아무 항목과도 중복 제거될 수 있습니다. 일부 또는 아무 항목과도 중복 제거되지 않은 경우 잡의 여러 빌드가 실행되며, 이 변수는 해당 빌드가 어떤 항목에 적용되는지를 나타낸다.

zuul.build_refs[].branch

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목의 브랜치(refs/heads/ 접두어 제외)입니다.

Change

변경 사항의 대상 브랜치(refs/heads/ 접두어 제외)입니다.

zuul.build_refs[].change

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 식별자입니다.

zuul.build_refs[].change_message

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 커밋 또는 풀 리퀘스트 메시지입니다. Zuul이 Ansible을 실행할 때 이 변수는 !unsafe YAML 태그가 지정되어 Ansible이 값을 보간(interpolate)하지 않도록 합니다. 단, 디버깅 및 확인을 위해 빌드 워크스페이스에 생성되는 inventory.yaml 파일에는 !unsafe 태그가 포함되지 않습니다.

zuul.build_refs[].change_url

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 소스 위치 URL입니다. 예: https://review.example.org/#/c/123456/ 또는 https://github.com/example/example/pull/1234.

Branch

브랜치의 커밋 브라우저 URL입니다.

Tag

태그의 커밋 브라우저 URL입니다.

Ref

참조의 커밋 브라우저 URL입니다.

zuul.build_refs[].patchset

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 패치셋 식별자입니다. 변경 사항이 수정되면 이 값은 달라집니다.

zuul.build_refs[].project

항목의 프로젝트. 다음 필드를 가지는 데이터 구조입니다:

zuul.build_refs[].project.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.build_refs[].project.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.build_refs[].project.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.build_refs[].project.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.build_refs[].project.src_dir

원격 호스트에서 원격 사용자의 홈 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.build_refs[].oldrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 이전 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 삭제로 인해 큐에 추가된 경우, 해당 태그의 이전 git sha가 여기에 포함됩니다. 태그가 생성된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 삭제로 인해 큐에 추가된 경우, 해당 참조의 이전 git sha가 여기에 포함됩니다. 참조가 생성된 경우에는 이 변수는 정의되지 않습니다.

zuul.build_refs[].newrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 새로운 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 생성으로 인해 큐에 추가된 경우, 해당 태그의 새로운 git sha가 여기에 포함됩니다. 태그가 삭제된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 생성으로 인해 큐에 추가된 경우, 해당 참조의 새로운 git sha가 여기에 포함됩니다. 참조가 삭제된 경우에는 이 변수는 정의되지 않습니다.

zuul.build_refs[].commit_id

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

브랜치의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Tag

태그의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Ref

참조의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

zuul.build_refs[].tag

이 필드는 다음 항목 유형에 대해 존재합니다:

Tag

항목의 태그 이름(refs/tags/ 접두어 제외).

zuul.build_refs[].topic

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

변경 사항의 토픽(있는 경우).

zuul.build_refs[].merge_commit_id

이 필드는 변경 사항이 병합되는 동안 해당 변경 사항에 대해 실행되는 리포터 잡에서만 존재합니다. 모든 소스에서 사용 가능하지는 않을 수 있습니다(현재 Gerrit, GitHub, GitLab에서 지원됨).

변경 사항이 병합된 이후 대상 브랜치의 git sha입니다.

zuul.buildset_refs
Type: list

이 큐 항목과 연관된 참조를 각각 나타내는 딕셔너리 목록입니다. 일반적으로 이 목록에는 하나의 항목만 존재하지만, 큐 항목이 의존성 사이클인 경우 사이클에 포함된 각 변경 사항이 모두 포함됩니다.

zuul.buildset_refs[].branch

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목의 브랜치(refs/heads/ 접두어 제외)입니다.

Change

변경 사항의 대상 브랜치(refs/heads/ 접두어 제외)입니다.

zuul.buildset_refs[].change

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 식별자입니다.

zuul.buildset_refs[].change_message

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 커밋 또는 풀 리퀘스트 메시지입니다. Zuul이 Ansible을 실행할 때 이 변수는 !unsafe YAML 태그가 지정되어 Ansible이 값을 보간(interpolate)하지 않도록 합니다. 단, 디버깅 및 확인을 위해 빌드 워크스페이스에 생성되는 inventory.yaml 파일에는 !unsafe 태그가 포함되지 않습니다.

zuul.buildset_refs[].change_url

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 소스 위치 URL입니다. 예: https://review.example.org/#/c/123456/ 또는 https://github.com/example/example/pull/1234.

Branch

브랜치의 커밋 브라우저 URL입니다.

Tag

태그의 커밋 브라우저 URL입니다.

Ref

참조의 커밋 브라우저 URL입니다.

zuul.buildset_refs[].patchset

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

해당 변경 사항의 패치셋 식별자입니다. 변경 사항이 수정되면 이 값은 달라집니다.

zuul.buildset_refs[].project

항목의 프로젝트. 다음 필드를 가지는 데이터 구조입니다:

zuul.buildset_refs[].project.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.buildset_refs[].project.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.buildset_refs[].project.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.buildset_refs[].project.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.buildset_refs[].project.src_dir

원격 호스트에서 원격 사용자의 홈 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.buildset_refs[].oldrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 이전 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 삭제로 인해 큐에 추가된 경우, 해당 태그의 이전 git sha가 여기에 포함됩니다. 태그가 생성된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 삭제로 인해 큐에 추가된 경우, 해당 참조의 이전 git sha가 여기에 포함됩니다. 참조가 생성된 경우에는 이 변수는 정의되지 않습니다.

zuul.buildset_refs[].newrev

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

항목이 변경 사항 병합 또는 브랜치로의 푸시로 인해 큐에 추가된 경우, 새로운 리비전의 git sha가 여기에 포함됩니다.

Tag

항목이 태그 생성으로 인해 큐에 추가된 경우, 해당 태그의 새로운 git sha가 여기에 포함됩니다. 태그가 삭제된 경우에는 이 변수는 정의되지 않습니다.

Ref

항목이 참조 생성으로 인해 큐에 추가된 경우, 해당 참조의 새로운 git sha가 여기에 포함됩니다. 참조가 삭제된 경우에는 이 변수는 정의되지 않습니다.

zuul.buildset_refs[].commit_id

이 필드는 다음 항목 유형에 대해 존재합니다:

Branch

브랜치의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Tag

태그의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

Ref

참조의 git sha. 정의되어 있는 경우 newrev 또는 oldrev 와 동일합니다.

zuul.buildset_refs[].tag

이 필드는 다음 항목 유형에 대해 존재합니다:

Tag

항목의 태그 이름(refs/tags/ 접두어 제외).

zuul.buildset_refs[].topic

이 필드는 다음 항목 유형에 대해 존재합니다:

Change

변경 사항의 토픽(있는 경우).

zuul.buildset_refs[].merge_commit_id

이 필드는 변경 사항이 병합되는 동안 해당 변경 사항에 대해 실행되는 리포터 잡에서만 존재합니다. 모든 소스에서 사용 가능하지는 않을 수 있습니다(현재 Gerrit, GitHub, GitLab에서 지원됨).

변경 사항이 병합된 이후 대상 브랜치의 git sha입니다.

잡

잡과 관련된 다음 변수를 사용할 수 있습니다:

zuul

zuul.artifacts
Type: list

잡에 job.requires 속성이 있고, Zuul이 파이프라인에서 이 변경 사항보다 앞에 있는 변경 사항 중 job.provides 속성이 일치하는 변경 사항을 찾은 경우, 해당 잡들에서 반환된 아티팩트 URL 반환 정보가 여기에 표시됩니다.

이 값은 다음 형식의 딕셔너리 목록입니다:

zuul.artifacts[].project

이 아티팩트를 제공한 프로젝트의 이름입니다.

zuul.artifacts[].change

이 아티팩트를 제공한 변경 사항 번호입니다.

zuul.artifacts[].patchset

해당 변경 사항의 패치셋입니다.

zuul.artifacts[].job

아티팩트를 생성한 잡의 이름입니다.

zuul.artifacts[].name

The name of the artifact (as supplied to 아티팩트 URL 반환).

zuul.artifacts[].url

The URL of the artifact (as supplied to 아티팩트 URL 반환).

zuul.artifacts[].metadata

The metadata of the artifact (as supplied to 아티팩트 URL 반환).

zuul.build

빌드의 UUID입니다. 빌드는 잡의 단일 실행을 의미합니다. 항목이 파이프라인 큐에 추가되면 일반적으로 해당 항목에 의해 트리거된 각 잡에 대해 하나의 빌드가 생성됩니다. 그러나 항목이 다시 큐에 추가될 수 있으며, 이 경우 또 다른 빌드가 실행될 수 있습니다. 종속 파이프라인에서는 큐 앞쪽의 상황 변화에 따라 동일한 항목에 대해 같은 잡이 여러 번 실행될 수 있습니다. 잡이 어떤 이유로든 실행될 때마다 새로운 고유 id가 부여됩니다.

zuul.buildset

빌드셋 UUID입니다. Zuul이 항목에 대해 잡을 실행할 때, 해당 잡들의 집합을 빌드셋이라고 합니다. 종속 파이프라인에서 앞선 항목의 구성이 변경되면 Zuul은 새로운 빌드셋을 생성하고 모든 잡을 다시 시작합니다.

zuul.child_jobs

이 잡이 성공적으로 완료된 후 실행될 1단계 종속 잡의 목록입니다.

zuul.override_checkout

잡이 체크아웃할 브랜치 또는 태그를 재정의하도록 구성된 경우, 여기에 해당 값이 포함됩니다. 그렇지 않으면 이 변수는 정의되지 않습니다.

zuul.pipeline

잡이 실행 중인 파이프라인의 이름입니다.

zuul.post_review
Type: bool

현재 잡이 post-review 파이프라인에서 실행 중인지 여부입니다.

zuul.job

실행 중인 잡의 이름입니다.

zuul.event_id

이 실행을 트리거한 이벤트의 UUID입니다. 주로 디버깅 목적으로 유용합니다.

zuul.voting

잡이 voting 여부를 나타내는 boolean 값입니다.

zuul.attempts

현재 빌드셋에 대해 이 잡을 실행하려고 시도한 횟수를 나타내는 정수 값입니다. 사전 동작 실패나 네트워크 연결 문제가 발생한 경우 이전 시도가 취소되었을 수 있으며, 이 값은 1보다 클 수 있습니다.

zuul.max_attempts

사전 플레이북에서 오류가 발생했을 때 실패로 보고되기 전에 이 잡에 대해 시도할 횟수입니다. 이 값은 job.attempts 에서 가져옵니다.

zuul.ansible_version

이 잡 실행에 사용된 Ansible community 패키지 릴리스 버전입니다.

zuul.projects
Type: dict

Zuul이 해당 항목을 위해 준비한 모든 프로젝트의 딕셔너리입니다. 최소한 항목 자체의 프로젝트를 포함합니다. 또한 이 항목이 의존하는 다른 항목의 프로젝트와 job.required-projects 에 나타나는 프로젝트도 포함합니다.

이는 딕셔너리의 딕셔너리 구조입니다. 각 값은 canonical_name 을 키로 가지며, 각 항목은 다음으로 구성됩니다:

zuul.projects{}.name

호스트 이름을 제외한 프로젝트 이름입니다. 예: org/project.

zuul.projects{}.short_name

디렉터리나 조직을 제외한 프로젝트 이름입니다. 예: project.

zuul.projects{}.canonical_hostname

프로젝트가 위치한 정규화된 호스트 이름입니다. 예: git.example.com.

zuul.projects{}.canonical_name

호스트 이름을 포함한 프로젝트의 전체 정규화된 이름입니다. 예: git.example.com/org/project.

zuul.projects{}.src_dir

작업 디렉터리를 기준으로 한 소스 코드 경로입니다. 예: src/git.example.com/org/project.

zuul.projects{}.required

이 프로젝트가 해당 잡의 job.required-projects 목록에 포함되어 있는지를 나타내는 boolean 값입니다.

zuul.projects{}.checkout

Zuul이 이 프로젝트에 대해 체크아웃한 브랜치 또는 태그입니다. 이는 항목과 연관된 브랜치 또는 태그와 잡 구성의 영향을 받을 수 있습니다.

zuul.projects{}.checkout_description

Zuul이 특정 브랜치 또는 태그를 체크아웃한 이유에 대한 사람이 읽기 쉬운 설명입니다. 이는 복잡한 잡의 경우 디버깅을 돕기 위한 것입니다. 구체적인 텍스트는 정의되어 있지 않으며 변경될 수 있습니다.

zuul.projects{}.commit

체크아웃된 커밋의 16진수 SHA입니다. 이 커밋은 업스트림 저장소에 존재할 수도 있으며, 추측 기반 병합의 결과인 경우에는 이 잡 실행 중에만 존재할 수 있습니다.

예를 들어, 특정 프로젝트 하나의 소스 디렉터리에 접근하려면 다음과 같이 사용할 수 있습니다:

{{ zuul.projects['git.example.com/org/project'].src_dir }}

프로젝트 목록을 순회하려면 다음과 같은 작업을 작성할 수 있습니다:

- name: Sample project iteration
  debug:
    msg: "Project {{ item.name }} is at {{ item.src_dir }}
  with_items: {{ zuul.projects.values() | list }}

zuul.playbook_context

이 딕셔너리는 잡에서 실행된 각 플레이북의 실행 정보가 포함되어 있습니다. Zuul이 정확히 어떤 플레이북과 롤을 실행했는지 이해하는 데 유용합니다.

여기에 표시되는 모든 경로는 빌드 디렉터리의 루트 아래에 위치합니다 (익스큐터에서 잡이 접근 가능한 워크스페이스 디렉터리보다 한 단계 위입니다).

zuul.playbook_context.playbook_projects
Type: dict

플레이북 실행을 위해 체크아웃된 프로젝트의 딕셔너리입니다. 신뢰할 수 있는 실행 컨텍스트에서 사용되는 경우 업스트림 저장소에 병합된 커밋만 포함합니다. 신뢰할 수 없는 컨텍스트에서는 추측 기반 병합된 코드가 포함될 수 있습니다.

키는 경로이며, 각 값은 다음 키를 가지는 또 다른 딕셔너리입니다:

zuul.playbook_context.playbook_projects{}.canonical_name

저장소의 정규 이름입니다.

zuul.playbook_context.playbook_projects{}.checkout

체크아웃된 브랜치 또는 태그입니다.

zuul.playbook_context.playbook_projects{}.commit

체크아웃된 커밋의 16진수 SHA입니다. 위와 마찬가지로, 이 커밋은 추측 기반 병합의 결과인지 여부에 따라 업스트림 저장소에 존재하지 않을 수도 있습니다.

zuul.playbook_context.pre_playbooks
Type: list

zuul.playbook_context.playbooks 을 참조하십시오.

zuul.playbook_context.playbooks
Type: list

잡에서 실행된 pre, run 또는 post 플레이북의 순서가 있는 목록입니다. 각 항목은 다음 키를 가지는 딕셔너리입니다:

zuul.playbook_context.playbooks[].path

플레이북의 경로입니다.

zuul.playbook_context.playbooks[].roles
Type: list

플레이북에서 사용할 수 있는 롤에 대한 정보입니다. Ansible에 전달되는 실제 role path 는 다음 딕셔너리 각각의 role_path 항목을 연결한 값입니다. 그 외의 정보는 role path에 포함된 내용을 설명합니다.

다양한 롤 레이아웃과 별칭을 처리하기 위해 role path의 각 요소는 자체 디렉터리를 가집니다. 해당 롤 저장소의 내용과 별칭 구성에 따라, zuul.playbook_context.playbook_projects 에 있는 저장소 체크아웃 중 하나에 심볼릭 링크가 추가되어 Ansible에 올바른 이름으로 롤이 전달될 수 있도록 합니다.

zuul.playbook_context.playbooks[].roles[].checkout

체크아웃된 브랜치 또는 태그입니다.

zuul.playbook_context.playbooks[].roles[].checkout_description

Zuul이 특정 브랜치 또는 태그를 체크아웃한 이유에 대한 사람이 읽기 쉬운 설명입니다. 이는 복잡한 잡의 경우 디버깅을 돕기 위한 것입니다. 구체적인 텍스트는 정의되어 있지 않으며 변경될 수 있습니다.

zuul.playbook_context.playbooks[].roles[].link_name

심볼릭 링크의 이름입니다.

zuul.playbook_context.playbooks[].roles[].link_target

심볼릭 링크의 대상입니다.

zuul.playbook_context.playbooks[].roles[].role_path

Ansible에 전달된 role path입니다.

zuul.playbook_context.post_playbooks
Type: list

zuul.playbook_context.playbooks 을 참조하십시오.

zuul.tenant

현재 Zuul 테넌트의 이름입니다.

zuul.pre_timeout

pre-run 플레이북 타임아웃(초 단위)입니다.

zuul.timeout

잡 타임아웃(초 단위)입니다.

zuul.post_timeout

post-run 플레이북 타임아웃(초 단위)입니다.

zuul.jobtags

잡과 연관된 태그 목록입니다. git 태그와 혼동하지 말 것. 이는 잡에서 보고나 분류 목적으로 사용할 수 있는 자유 형식의 텍스트 필드입니다.

zuul.resources

컨테이너 빌드 리소스를 사용하는 잡은 해당 리소스를 설명하는 resources 변수에 접근할 수 있습니다. Resources는 그룹 키를 가지는 딕셔너리이며, 각 값은 다음으로 구성됩니다:

zuul.resources.namespace

리소스의 네임스페이스 이름입니다.

zuul.resources.context

kube config 컨텍스트 이름입니다.

zuul.resources.pod

레이블이 kubectl 연결을 정의하는 경우의 pod 이름입니다.

프로젝트 또는 네임스페이스 리소스는 템플릿에서 다음과 같이 사용할 수 있습니다:

- hosts: localhost
    tasks:
    - name: Create a k8s resource
      k8s_raw:
        state: present
        context: "{{ zuul.resources['node-name'].context }}"
        namespace: "{{ zuul.resources['node-name'].namespace }}"

Kubectl 리소스는 템플릿에서 다음과 같이 사용할 수 있습니다:

- hosts: localhost
    tasks:
    - name: Copy src repos to the pod
      command: >
        oc rsync -q --progress=false
            {{ zuul.executor.src_root }}/
            {{ zuul.resources['node-name'].pod }}:src/
        no_log: true

작업 디렉터리

또한 작업 디렉터리와 잡을 실행 중인 익스큐터에 대한 일부 정보도 제공됩니다:

zuul

zuul.executor

잡을 실행 중인 익스큐터와 관련된 여러 값이 제공됩니다:

zuul.executor.hostname

익스큐터의 호스트 이름.

zuul.executor.src_root

소스 디렉터리의 경로.

zuul.executor.log_root

로그 디렉터리의 경로.

zuul.executor.work_root

작업 디렉터리의 경로.

zuul.executor.inventory_file

인벤토리의 경로입니다. 노드셋 없이 실행되는 잡에서는 Ansible이 localhost에 대해 이를 설정하지 않기 때문에 이 변수가 필요합니다; 자세한 내용은 porting guide <https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.4.html#inventory> 를 참조하십시오.

인벤토리 파일은 trusted execution context 에서 실행되는 잡만 읽을 수 있습니다.

zuul_success

사후 동작 플레이북에는 잡의 동작 단계가 성공했는지 여부를 나타내는 이 변수가 전달됩니다. 이 변수는 bool 필터와 함께 사용하도록 되어 있습니다.

tasks:
  - shell: echo example
    when: zuul_success | bool

zuul_will_retry

사후 동작 및 cleanup 플레이북에는 잡이 재시도될지 여부를 나타내는 이 변수가 전달됩니다. 이 변수는 bool 필터와 함께 사용하도록 되어 있습니다.

tasks:
  - shell: echo example
    when: zuul_will_retry | bool

nodepool

Nodepool에서 제공하는 각 호스트에 대한 정보는 nodepool 호스트 변수에 제공됩니다. 사용 가능한 값은 노드와 이를 제공한 드라이버에 따라 달라집니다. 해당되지 않는 경우 값은 null 일 수 있습니다.

nodepool.label

노드의 nodepool 레이블.

nodepool.az

노드가 배치된 가용 영역.

nodepool.cloud

노드가 생성된 클라우드의 이름.

nodepool.provider

노드의 nodepool 제공자 이름.

nodepool.region

nodepool 제공자의 리전 이름.

nodepool.host_id

노드의 하이퍼바이저에 대한 클라우드의 호스트 식별자.

nodepool.external_id

노드에 대한 클라우드의 식별자.

nodepool.slot

노드에서 여러 잡 실행을 지원하는 경우, 이 잡에 할당된 노드 하위 구분에 대한 고유한 숫자 ID입니다. 빌드 디렉터리 충돌을 방지하는 데 사용할 수 있습니다.

nodepool.interface_ip

클라우드 제공자와 nodepool이 결정한, 노드에 접속하기에 가장 적합한 IP 주소입니다.

nodepool.public_ipv4

노드의 공용 IPv4 주소입니다.

nodepool.private_ipv4

노드의 사설 IPv4 주소입니다.

nodepool.public_ipv6

노드의 공용 IPv6 주소입니다.

nodepool.private_ipv6

노드의 사설 IPv6 주소입니다.

nodepool.node_properties

Nodepool이 노드를 Zuul에 할당할 때 고려된 기준을 나타내는 boolean 플래그 등, 노드 속성의 임의 매핑. 주목할 만한 속성으로는 노드가 AWS 스팟 인스턴스인 경우의 spot, 또는 AWS fleet API를 사용해 Nodepool이 노드를 생성한 경우의 fleet 이 있습니다.

SSH 키

Zuul은 각 잡을 시작할 때 SSH agent를 실행하고 최소 하나의 키를 해당 agent에 추가합니다. 일반적으로 Ansible이 원격 노드에서 작업을 수행할 때 이를 사용하므로 이를 인지할 필요는 없습니다. 그러나 일부 상황에서는 agent와 직접 상호작용해야 할 수 있습니다. 예를 들어 특정 호스트에 접근하기 위해 시크릿으로 제공된 키를 잡에 추가하거나, 사전 플레이북에서 할당된 노드에 로그인하는 데 사용되는 키를 교체하여 신뢰되지 않은 잡 콘텐츠로부터의 오남용을 방지하고자 할 수 있습니다.

SSH agent에 추가되는 각 키에 대한 설명은 다음과 같습니다.

Nodepool 키

이 키는 시스템 관리자가 제공합니다. Nodepool이 제공하는 모든 노드에서 허용될 것으로 예상되며, 일반적으로 Zuul이 잡을 실행할 때 사용하는 키입니다. 관련 없는 잡이 이 키를 허용하는 임의의 호스트(예: 다른 잡의 노드 또는 정적 호스트)를 Ansible 인벤토리에 추가할 가능성이 있으므로, add-build-sshkey 롤을 사용하는 것이 권장됩니다.

테넌트 키

Zuul의 각 테넌트는 자체 SSH 키 쌍을 가집니다. 이 키는 해당 테넌트에서 실행되는 모든 잡에 대해 SSH agent에 추가됩니다. 이는 모든 파이프라인에서 사용 가능합니다는 점에서 프로젝트 키와 다르다. 특정 노드에 대한 접근을 특정 테넌트로 제한하는 데 유용할 수 있습니다. 시스템은 add_host Ansible 모듈을 사용해 인벤토리에 추가할 수 있으며, Nodepool의 정적 노드로 제공될 수도 있습니다.

Zuul은 내장 웹서버를 통해 각 테넌트의 공개 SSH 키를 제공합니다. 해당 키는 /api/tenant/<tenant>/tenant-ssh-key/ssh.pub 경로에서 가져올 수 있으며, <tenant> 는 테넌트의 이름입니다.

프로젝트 키

Zuul의 각 프로젝트는 자체 SSH 키 쌍을 가집니다. 이 키는 post-review 파이프라인에서 실행되는 모든 잡에 대해 SSH agent에 추가됩니다. 시스템 관리자가 해당 프로젝트를 신뢰하는 경우, post-review 잡이 시스템에 접근할 수 있도록 프로젝트의 공개 키를 시스템에 추가할 수 있습니다. 시스템은 add_host Ansible 모듈을 사용해 인벤토리에 추가할 수 있으며, Nodepool의 정적 노드로 제공될 수도 있습니다.

Zuul은 내장 웹서버를 통해 각 프로젝트의 공개 SSH 키를 제공합니다. 해당 키는 /api/tenant/<tenant>/project-ssh-key/<project>.pub 경로에서 가져올 수 있으며, <project> 는 프로젝트의 정규 이름이고 <tenant> 는 해당 프로젝트를 포함하는 테넌트의 이름입니다.

반환 값

잡은 Zuul의 동작에 영향을 주거나 종속 잡에서 사용하기 위해 일부 값을 반환할 수 있습니다. 값을 반환하려면 잡 플레이북에서 zuul_return Ansible 모듈을 사용하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        foo: bar

딕셔너리 {'foo': 'bar'} 를 Zuul에 반환합니다.

선택적으로, 반환할 데이터가 많은 경우 해당 데이터를 포함한 JSON 형식 파일의 경로를 지정할 수 있습니다. 예를 들어:

tasks:
  - zuul_return:
      file: /path/to/data.json

일반적으로 반환된 데이터는 인벤토리 파일을 통해 종속 잡에 제공되며, 이는 잡의 로그 아카이브에 포함될 수 있습니다. 민감한 데이터를 종속 잡에 제공해야 하는 경우에는 secret_data 속성을 대신 사용할 수 있으며, 데이터는 잡 시크릿과 동일한 메커니즘을 통해 제공되어 작업 디렉터리의 디스크에 기록되지 않습니다. 그럼에도 불구하고 잡 내부에서 민감한 데이터를 표시하거나 저장하지 않도록 주의해야 합니다. 예를 들어:

tasks:
  - zuul_return:
      secret_data:
        password: foobar

zuul 계층에 속하지 않는 모든 값은 종속 잡에 Ansible 변수로 제공됩니다. 이 변수들은 Zuul의 다른 유형 변수보다 우선순위가 낮으므로, 잡 변수와 이름이 겹치지 않도록 해야 합니다. 둘 이상의 부모 잡이 동일한 변수를 반환하는 경우, 잡 그래프에서 더 나중에 실행되는 잡의 값이 우선합니다.

zuul 계층의 값은 Zuul 자체의 동작에 영향을 주는 특수 변수입니다. 다음 문단에서는 현재 지원되는 특수 변수와 그 의미를 설명합니다.

로그 URL 반환

빌드의 로그 URL을 설정하려면 zuul_return 을 사용하여 zuul.log_url 값을 설정하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        zuul:
          log_url: http://logs.example.com/path/to/build/logs

아티팩트 URL 반환

빌드가 아티팩트를 생성하는 경우, 여러 개의 URL을 Zuul에 반환하여 SQL 데이터베이스에 저장할 수 있습니다. 이후 웹 인터페이스와 후속 잡에서 이를 사용할 수 있습니다.

빌드에 대한 아티팩트 URL을 제공하려면 zuul_return 을 사용하여 zuul.artifacts 딕셔너리 아래에 키를 설정하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        zuul:
          artifacts:
            - name: tarball
              url: http://example.com/path/to/package.tar.gz
              metadata:
                version: 3.0
            - name: docs
              url: build/docs/

url 값이 상대 URL인 경우, 설정되어 있다면 zuul.log_url 값과 결합되어 절대 URL이 생성됩니다. metadata 키는 선택 사항이며, 제공되는 경우 딕셔너리여야 합니다. 그 키와 값은 임의의 값일 수 있습니다.

zuul_return 이 여러 번 호출되는 경우(예: 여러 플레이북을 통해), 각 호출에서 반환된 zuul.artifacts 의 요소는 추가됩니다.

종속 잡 건너뛰기

참고

다음 섹션에서 ‘child jobs’ 은 job.dependencies 로 구성된 종속 잡을 의미하며, 부모 잡을 상속하는 잡과 혼동해서는 안 됩니다.

현재 빌드에서 종속 잡을 건너뛰려면 zuul_return 을 사용하여 zuul.child_jobs 값을 설정하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        zuul:
          child_jobs:
            - dependent_jobA
            - dependent_jobC

사전 구성된 종속 잡 중 dependent_jobA와 dependent_jobC만 실행하도록 zuul에 지시합니다. dependent_jobB가 구성되어 있었다면 SKIPPED로 표시됩니다. zuul.child_jobs가 비어 있으면 모든 잡이 SKIPPED로 표시됩니다. 유효하지 않은 종속 잡은 제거되고 무시되며, 유효하지 않은 잡만 나열된 경우 zuul.child_jobs에 빈 목록을 제공한 것과 동일합니다.

경고 남기기

잡은 변경 사항에 대해 zuul이 남기는 댓글에 추가될 경고를 남길 수 있습니다. zuul_return 을 사용하여 경고 목록을 추가하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        zuul:
          warnings:
            - This warning will be posted on the change.

zuul_return 이 여러 번 호출되는 경우(예: 여러 플레이북을 통해), 각 호출에서 반환된 zuul.warnings 의 요소는 추가됩니다.

파일 코멘트 남기기

변경 사항의 파일 코멘트를 남기도록 리포터에 지시하려면 zuul.file_comments 값을 설정하십시오. 예를 들어:

tasks:
  - zuul_return:
      data:
        zuul:
          file_comments:
            path/to/file.py:
              - line: 42
                message: "Line too long"
                level: info
              - line: 82
                message: "Line too short"
              - line: 119
                message: "This block is indented too far."
                level: warning
                range:
                  start_line: 117
                  start_character:    0
                  end_line:   119
                  end_character:  37

현재 모든 reporter가 라인 코멘트(또는 그 모든 기능)를 지원하는 것은 아닙니다. 이 경우 reporter는 해당 데이터를 단순히 무시합니다. level 은 선택 사항이지만, 제공되는 경우 info, warning, error 중 하나여야 합니다.

Zuul은 제공된 라인 번호를 원래 작성된 변경 사항의 해당 라인으로 자동 변환하려고 시도합니다(변경 사항 작성 이후 병합된 다른 변경 사항으로 인해 차이가 있을 수 있습니다). 이 동작이 잡에 대해 잘못된 결과를 초래하는 경우, zuul_return 에서 zuul.disable_file_comment_line_mapping 변수를 true 로 설정하여 비활성화할 수 있습니다.

zuul_return 이 여러 번 호출되는 경우(예: 여러 플레이북을 통해), 각 호출에서 반환된 zuul.file_comments 의 요소는 추가됩니다.

잡 일시 중지

동작 단계 중 zuul에 알림으로써 동작 단계 이후 잡을 일시 중지할 수 있습니다. 이 경우 종속 잡은 시작될 수 있으며, 선행 잡은 모든 종속 잡이 완료될 때까지 일시 중지된 상태로 유지됩니다. 예를 들어 종속 잡에서 사용할 docker 레지스트리를 잡에서 시작하는 경우에 유용합니다. 잡을 일시 중지하려면 zuul_return 을 사용하여 zuul.pause 값을 설정하십시오. 동시에 종속 잡에 임의의 데이터를 제공할 수도 있습니다.

tasks:
  - zuul_return:
      data:
        zuul:
          pause: true
        registry_ip_address: "{{ hostvars[groups.all[0]].ansible_host }}"

재시도 건너뛰기

pre-run 실패로 인한 재시도를 건너뛰려면 zuul.retry 를 false 로 설정할 수 있습니다.

예를 들어 다음과 같이 하면 빌드 재시도를 건너뛴다:

tasks:
  - zuul_return:
      data:
        zuul:
          retry: false

Ansible 그룹

Ansible 호스트 그룹은 잡의 nodeset 을 통해 구성할 수 있습니다. 이에 더해 Zuul은 zuul_unreachable 이라는 이름의 그룹을 자동으로 생성합니다. 이 그룹은 항상 존재하며, 잡 시작 시에는 비어 있습니다. 어떤 플레이북에서 접근 불가능한 호스트가 발생하면 해당 호스트는 이후 모든 플레이북에 대해 이 그룹에 추가됩니다. 이는 이미 접근 불가능한 것으로 알려진 호스트에서 특정 post-run 플레이북 단계를 실행하지 않도록 하는 데 사용할 수 있습니다. 예를 들어 원격 호스트에서 로그 복사를 피하려면 다음과 같이 작성할 수 있습니다:

- hosts: all:!zuul_unreachable
  gather_facts: no
  tasks:
    - name: Copy logs
      ...

zuul_unreachable 그룹 이름은 zuul에서 예약되어 있으며, 노드셋에 정의된 동일한 이름의 그룹을 자동으로 덮어쓴다.

빌드 상태

잡 빌드는 다음 상태 중 하나를 가질 수 있습니다:

SUCCESS

정상적인 잡 실행.

FAILURE

잡은 정상적으로 실행되었으나 실패로 종료되었습니다.

RETRY

pre-run 플레이북이 실패했거나 노드에 접근할 수 없게 되어 잡이 재시도됩니다.

RETRY_LIMIT

pre-run 플레이북이 실패했거나 노드에 접근할 수 없는 상태가 재시도 최대 attempts 횟수를 초과했습니다.

POST_FAILURE

post-run 플레이북이 실패했습니다.

SKIPPED

빌드 종속성 중 하나가 실패하여 이 잡은 실행되지 않았습니다.

NODE_FAILURE

Provider 가 노드셋 요청을 충족할 수 없었습니다. 이는 Zuul(또는 Nodepool)이 요청된 노드를 제공할 수 없는 경우 발생할 수 있습니다.