잡 실행 흐름

잡 실행 흐름 (Job execution flow)

잡 실행 흐름은 GitLab Runner가 CI/CD 잡을 처음부터 끝까지 어떻게 처리하는지를 설명해요. GitLab Runner는 잡을 받고, (설정되어 있다면) 볼트(vault)에서 시크릿을 가져오고, executor를 준비한 뒤에 CI/CD 잡을 실행해요.

모든 CI/CD 잡은 일련의 순차적 단계로 실행되며, 각 단계는 별도의 셸 컨텍스트에서 실행돼요. Runner는 이렇게 처리해요:

잡을 위한 소스 코드를 준비해요: 셸 컨텍스트에 변수를 내보냄 · 구성에 pre_get_sources_script가 정의되어 있으면 실행 · none 전략이 구성되지 않았다면 git fetch와 기타 소스 처리 명령 실행 · 서브모듈이 있으면 업데이트 명령 실행 · 구성에 post_get_sources_script가 정의되어 있으면 실행
cache가 구성되어 있고 이전 단계가 성공했다면 캐시된 파일을 다운로드해요: 셸 컨텍스트에 변수를 내보냄 · 이전 잡 실행에서 캐시된 파일을 다운로드하는 명령 실행
아티팩트 다운로드가 구성되어 있고 이전 단계가 성공했다면 이전 잡의 아티팩트를 다운로드해요: 셸 컨텍스트에 변수를 내보냄 · 이전 잡에서 아티팩트 파일을 다운로드하는 명령 실행
이전 단계가 성공했다면 주요 잡 스크립트를 실행해요: 셸 컨텍스트에 변수를 내보냄 · 구성에 pre_build_script가 정의되어 있으면 실행 · before_script 명령이 정의되어 있으면 실행 · 주요 script 명령 실행 · 구성에 post_build_script가 정의되어 있으면 실행
이전 단계가 실패했든 아니든, after_script 명령이 정의되어 있으면 실행해요: 새 셸 컨텍스트에 변수를 내보냄 · after_script 명령 실행 · 이 명령의 실패는 전체 잡 상태에 영향을 주지 않아요
캐시 업로드가 구성되어 있고 이전 단계가 실패했든 아니든, 파일을 캐시에 업로드해요: 셸 컨텍스트에 변수를 내보냄 · 지정된 파일을 캐시 저장소에 업로드하는 명령 실행 · 이 단계의 실패는 전체 잡 상태에 영향을 줄 수 있어요
아티팩트 업로드가 구성되어 있고 이전 단계가 실패했든 아니든, 아티팩트를 업로드해요: 셸 컨텍스트에 변수를 내보냄 · 지정된 파일을 잡 아티팩트로 업로드하는 명령 실행 · 이 단계의 실패는 전체 잡 상태에 영향을 줄 수 있어요
referee 업로드가 구성되어 있고 이전 단계가 실패했든 아니든, referee 데이터를 업로드해요: 셸 컨텍스트에 변수를 내보냄 · referee 정보를 업로드하는 명령 실행 · 이 명령의 실패는 전체 잡 상태에 영향을 주지 않아요
정리 작업이 구성되어 있고 이전 단계가 실패했든 아니든, 정리 작업을 수행해요: 셸 컨텍스트에 변수를 내보냄 · 작업 디렉터리에서 파일 기반 변수를 삭제하는 명령 실행 · 이 명령의 실패는 전체 잡 상태에 영향을 주지 않아요

%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
    accTitle: GitLab CI/CD Job Execution Flow
    accDescr: Shows the complete 9-step job execution sequence from source preparation through cleanup operations.

    Start([Job Starts]) --> Source[1. Source preparation<br/><small>Export variables, runs <code>pre_get_sources_script</code>,</small><br/><small><code>git fetch</code>, submodules, <code>post_get_sources_script</code>.</small>]

    Source --> Cache[2. Download cache<br/><small>If configured and previous step succeeds.</small>]

    Cache --> Artifacts[3. Download artifacts<br/><small>If configured and previous step succeeds.</small>]

    Artifacts --> MainExec[4. Main execution<br/><small>Export variables, <code>pre_build_script</code>,</small><br/><small><code>before_script</code>, <code>script</code>, <code>post_build_script</code>.</small>]

    MainExec --> AfterScript[5. <code>after_script</code><br/><small>Always runs if defined.</small><br/><small>Files created here are included.</small>]

    AfterScript --> Critical[⚠️ CRITICAL: <code>after_script</code> runs BEFORE upload stages.]

    Critical --> UploadCache[6. Upload cache<br/><small>Always runs if configured.</small><br/><small>Failure may affect job status.</small>]

    Critical --> UploadArtifacts[7. Upload artifacts<br/><small>Always runs if configured.</small><br/><small>Failure may affect job status.</small>]

    UploadCache --> UploadReferees[8. Upload referees<br/><small>Always runs if configured.</small><br/><small>Failure doesn't affect job status.</small>]

    UploadArtifacts --> UploadReferees

    UploadReferees --> Cleanup[9. Cleanup operations<br/><small>Always runs if configured.</small><br/><small>Delete file-based variables.</small>]

    Cleanup --> End([Job Complete])

출처: 문서

본문

셸 컨텍스트 격리

각 셸 컨텍스트는 설계상 격리되어 있어요. 컨텍스트 사이의 유일한 연결은 공유 작업 디렉터리 파일 시스템이에요.

한 컨텍스트에서의 수동 변수 내보내기(예: export my_variable=$(date))는 다른 컨텍스트에서 사용할 수 없어요
각 스크립트는 첫 오류에서 일찍 실패하도록 (Unix 셸의 경우) set -eo pipefail로 실행돼요
각 단계의 결과는 후속 단계가 실행될지 여부와 전체 잡 상태에 영향을 줘요

더 알아보기

다음으로는 잡 아티팩트와 캐시 문서를 함께 보면 잡 실행 중 다운로드·업로드되는 데이터를 제대로 구성하는 방법을 익힐 수 있어요. after_script는 업로드 단계보다 먼저 실행된다는 점을 꼭 기억하세요!