작업 실행 방식 제어

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

새로운 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 실행해야 할 작업을 결정하기 위해 파이프라인 구성을 확인합니다. 변수의 상태나 파이프라인 유형과 같은 요소에 따라 작업을 실행하도록 구성할 수 있습니다.

특정 파이프라인에서 작업을 포함하거나 제외하려면 rules를 사용하세요.

needs를 사용하여 작업을 구성하여 이전 작업이 완료되는 즉시 실행되도록 할 수 있습니다.

매뉴얼으로 실행되어야 하는 작업 만들기

작업이 사용자에 의해 시작되지 않으면 실행되지 않도록 요구할 수 있습니다. 이를 매뉴얼 작업이라고 합니다. 예를 들어, 프로덕션 배포와 같은 작업에 매뉴얼 작업을 사용하고 싶을 수 있습니다.

작업을 매뉴얼으로 지정하려면 .gitlab-ci.yml 파일에서 작업에 when: manual을 추가하세요.

기본적으로 매뉴얼 작업은 파이프라인이 시작될 때 건너뛰기로 표시됩니다.

protected branches를 사용하여 무단으로 매뉴얼 배포를 방지할 수 있습니다.

매뉴얼 작업의 유형

매뉴얼 작업은 선택적일 수도 있고 차단할 수도 있습니다.

선택적 매뉴얼 작업:

  • allow_failuretrue이며, 이것이 when: manual이고 rules 또는 rules 바깥에 when: manual이 정의되지 않은 작업의 기본 설정입니다.
  • 상태가 전체 파이프라인 상태에 기여하지 않습니다. 매뉴얼 작업이 모두 실패해도 파이프라인은 성공할 수 있습니다.

차단된 매뉴얼 작업:

  • allow_failurefalse이며, 안에 when: manual이 정의된 작업의 기본 설정입니다.
  • 파이프라인은 작업이 정의된 단계에서 중지됩니다. 파이프라인을 계속 실행하려면 매뉴얼 작업을 실행하십시오.
  • 파이프라인이 차단된 경우 합병 요청은 차단된 파이프라인으로 Merge할 수 없습니다.
  • 파이프라인은 차단됨 상태로 표시됩니다.

매뉴얼 작업을 사용하여 strategy: depend로 트리거된 파이프라인에서 매뉴얼 작업의 유형이 파이프라인 실행 중인 동안 트리거 작업의 상태에 영향을 줄 수 있습니다.

매뉴얼 작업 실행

매뉴얼 작업을 실행하려면 할당된 브랜치에 대한 Merge 권한이 있어야 합니다:

  1. 파이프라인, 작업, 환경, 또는 배포 보기로 이동합니다.
  2. 매뉴얼 작업 옆에 실행 ()을 선택합니다.

매뉴얼 작업을 실행할 때 사용자 정의 CI/CD 변수를 추가할 수도 있습니다.

매뉴얼 작업 보호

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

보호된 환경을 사용하여 매뉴얼 작업을 실행할 권한이 있는 사용자 디렉터리을 정의할 수 있습니다. 보호된 환경과 관련된 사용자만 매뉴얼 작업을 트리거할 수 있습니다. 이를 통해 다음과 같은 작업이 가능합니다.

  • 특정 환경에 배포할 수 있는 사용자를 더 정확하게 제한할 수 있습니다.
  • 승인된 사용자가 파이프라인을 “승인”할 때까지 파이프라인을 차단할 수 있습니다.

매뉴얼 작업을 보호하려면:

  1. 작업에 environment를 추가합니다. 예:

    deploy_prod:
      stage: deploy
      script:
        - echo "프로덕션 서버에 배포"
      environment:
        name: production
        url: https://example.com
      when: manual
      rules:
        - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    
  2. 보호된 환경 설정에서 환경(production 이 예제에서)을 선택하고 트리거할 수 있는 사용자, 역할 또는 그룹을 허용된 배포 대상 디렉터리에 추가합니다. 이 디렉터리에 있는 사용자만 이 매뉴얼 작업을 트리거할 수 있으며, 항상 보호된 환경을 사용할 수 있는 GitLab 관리자입니다.

차단된 매뉴얼 작업과 함께 보호된 환경을 사용하여 나중에 파이프라인 단계를 승인할 수 있는 사용자 디렉터리을 지정할 수 있습니다. 보호된 매뉴얼 작업에 allow_failure: false을 추가하고, 트리거된 매뉴얼 작업이 인가된 사용자에 의해 트리거된 후에 파이프라인의 다음 단계만 실행할 수 있도록 할 수 있습니다.

지연 후 작업 실행

when: delayed를 사용하여 스크립트를 일정 기간 후에 실행하거나 작업이 즉시 보류 상태로 진입하는 것을 피하려는 경우에 사용합니다.

start_in 키워드로 기간을 설정할 수 있습니다. start_in 값은 시간 단위로 제공되는 경과 시간으로, 단위가 지정되지 않으면 최소 1초에서 최대 1주일까지의 값을 가질 수 있습니다. 유효한 값의 예로는 다음과 같습니다.

  • '5' (단위가 없는 값은 따옴표로 둘러싸여야 합니다)
  • 5 seconds
  • 30 minutes
  • 1 day
  • 1 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을 사용하여 루비 테스트를 병렬로 실행할 수 있습니다.

caution
Test Boosters는 작성자에게 사용 통계를 보고합니다.

일차원 배열의 병렬 작업 실행

일차원 배열의 병렬 작업을 생성할 수 있습니다.

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]

이 예제는 PROVIDERSTACK에 대해 값이 다른 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_VERSION2.7이고 PROVIDERaws인 작업에서 아티팩트를 가져오려면:

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

이 예제에서 각 병렬 작업은 PROVIDERSTACK에 대해 다른 값을 갖습니다.

  • 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 작업이 실행됩니다.