CI/CD Job은 GitLab CI/CD 파이프라인의 기본 요소입니다. Job은 코드 빌드, 테스트 또는 배포와 같은 작업을 수행하기 위해 실행할 명령어 목록으로 .gitlab-ci.yml 파일에 구성됩니다.

Job의 특징:

• Docker 컨테이너와 같이 러너에서 실행됩니다.
• 다른 Job과 독립적으로 실행됩니다.
• Job의 전체 실행 로그가 있는 Job 로그가 있습니다.

Job은 실행 방법, 실행 시기 제어, Stage 그룹화, CI/CD 변수 정의, 캐시 정의, 아티팩트 저장 등 Job 실행의 모든 측면을 정의하는 YAML 키워드로 정의됩니다.

파이프라인에 Job 추가#

파이프라인에 Job을 추가하려면 .gitlab-ci.yml 파일에 추가합니다. Job은 다음 조건을 충족해야 합니다:

• YAML 구성의 최상위 수준에 정의되어야 합니다.
• 고유한 Job 이름을 가져야 합니다.
• 실행할 명령을 정의하는 script 섹션이 있거나, 다운스트림 파이프라인을 트리거하는 trigger 섹션이 있어야 합니다.

예를 들면:

my-ruby-job:
  script:
    - bundle install
    - bundle exec my_ruby_command

my-shell-script-job:
  script:
    - my_shell_script.sh

Job 이름#

다음 키워드는 Job 이름으로 사용할 수 없습니다:

• image
• services
• stages
• before_script
• after_script
• variables
• cache
• include
• deploy Stage에 구성된 pages:deploy

또한 다음 이름은 따옴표로 묶으면 유효하지만 파이프라인 구성을 불명확하게 만들 수 있으므로 권장되지 않습니다:

• "true":
• "false":
• "nil":

Job 이름은 255자 이하여야 합니다.

Job에 고유한 이름을 사용합니다. 파일에 여러 Job이 동일한 이름을 가지면 하나만 파이프라인에 추가되고, 어느 것이 선택될지 예측하기 어렵습니다. 하나 이상의 포함된 파일에서 동일한 Job 이름이 사용되는 경우 파라미터가 병합됩니다.

Job 숨기기#

구성 파일에서 삭제하지 않고 Job을 일시적으로 비활성화하려면 Job 이름 앞에 점(.)을 추가합니다. 숨겨진 Job에는 script 또는 trigger 키워드가 포함될 필요가 없지만 유효한 YAML 구성이 포함되어야 합니다.

예를 들면:

.hidden_job:
  script:
    - run test

숨겨진 Job은 GitLab CI/CD에서 처리되지 않지만 다음과 함께 재사용 가능한 구성을 위한 템플릿으로 사용할 수 있습니다:

• extends 키워드.
• YAML 앵커.

Job 키워드의 기본값 설정#

default 키워드를 사용하여 기본 Job 키워드와 값을 설정할 수 있으며, 이는 파이프라인의 모든 Job에서 기본적으로 사용됩니다.

예를 들면:

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

rspec-job:
  script: bundle exec rspec

파이프라인이 실행되면 Job은 기본 키워드를 사용합니다:

rspec-job:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World
  script: bundle exec rspec

기본 키워드 및 변수의 상속 제어#

다음의 상속을 제어할 수 있습니다:

• inherit:default로 기본 키워드.
• inherit:variables로 기본 변수.

예를 들면:

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
  WEBHOOK_URL: https://my-webhook.example.com

rubocop:
  inherit:
    default: false
    variables: false
  script: bundle exec rubocop

rspec:
  inherit:
    default: [image]
    variables: [WEBHOOK_URL]
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma

이 예시에서:

• rubocop:
  • 상속: 없음.
• rspec:
  • 상속: 기본 image와 WEBHOOK_URL 변수.
  • 상속하지 않음: 기본 before_script와 DOMAIN 변수.
• capybara:
  • 상속: 기본 before_script와 image.
  • 상속하지 않음: DOMAIN과 WEBHOOK_URL 변수.
• karma:
  • 상속: 기본 image와 before_script, 그리고 DOMAIN 변수.
  • 상속하지 않음: WEBHOOK_URL 변수.

파이프라인에서 Job 보기#

파이프라인에 액세스하면 해당 파이프라인의 관련 Job을 볼 수 있습니다.

파이프라인에서 Job의 순서는 파이프라인 그래프 유형에 따라 다릅니다.

• 전체 파이프라인 그래프에서 Job은 이름순으로 알파벳 순서로 정렬됩니다.
• 파이프라인 미니 그래프에서 Job은 실패한 Job이 먼저 표시되는 상태 심각도 순으로 정렬되고, 그 다음 이름 알파벳 순으로 정렬됩니다.

개별 Job을 선택하면 Job 로그가 표시되고 다음을 수행할 수 있습니다:

• Job 취소.
• 실패한 경우 Job 재시도.
• 성공한 경우 Job 다시 실행.
• Job 로그 지우기.

프로젝트 Job 보기#

히스토리

• Job 이름 필터가 GitLab 17.3에서 GitLab.com 및 GitLab Self-Managed의 실험으로 API에는 populate_and_use_build_names_table, UI에는 fe_search_build_by_name이라는 플래그와 함께 추가됨. 기본적으로 비활성화됨.
• GitLab 18.5에서 일반 가용. 기능 플래그 populate_and_use_build_names_table 및 fe_search_build_by_name 제거됨.
• Job 종류 필터가 GitLab 18.3에서 추가됨.

프로젝트에서 실행된 Job을 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Jobs를 선택합니다.

Job 상태, 소스, 이름, 종류로 목록을 필터링할 수 있습니다.

기본적으로 필터는 빌드 Job만 표시합니다. 트리거 Job을 보려면 필터를 지우고 Kind > Trigger를 선택합니다.

사용 가능한 Job 상태#

CI/CD Job은 다음 상태를 가질 수 있습니다:

• canceled: Job이 수동으로 취소되었거나 자동으로 중단됨.
• canceling: Job이 취소되는 중이지만 after_script가 실행 중.
• created: Job이 생성되었지만 아직 처리되지 않음.
• failed: Job 실행이 실패함.
• manual: Job을 시작하려면 수동 조작이 필요함.
• pending: Job이 러너를 기다리는 대기열에 있음.
• preparing: 러너가 실행 환경을 준비 중.
• running: Job이 러너에서 실행 중.
• scheduled: Job이 예약되었지만 실행이 시작되지 않음.
• skipped: 조건 또는 종속성으로 인해 Job을 건너뜀.
• success: Job이 성공적으로 완료됨.
• waiting_for_callback: Job이 외부 서비스에서 콜백을 기다리는 중.
• waiting_for_resource: Job이 리소스를 사용 가능하게 기다리는 중.

Job의 소스 보기#

히스토리

• GitLab 17.9에서 populate_and_use_build_source_table이라는 플래그와 함께 Job 소스가 도입됨. 기본적으로 활성화됨.
• GitLab 17.11에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 일반 가용.

GitLab CI/CD Job에는 Job을 트리거한 작업을 나타내는 소스 속성이 포함됩니다. 이 속성을 사용하여 Job이 시작된 방식을 추적하거나 특정 소스를 기반으로 Job 실행을 필터링합니다.

사용 가능한 Job 소스#

소스 속성은 다음 값을 가질 수 있습니다:

• api: Jobs API에 대한 REST 호출로 시작된 Job.
• chat: GitLab ChatOps를 사용하는 채팅 명령으로 시작된 Job.
• container_registry_push: 컨테이너 레지스트리 푸시로 시작된 Job.
• duo_workflow: GitLab Duo Agent Platform으로 시작된 Job.
• external: GitLab과 통합된 외부 리포지터리의 이벤트로 시작된 Job. 풀 리퀘스트 이벤트는 포함되지 않습니다.
• external_pull_request_event: 외부 리포지터리의 풀 리퀘스트 이벤트로 시작된 Job.
• merge_request_event: 머지 리퀘스트 이벤트로 시작된 Job.
• ondemand_dast_scan: 온디맨드 DAST 스캔으로 시작된 Job.
• ondemand_dast_validation: 온디맨드 DAST 유효성 검사로 시작된 Job.
• parent_pipeline: 상위 파이프라인으로 시작된 Job.
• pipeline: 사용자가 수동으로 파이프라인을 실행하여 시작된 Job.
• pipeline_execution_policy: 파이프라인 실행 정책으로 시작된 Job.
• pipeline_execution_policy_schedule: 예약된 파이프라인 실행 정책으로 시작된 Job.
• push: 코드 푸시로 시작된 Job.
• scan_execution_policy: 스캔 실행 정책으로 시작된 Job.
• schedule: 예약된 파이프라인으로 시작된 Job.
• security_orchestration_policy: 예약된 스캔 실행 정책으로 시작된 Job.
• trigger: 다른 Job 또는 파이프라인으로 시작된 Job.
• unknown: 알 수 없는 소스로 시작된 Job.
• web: GitLab UI에서 사용자가 시작한 Job.
• webide: Web IDE에서 사용자가 시작한 Job.

파이프라인 뷰에서 유사한 Job 그룹화#

유사한 Job이 많은 경우 파이프라인 그래프가 길어지고 읽기 어려워집니다.

유사한 Job을 자동으로 그룹화할 수 있습니다. Job 이름이 특정 방식으로 형식이 지정되면 일반 파이프라인 그래프(미니 그래프 제외)에서 단일 그룹으로 축소됩니다.

재시도 또는 취소 버튼 대신 Job 이름 옆에 숫자가 표시되면 파이프라인에 그룹화된 Job이 있음을 알 수 있습니다. 숫자는 그룹화된 Job의 수를 나타냅니다. 해당 Job 위에 마우스를 올리면 모든 Job이 통과했는지 또는 실패한 Job이 있는지 확인할 수 있습니다. 선택하면 확장됩니다.

Job 그룹을 만들려면 .gitlab-ci.yml 파일에서 각 Job 이름을 숫자와 다음 중 하나로 구분합니다:

• 앞 또는 뒤 슬래시(/ 또는 \), 예: slash-test 1/3, slash-test 2/3, slash-test 3/3.
• 콜론(:), 예: colon-test 1:3, colon-test 2:3, colon-test 3:3.
• 공백, 예: space-test 0 3, space-test 1 3, space-test 2 3.

이러한 기호는 서로 바꿔서 사용할 수 있습니다.

다음 예시에서 이 세 가지 Job은 build ruby라는 그룹에 있습니다:

build ruby 1/3:
  stage: build
  script:
    - echo "ruby1"

build ruby 2/3:
  stage: build
  script:
    - echo "ruby2"

build ruby 3/3:
  stage: build
  script:
    - echo "ruby3"

파이프라인 그래프는 세 개의 Job이 있는 build ruby라는 그룹을 표시합니다.

Job은 왼쪽에서 오른쪽으로 숫자를 비교하여 정렬됩니다. 일반적으로 첫 번째 숫자가 인덱스이고 두 번째 숫자가 전체 수입니다.

Job 재시도#

완료 후 최종 상태(실패, 성공 또는 취소)에 관계없이 Job을 재시도할 수 있습니다.

Job을 재시도하면:

• 새 Job ID로 새 Job 인스턴스가 생성됩니다.
• Job은 원래 Job과 동일한 파라미터 및 변수로 실행됩니다.
• Job이 아티팩트를 생성하면 새 아티팩트가 생성되고 저장됩니다.
• 새 Job은 원래 파이프라인을 만든 사용자가 아니라 재시도를 시작한 사용자와 연결됩니다.
• 이전에 건너뛴 후속 Job은 재시도를 시작한 사용자에게 재할당됩니다.

다운스트림 파이프라인을 트리거하는 트리거 Job을 재시도하면:

• 트리거 Job은 새 다운스트림 파이프라인을 생성합니다.
• 다운스트림 파이프라인도 재시도를 시작한 사용자와 연결됩니다.
• 다운스트림 파이프라인은 재시도 시점에 존재하는 구성으로 실행되며, 원래 실행과 다를 수 있습니다.

Job 재시도#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
• Job이 아카이브되지 않아야 합니다.

머지 리퀘스트에서 Job을 재시도하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 머지 리퀘스트에서 다음 중 하나를 수행합니다:
   • 파이프라인 위젯에서 재시도하려는 Job 옆에서 Run again([retry])을 선택합니다.
   • Pipelines 탭을 선택하고 재시도하려는 Job 옆에서 Run again([retry])을 선택합니다.

Job 로그에서 Job을 재시도하려면:

1. Job의 로그 페이지로 이동합니다.
2. 오른쪽 상단 모서리에서 Run again([retry])을 선택합니다.

파이프라인에서 Job을 재시도하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 재시도하려는 Job이 포함된 파이프라인을 찾습니다.
4. 파이프라인 그래프에서 재시도하려는 Job 옆에서 Run again([retry])을 선택합니다.

파이프라인에서 실패하거나 취소된 모든 Job 재시도#

파이프라인에 실패하거나 취소된 Job이 여러 개 있는 경우 한 번에 모두 재시도할 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 다음 중 하나를 수행합니다:
   • Build > Pipelines를 선택합니다.
   • 머지 리퀘스트로 이동하여 Pipelines 탭을 선택합니다.
3. 실패하거나 취소된 Job이 있는 파이프라인에서 Retry all failed or canceled jobs([retry])를 선택합니다.

Job 취소#

아직 완료되지 않은 CI/CD Job을 취소할 수 있습니다.

Job을 취소하면 상태와 GitLab Runner 버전에 따라 다음이 발생합니다:

• 아직 실행을 시작하지 않은 Job의 경우 Job이 즉시 취소됩니다.
• 실행 중인 Job의 경우:
  • GitLab 17.0 이상에서 GitLab Runner 16.10 이상의 경우:
    1. Job이 canceling으로 표시됩니다.
    2. 현재 실행 중인 명령이 완료되도록 허용됩니다. Job의 before_script 또는 script의 나머지 명령은 건너뜁니다.
    3. Job에 after_script 섹션이 있으면 항상 시작되고 완료될 때까지 실행됩니다.
    4. Job이 canceled로 표시됩니다.
  • GitLab 16.11 이하에서 GitLab Runner 16.9 이하의 경우, after_script 실행 없이 Job이 즉시 canceled됩니다.

after_script를 기다리지 않고 Job을 즉시 취소해야 하는 경우 강제 취소를 사용합니다.

Job 취소#

사전 요구 사항:

• 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한이 있거나, 파이프라인 또는 Job을 취소할 수 있는 최소 권한이 있어야 합니다.

머지 리퀘스트에서 Job을 취소하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 머지 리퀘스트에서 다음 중 하나를 수행합니다:
   • 파이프라인 위젯에서 취소하려는 Job 옆에서 Cancel([cancel])을 선택합니다.
   • Pipelines 탭을 선택하고 취소하려는 Job 옆에서 Cancel([cancel])을 선택합니다.

Job 로그에서 Job을 취소하려면:

1. Job의 로그 페이지로 이동합니다.
2. 오른쪽 상단 모서리에서 Cancel([cancel])을 선택합니다.

파이프라인에서 Job을 취소하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 취소하려는 Job이 포함된 파이프라인을 찾습니다.
4. 파이프라인 그래프에서 취소하려는 Job 옆에서 Cancel([cancel])을 선택합니다.

파이프라인의 실행 중인 모든 Job 취소#

실행 중인 파이프라인의 모든 Job을 한 번에 취소할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 다음 중 하나를 수행합니다:
   • Build > Pipelines를 선택합니다.
   • 머지 리퀘스트로 이동하여 Pipelines 탭을 선택합니다.
3. 취소하려는 파이프라인에서 Cancel the running pipeline([cancel])을 선택합니다.

Job 강제 취소#

히스토리

• GitLab 17.10에서 force_cancel_build라는 플래그와 함께 실험으로 도입됨. 기본적으로 비활성화됨.
• GitLab 17.11에서 일반 가용. 기능 플래그 force_cancel_build 제거됨.

after_script가 완료되기를 기다리고 싶지 않거나 Job이 응답하지 않는 경우 강제 취소할 수 있습니다. 강제 취소는 Job을 canceling 상태에서 canceled로 즉시 이동합니다.

Job을 강제 취소하면 Job 토큰이 즉시 취소됩니다. 러너가 여전히 Job을 실행 중이면 GitLab에 대한 액세스 권한을 잃습니다. 러너는 after_script가 완료될 때까지 기다리지 않고 Job을 중단합니다.

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.
• Job이 canceling 상태여야 합니다. 이를 위해서는 다음이 필요합니다:
  • GitLab 17.0 이상.
  • GitLab Runner 16.10 이상.

Job을 강제 취소하려면:

1. Job의 로그 페이지로 이동합니다.
2. 오른쪽 상단 모서리에서 Force cancel을 선택합니다.

실패한 Job 문제 해결#

파이프라인이 실패하거나 실패가 허용된 경우, 이유를 찾을 수 있는 여러 위치가 있습니다:

• 파이프라인 세부 정보 뷰의 파이프라인 그래프.
• 머지 리퀘스트 및 커밋 페이지의 파이프라인 위젯.
• Job의 전역 및 상세 뷰에 있는 Job 뷰.

각 위치에서 실패한 Job 위에 마우스를 올리면 실패 이유를 볼 수 있습니다.

Job 세부 정보 페이지에서도 실패 이유를 볼 수 있습니다.

근본 원인 분석 사용#

GitLab Duo Chat에서 GitLab Duo 근본 원인 분석을 사용하여 실패한 CI/CD Job을 문제 해결할 수 있습니다.

배포 Job#

배포 Job은 환경을 사용하는 CI/CD Job입니다. 배포 Job은 environment 키워드와 start 환경 action을 사용하는 모든 Job입니다. 배포 Job은 deploy Stage에 있을 필요가 없습니다. 다음 deploy me Job은 배포 Job의 예시입니다. action: start가 기본 동작이며 명확성을 위해 여기에 정의되었지만 생략할 수 있습니다:

deploy me:
  script:
    - deploy-to-cats.sh
  environment:
    name: production
    url: https://cats.example.com
    action: start

배포 Job의 동작은 오래된 배포 Job 방지 및 한 번에 하나의 배포 Job만 실행 보장과 같은 배포 안전성 설정으로 제어할 수 있습니다.