작업 실행 방식 제어
새로운 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 실행해야 할 작업을 결정하기 위해 파이프라인 구성을 확인합니다. 변수의 상태나 파이프라인 유형과 같은 요소에 따라 작업을 실행하도록 구성할 수 있습니다.
특정 파이프라인에서 작업을 포함하거나 제외하려면 rules를 사용하세요.
needs를 사용하여 작업을 구성하여 이전 작업이 완료되는 즉시 실행되도록 할 수 있습니다.
매뉴얼으로 실행되어야 하는 작업 만들기
작업이 사용자에 의해 시작되지 않으면 실행되지 않도록 요구할 수 있습니다. 이를 매뉴얼 작업이라고 합니다. 예를 들어, 프로덕션 배포와 같은 작업에 매뉴얼 작업을 사용하고 싶을 수 있습니다.
작업을 매뉴얼으로 지정하려면 .gitlab-ci.yml 파일에서 작업에 when: manual을 추가하세요.
기본적으로 매뉴얼 작업은 파이프라인이 시작될 때 건너뛰기로 표시됩니다.
protected branches를 사용하여 무단으로 매뉴얼 배포를 방지할 수 있습니다.
매뉴얼 작업의 유형
매뉴얼 작업은 선택적일 수도 있고 차단할 수도 있습니다.
선택적 매뉴얼 작업:
-
allow_failure가true이며, 이것이when: manual이고rules또는rules바깥에when: manual이 정의되지 않은 작업의 기본 설정입니다. - 상태가 전체 파이프라인 상태에 기여하지 않습니다. 매뉴얼 작업이 모두 실패해도 파이프라인은 성공할 수 있습니다.
차단된 매뉴얼 작업:
-
allow_failure가false이며,기안에when: manual이 정의된 작업의 기본 설정입니다. - 파이프라인은 작업이 정의된 단계에서 중지됩니다. 파이프라인을 계속 실행하려면 매뉴얼 작업을 실행하십시오.
- 파이프라인이 차단된 경우 합병 요청은 차단된 파이프라인으로 Merge할 수 없습니다.
- 파이프라인은 차단됨 상태로 표시됩니다.
매뉴얼 작업을 사용하여 strategy: depend로 트리거된 파이프라인에서 매뉴얼 작업의 유형이 파이프라인 실행 중인 동안 트리거 작업의 상태에 영향을 줄 수 있습니다.
매뉴얼 작업 실행
매뉴얼 작업을 실행하려면 할당된 브랜치에 대한 Merge 권한이 있어야 합니다:
- 파이프라인, 작업, 환경, 또는 배포 보기로 이동합니다.
- 매뉴얼 작업 옆에 실행 ()을 선택합니다.
매뉴얼 작업을 실행할 때 사용자 정의 CI/CD 변수를 추가할 수도 있습니다.
매뉴얼 작업 보호
보호된 환경을 사용하여 매뉴얼 작업을 실행할 권한이 있는 사용자 디렉터리을 정의할 수 있습니다. 보호된 환경과 관련된 사용자만 매뉴얼 작업을 트리거할 수 있습니다. 이를 통해 다음과 같은 작업이 가능합니다.
- 특정 환경에 배포할 수 있는 사용자를 더 정확하게 제한할 수 있습니다.
- 승인된 사용자가 파이프라인을 “승인”할 때까지 파이프라인을 차단할 수 있습니다.
매뉴얼 작업을 보호하려면:
-
작업에
environment를 추가합니다. 예:deploy_prod: stage: deploy script: - echo "프로덕션 서버에 배포" environment: name: production url: https://example.com when: manual rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH -
보호된 환경 설정에서 환경(
production이 예제에서)을 선택하고 트리거할 수 있는 사용자, 역할 또는 그룹을 허용된 배포 대상 디렉터리에 추가합니다. 이 디렉터리에 있는 사용자만 이 매뉴얼 작업을 트리거할 수 있으며, 항상 보호된 환경을 사용할 수 있는 GitLab 관리자입니다.
차단된 매뉴얼 작업과 함께 보호된 환경을 사용하여 나중에 파이프라인 단계를 승인할 수 있는 사용자 디렉터리을 지정할 수 있습니다. 보호된 매뉴얼 작업에 allow_failure: false을 추가하고, 트리거된 매뉴얼 작업이 인가된 사용자에 의해 트리거된 후에 파이프라인의 다음 단계만 실행할 수 있도록 할 수 있습니다.
지연 후 작업 실행
when: delayed를 사용하여 스크립트를 일정 기간 후에 실행하거나 작업이 즉시 보류 상태로 진입하는 것을 피하려는 경우에 사용합니다.
start_in 키워드로 기간을 설정할 수 있습니다. start_in 값은 시간 단위로 제공되는 경과 시간으로, 단위가 지정되지 않으면 최소 1초에서 최대 1주일까지의 값을 가질 수 있습니다. 유효한 값의 예로는 다음과 같습니다.
-
'5'(단위가 없는 값은 따옴표로 둘러싸여야 합니다) 5 seconds30 minutes1 day1 week
지연된 작업이 포함된 스테이지가 있는 경우 파이프라인은 지연된 작업이 완료될 때까지 진행되지 않습니다. 이 키워드를 사용하여 다른 스테이지 간에 지연을 삽입할 수 있습니다.
지연된 작업의 타이머는 이전 스테이지가 완료된 즉시 시작합니다. 다른 유형의 작업과 마찬가지로, 지연된 작업의 타이머는 이전 스테이지가 통과되지 않으면 시작되지 않습니다.
다음 예제는 이전 스테이지 완료 후 30분 후에 실행되는 timed rollout 10%라는 작업을 생성합니다.
timed rollout 10%:
stage: deploy
script: echo '10% 배포 중...'
when: delayed
start_in: 30 minutes
environment: production
지연된 작업의 활성 타이머를 중지하려면 예약 취소()를 선택합니다. 이제 이 작업은 자동으로 예약될 수 없습니다. 그러나 매뉴얼으로 작업을 실행할 수는 있습니다.
지연된 작업을 매뉴얼으로 시작하려면 예약 취소()를 선택하여 대기 타이머를 중지하고, 다음으로 실행()을 선택하십시오. 그러면 GitLab Runner가 곧 작업을 시작합니다.
큰 작업을 병렬화하기
큰 작업을 여러 개의 병렬 작업으로 분할하여 실행하려면 .gitlab-ci.yml 파일에서 parallel 키워드를 사용하세요.
다양한 언어 및 테스트 스위트에는 병렬화를 활성화하는 다양한 방법이 있습니다. 예를 들어 Semaphore Test Boosters 및 RSpec을 사용하여 루비 테스트를 병렬로 실행할 수 있습니다.
일차원 배열의 병렬 작업 실행
일차원 배열의 병렬 작업을 생성할 수 있습니다.
deploystacks:
stage: deploy
script:
- bin/deploy
parallel:
matrix:
- PROVIDER: [aws, ovh, gcp, vultr]
environment: production/$PROVIDER
또한 다차원 배열을 생성할 수 있습니다.
병렬 트리거 작업의 매트릭스 실행
단일 파이프라인에서 변수 값이 각각 다른 여러 인스턴스에 대해 트리거 작업을 병렬로 여러 번 실행할 수 있습니다.
deploystacks:
stage: deploy
trigger:
include: path/to/child-pipeline.yml
parallel:
matrix:
- PROVIDER: aws
STACK: [monitoring, app1]
- PROVIDER: ovh
STACK: [monitoring, backup]
- PROVIDER: [gcp, vultr]
STACK: [data]
이 예제는 PROVIDER 및 STACK에 대해 값이 다른 6개의 병렬 deploystacks 트리거 작업을 생성하며, 각각이 해당 변수로 6개의 다른 자식 파이프라인을 생성합니다.
deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [gcp, data]
deploystacks: [vultr, data]
병렬 매트릭스 작업 별로 다른 러너 태그 선택
parallel: matrix에서 정의된 변수를 동적 러너 선택을 위해 tags 키워드와 함께 사용할 수 있습니다.
deploystacks:
stage: deploy
parallel:
matrix:
- PROVIDER: aws
STACK: [monitoring, app1]
- PROVIDER: gcp
STACK: [data]
tags:
- ${PROVIDER}-${STACK}
environment: $PROVIDER/$STACK
parallel:matrix 작업에서 아티팩트 가져오기
parallel:matrix로 생성된 작업에서 아티팩트를 가져올 수 있습니다. 이를 위해 dependencies 키워드를 사용하세요. dependencies의 값을 다음과 같이 문자열 형식으로 작업 이름을 사용합니다.
<job_name> [<matrix argument 1>, <matrix argument 2>, ... <matrix argument N>]
예를 들어, RUBY_VERSION이 2.7이고 PROVIDER가 aws인 작업에서 아티팩트를 가져오려면:
ruby:
image: ruby:${RUBY_VERSION}
parallel:
matrix:
- RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
PROVIDER: [aws, gcp]
script: bundle install
deploy:
image: ruby:2.7
stage: deploy
dependencies:
- "ruby: [2.7, aws]"
script: echo hello
environment: production
dependencies 항목에 따옴표를 붙여야 합니다.
여러 병렬화된 작업이 needs와 함께 병렬 작업을 지정
여러 병렬화된 작업에 needs:parallel:matrix에서 정의된 변수를 사용할 수 있습니다.
예를 들어:
linux:build:
stage: build
script: echo "Building linux..."
parallel:
matrix:
- PROVIDER: aws
STACK:
- monitoring
- app1
- app2
mac:build:
stage: build
script: echo "Building mac..."
parallel:
matrix:
- PROVIDER: [gcp, vultr]
STACK: [data, processing]
linux:rspec:
stage: test
needs:
- job: linux:build
parallel:
matrix:
- PROVIDER: aws
STACK: app1
script: echo "Running rspec on linux..."
mac:rspec:
stage: test
needs:
- job: mac:build
parallel:
matrix:
- PROVIDER: [gcp, vultr]
STACK: [data]
script: echo "Running rspec on mac..."
production:
stage: deploy
script: echo "Running production..."
environment: production
이 예제에서 각 병렬 작업은 PROVIDER와 STACK에 대해 다른 값을 갖습니다.
- 3개의 병렬
linux:build작업:linux:build: [aws, monitoring]linux:build: [aws, app1]linux:build: [aws, app2]
- 4개의 병렬
mac:build작업:mac:build: [gcp, data]mac:build: [gcp, processing]mac:build: [vultr, data]mac:build: [vultr, processing]
-
linux:rspec작업 -
production작업
작업에는 세 가지 실행 경로가 있습니다.
- Linux 경로:
linux:rspec작업은linux:build: [aws, app1]작업이 끝나자마자 실행되며,mac:build가 끝나기를 기다리지 않습니다. - macOS 경로:
mac:rspec작업은mac:build: [gcp, data]와mac:build: [vultr, data]작업이 끝나자마자 실행되며,linux:build가 끝나기를 기다리지 않습니다. - 이전 작업이 모두 끝나면
production작업이 실행됩니다.
도움말