• rules를 사용하여 작업 실행 시점 지정
  • rules 예시
    • 예약된 파이프라인에 대해 작업 실행
    • 브랜치가 비어 있는 경우 작업 건너뛰기
  • 복잡한 rules
  • 중복 파이프라인 피하기
  • rules의 일반적인 if 절
  • rules:changes의 변수
  • 다른 작업에서 규칙 재사용
• only 및 except로 작업 실행 시기 지정
  • only:refs / except:refs 예제
  • only: 변수 / except: 변수 예제
  • only:changes / except:changes 예제
    • 합병 요청 파이프라인에서 only:changes 사용
  • only 또는 except로 여러 키워드를 결합
• 매뉴얼으로 실행해야 하는 작업 생성
  • 매뉴얼 작업 유형
  • 매뉴얼 작업 실행
  • 매뉴얼 작업 보호
• 지연 후 작업 실행
• 대규모 작업 병렬화
  • 일차원 병렬 작업 행렬 실행
  • 병렬 트리거 작업 행렬 실행
  • 각 병렬 행렬 작업에 다른 실행자 태그 지정
    • parallel: matrix 작업에서 artifact 가져오기
• 여러 병렬화된 작업을 필요로 하는 needs를 사용해 병렬화된 작업 지정
• 미리 정의된 CI/CD 변수 사용하여 특정 파이프라인 유형에서 작업 실행
• 정규 표현식
  • only / except 정규 표현식 구문
• CI/CD 변수 표현식
  • 변수와 문자열 비교
  • 두 변수 비교
  • 변수가 정의되지 않은지 확인
  • 변수가 비어 있는지 확인
  • 변수의 존재 여부 확인
  • 변수를 정규 표현식 패턴과 비교
    • 정규 표현식 패턴을 변수에 저장
  • 변수 식을 && 또는 ||로 결합
    • 변수 식을 괄호로 그룹화

작업 실행 시점 선택

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

특정 파이프라인에서 특정 작업을 포함하거나 제외하도록 작업 구성하려면 rules를 사용합니다.

이전에 종속되는 작업이 실행을 마치자마자 작업이 실행되도록 구성하려면 needs를 사용하세요.

rules를 사용하여 작업 실행 시점 지정

• 소개됨 in GitLab 12.3.

rules를 사용하여 파이프라인에서 작업을 포함하거나 제외합니다.

Rules는 처음으로 일치하는 항목이 나올 때까지 순서대로 평가됩니다. 일치하는 항목을 찾으면 작업은 설정에 따라 파이프라인에 포함되거나 제외됩니다. 자세한 내용은 rules 참조를 확인하세요.

향후 키워드 개선 사항은 누구나 제안이나 요청을 추가할 수 있는 rules 개선에 대한 에픽에서 논의 중입니다.

rules 예시

다음 예시는 if를 사용하여 작업이 특정 두 가지 경우에만 실행되도록 정의합니다:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true
    - if: $CI_PIPELINE_SOURCE == "schedule"

• 파이프라인이 Merge Request용이면, 첫 번째 rule이 일치하게 되고, 작업은 다음과 같은 속성을 가진 Merge Request 파이프라인에 추가됩니다:
  • when: manual (매뉴얼 작업)
  • allow_failure: true (매뉴얼 작업이 실행되지 않아도 파이프라인은 계속 실행됨)
• 파이프라인이 Merge Request을 위한 것이 아니면, 첫 번째 rule이 일치하지 않고 두 번째 rule이 평가됩니다.
• 파이프라인이 예약된 파이프라인인 경우, 두 번째 rule이 일치하고 작업이 예약된 파이프라인에 추가됩니다. 속성이 정의되지 않았으므로 다음과 같은 속성으로 추가됩니다:
  • when: on_success (기본값)
  • allow_failure: false (기본값)
• 모든 다른 경우에는 어떤 rule도 일치하지 않아서 작업은 다른 어떤 파이프라인에 추가되지 않습니다.

또는 몇 가지 경우를 제외하고 모든 다른 경우에 작업을 실행하도록 rule 집합을 정의할 수 있습니다:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - when: on_success

• 파이프라인이 Merge Request을 위한 것이면, 작업은 파이프라인에 추가되지 않습니다.
• 파이프라인이 예약된 파이프라인을 위한 것이면, 작업은 파이프라인에 추가되지 않습니다.
• 다른 모든 경우에는 작업은 파이프라인에 추가되며 when: on_success로 실행됩니다.

예약된 파이프라인에 대해 작업 실행

작업을 예약된 파이프라인에서만 실행되도록 구성하려면 rules 키워드를 사용하세요.

다음 예시에서 make world는 예약된 파이프라인에서 실행되고, make build는 브랜치 및 태그 파이프라인에서 실행됩니다:

job:on-schedule:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - make world

job:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
  script:
    - make build

브랜치가 비어 있는 경우 작업 건너뛰기

rules:changes:compare_to를 사용하여 브랜치가 비어 있는 경우 작업을 실행하지 않고 CI/CD 리소스를 절약할 수 있습니다. 브랜치를 기본 브랜치와 비교하고, 브랜치에 대해:

• 변경된 파일이 없으면, 작업은 실행되지 않습니다.
• 변경된 파일이 있으면, 작업이 실행됩니다.

예를 들어, 기본 브랜치로 main을 가지는 프로젝트에서:

job:
  script:
    - echo "This job only runs for branches that are not empty"
  rules:
    - if: $CI_COMMIT_BRANCH
      changes:
        compare_to: 'refs/heads/main'
        paths:
          - '*'

이 작업의 rule은 현재 브랜치의 모든 파일과 경로(*)를 기본 브랜치 main과 비교합니다. rule이 일치하면 파일에 변경이 있을 때만 작업이 실행됩니다.

복잡한 rules

if, changes, exists와 같은 모든 rules 키워드를 동일한 rule에서 사용할 수 있습니다. rule은 모두 포함된 키워드가 true일 때만 true로 평가됩니다.

예를 들어:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $VAR == "string value"
      changes:  # 변경된 파일이 있는 경우 작업을 포함하고, 수정된 파일이 경로와 일치하면 when:manual로 설정합니다.
        - Dockerfile
        - docker/scripts/*
      when: manual
      allow_failure: true

만약 Dockerfile 파일이나 /docker/scripts의 파일 중 하나가 변경됐고 그리고 $VAR == “string value”이면, 작업이 매뉴얼으로 실행되고 실패해도 됩니다.

더 복잡한 변수 식을 만들려면 괄호를 사용하여 &&와 ||을 결합하세요. 소개됨 in GitLab 13.3:

job1:
  script:
    - echo This rule uses parentheses.
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

중복 파이프라인 피하기

작업이 rules를 사용하면 브랜치로 커밋을 푸시하는 것과 같은 단일 작업이 여러 파이프라인을 트리거할 수 있습니다. 여러 유형의 파이프라인에 대해 명시적으로 규칙을 설정하지 않아도 실수로 그들을 트리거시킬 수 있습니다.

중복 파이프라인을 유발할 수 있는 일부 구성은 파이프라인 경고가 표시됩니다.

예를 들어:

job:
  script: echo "이 작업은 파이프라인을 두 번 생성합니다!"
  rules:
    - if: $CUSTOM_VARIABLE == "false"
      when: never
    - when: always

이 작업은 $CUSTOM_VARIABLE이 false일 때 실행되지 않지만, 모든 다른 파이프라인에서, 푸시(브랜치) 및 Merge Request 파이프라인을 포함하여 모두 실행됩니다. 이 구성으로 인해 열린 Merge Request의 소스 브랜치에 대한 각 푸시는 중복된 파이프라인을 유발시킵니다.

중복된 파이프라인을 피하려면 다음을 할 수 있습니다:

• workflow를 사용하여 실행할 수 있는 파이프라인 유형을 지정합니다.

• 작업을 매우 구체적인 경우에만 실행하는 규칙으로 다시 작성하고 최종 when 규칙을 피합니다:

  job:
    script: echo "이 작업은 파이프라인을 두 번 생성하지 않습니다!"
    rules:
      - if: $CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"
  

작업 규칙을 변경하여 푸시(브랜치) 파이프라인 또는 Merge Request 파이프라인 중 하나를 피할 수도 있습니다. 그러나 workflow: rules 없이 - when: always 규칙을 사용하는 경우에도 GitLab은 여전히 파이프라인 경고를 표시합니다.

예를 들어, 다음은 중복된 파이프라인을 유발하지 않지만 workflow: rules 없이 권장되지는 않습니다:

job:
  script: echo "이 작업은 파이프라인을 두 번 생성하지 않습니다!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always

동일한 작업에 푸시 및 Merge Request 파이프라인을 모두 포함하지 마십시오. 중복 파이프라인을 방지하는 workflow:rules를 사용하지 않은 경우에는 다음을 권장하지 않습니다:

job:
  script: echo "이 작업은 파이프라인을 두 번 생성합니다!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

또한 동일 파이프라인에 only/except 작업과 rules 작업을 섞지 마십시오. YAML 오류를 유발하지는 않지만 only/except와 rules의 서로 다른 기본 동작은 문제를 유발할 수 있습니다.

job-with-no-rules:
  script: echo "이 작업은 브랜치 파이프라인에서 실행됩니다."

job-with-rules:
  script: echo "이 작업은 Merge Request 파이프라인에서 실행됩니다."
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

브랜치로 푸시할 때마다 중복된 파이프라인이 실행됩니다. 한 브랜치 파이프라인은 단일 작업(job-with-no-rules)을 실행하고, 하나의 Merge Request 파이프라인은 다른 작업(job-with-rules)을 실행합니다. 규칙이 없는 작업은 except: merge_requests에 대한 기본 동작이므로, job-with-no-rules는 Merge Request을 제외한 모든 경우에 실행됩니다.

rules의 일반적인 if 절

only/except 키워드와 유사한 동작을 위해 $CI_PIPELINE_SOURCE 변수의 값을 확인할 수 있습니다:

다음 예제는 예약된 파이프라인이나 푸시(브랜치 또는 태그) 파이프라인에서 when: on_success (기본값)로 매뉴얼 작업으로 실행합니다. 다른 파이프라인 유형에는 작업을 추가하지 않습니다.

job:
  script: echo "안녕, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: manual
      allow_failure: true
    - if: $CI_PIPELINE_SOURCE == "push"

다음 예제는 Merge Request 파이프라인 및 예약된 파이프라인에서 when: on_success로 작업을 실행합니다. 다른 파이프라인 유형에서는 작업을 실행하지 않습니다.

job:
  script: echo "안녕, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "schedule"

if 절에 대한 일반적으로 사용되는 다른 변수들:

• if: $CI_COMMIT_TAG: 태그에 대한 변경이 푸시되었을 때.
• if: $CI_COMMIT_BRANCH: 어떤 브랜치로 변경이 푸시되었을 때.
• if: $CI_COMMIT_BRANCH == "main": main에 변경이 푸시되었을 때.
• if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH: 기본 브랜치로 변경이 푸시되었을 때. 여러 프로젝트에서 동일한 구성을 사용하려는 경우에 사용합니다.
• if: $CI_COMMIT_BRANCH =~ /regex-expression/: 커밋 브랜치가 정규 표현식과 일치할 때.
• if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_COMMIT_TITLE =~ /Merge branch.*/: 커밋 브랜치가 기본 브랜치이고, 커밋 메시지 제목이 정규 표현식과 일치할 때. 예시로, Merge 커밋의 기본 커밋 메시지는 Merge branch로 시작합니다.
• if: $CUSTOM_VARIABLE !~ /regex-expression/: 사용자 정의 변수 CUSTOM_VARIABLE이 정규 표현식과 일치하지 않을 때.
• if: $CUSTOM_VARIABLE == "value1": 사용자 정의 변수 CUSTOM_VARIABLE이 정확히 value1일 때.

rules:changes의 변수

• GitLab 13.6에서 도입되었습니다.
• GitLab 13.7에서 피처 플래그가 제거되었습니다.

CI/CD 변수를 rules:changes 표현식에서 사용하여 파이프라인에 작업을 추가할 시기를 결정할 수 있습니다.

docker build:
  variables:
    DOCKERFILES_DIR: 'path/to/files'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - changes:
        - $DOCKERFILES_DIR/*

$ 문자를 변수와 경로 양쪽에 사용할 수 있습니다. 예를 들어, DOCKERFILES_DIR 변수가 있다면 해당 값을 사용합니다. 존재하지 않으면 경로의 일부로 해석됩니다.

다른 작업에서 규칙 재사용

• GitLab 14.3에서 도입되었습니다.

서로 다른 작업에서 규칙을 재사용하려면 !reference 태그를 사용하세요. !reference 규칙을 일반 작업 정의 규칙과 결합할 수 있습니다.

.default_rules:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

job1:
  rules:
    - !reference [.default_rules, rules]
  script:
    - echo "이 작업은 기본 브랜치에 대해 실행되지만 일정에 대해 실행되지 않습니다."

job2:
  rules:
    - !reference [.default_rules, rules]
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "이 작업은 기본 브랜치에 대해 실행되지만 일정에 대해 실행되지 않습니다."
    - echo "또한 Merge Request에 대해 실행됩니다."

only 및 except로 작업 실행 시기 지정

only 및 except를 사용하여 파이프라인에 작업을 추가할 시기를 제어할 수 있습니다.

• only는 작업이 실행되는 시기를 정의합니다.
• except는 작업이 실행되지 않는 시기를 정의합니다.

only:refs / except:refs 예제

only 또는 except와 함께 다음을 사용할 수 있습니다:

• 특정 키워드입니다. 전체 디렉터리은 only/except 구문 참조를 참조하세요.
• 브랜치 이름. 특정 키워드와 정확히 동일한 브랜치 이름을 피하세요. 예를 들어, tags 키워드에 대해 구성된 작업은 tags라는 이름의 브랜치에도 실행됩니다.
• 일련의 브랜치 이름을 지정하기 위한 정규식 패턴.

다음 예는 refs를 생략한 이유는 only 또는 except를 only:refs / except:refs와 동일하기 때문입니다.

예:

job:
  # 특수 키워드 사용
  only:
    - tags
    - triggers
    - schedules

이 예제에서 job은 다음에만 실행됩니다:

• Git 태그
• 트리거
• 일정에 따른 파이프라인

부모 리포지터리에서만 작업을 실행하고 포크를 제외하려면:

job:
  only:
    - branches@gitlab-org/gitlab
  except:
    - main@gitlab-org/gitlab
    - /^release/.*$/@gitlab-org/gitlab

이 예제에서 job은 gitlab-org/gitlab의 모든 브랜치에서 실행되지만 main 및 release/.*$로 시작하는 브랜치에서는 실행되지 않습니다.

only: 변수 / except: 변수 예제

except:variables를 사용하여 커밋 메시지에 따라 작업을 제외할 수 있습니다.

end-to-end:
  script: rake test:end-to-end
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/

더 복잡한 변수 표현식을 구축하려면 괄호와 함께 && 및 ||을 사용할 수 있습니다.

job1:
  script:
    - echo 이 규칙은 괄호를 사용합니다.
  only:
    variables:
      - ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

only:variables에서 여러 항목을 지정하면 그 중 하나라도 true로 평가되는 경우 작업이 실행됩니다. 여러 조건이 동시에 충족되어야 하는 경우 단일 항목에서 &&을 사용할 수 있습니다.

only:changes / except:changes 예제

.md 확장자를 가진 루트 디렉터리 내의 모든 파일에 변경 내용이 감지되면 작업을 건너뛸 수 있습니다:

build:
  script: npm run build
  except:
    changes:
      - "*.md"

여러 파일을 변경하지만 .md로 끝나는 파일이 하나만 변경된 경우에도 build 작업은 여전히 건너뜁니다. 해당 파일에 대해 작업이 실행되지 않습니다.

일부 changes를 사용하는 구성에서는 작업 또는 파이프라인이 예상치 않게 실행될 수 있습니다.

합병 요청 파이프라인에서 only:changes 사용

합병 요청 파이프라인에서는 합병 요청에서 수정된 파일을 기반으로 작업을 정의할 수 있습니다.

이 키워드를 only: [merge_requests]와 함께 사용하여 GitLab이 소스 브랜치의 올바른 기본 SHA를 찾을 수 있습니다. 파일 차이는 추가로 커밋에서 올바르게 계산되며 합병 요청의 모든 변경 사항이 파이프라인에서 올바르게 테스트됩니다.

예를 들어:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - merge_requests
    changes:
      - Dockerfile
      - service-one/**/*

이 시나리오에서 service-one 디렉터리나 Dockerfile에서 파일이 변경되면 GitLab이 docker build service one 작업을 생성합니다.

예를 들어:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    changes:
      - Dockerfile
      - service-one/**/*

이 예제에서 파이프라인은 service-one/**/*에 변경 사항이 있어 실패할 수 있습니다.

이 구성을 사용할 때는 최근 파이프라인이 이전 파이프라인의 실패를 올바르게 수정하는지 확인하세요. 해당 합병 요청이 Merge 가능하면 이전 파이프라인이 실패한 것은 중요하지 않습니다.

번역된.md 파일을 제공드리겠습니다. 더 필요한 번역이 있으신가요?

only 또는 except로 여러 키워드를 결합

only 또는 except와 여러 키워드를 사용하면 키워드는 하나의 결합된 표현으로 평가됩니다. 즉,

• only는 키에 대한 모든 조건이 일치하는 경우 작업을 포함합니다.
• except는 키에 대한 어떤 조건이 일치하는 경우 작업을 제외합니다.

only를 사용할 때 개별 키는 논리적으로 AND로 연결됩니다. 다음 조건이 참이면 작업이 파이프라인에 추가됩니다:

• (열거된 refs 중 하나 이상이 참) AND (열거된 변수 중 하나 이상이 참) AND (열거된 변경 사항 중 하나 이상이 참) AND (선택한 Kubernetes 상태가 일치)

다음 예에서 test 작업은 모든 다음 조건이 참인 경우에만 생성됩니다:

• 파이프라인이 예약됨 또는 main을 위해 실행됨.
• variables 키워드가 일치함.
• 프로젝트에서 kubernetes 서비스가 활성화됨.

test:
  script: npm run test
  only:
    refs:
      - main
      - schedules
    variables:
      - $CI_COMMIT_MESSAGE =~ /run-end-to-end-tests/
    kubernetes: active

except를 사용할 때 개별 키는 논리적으로 OR로 연결됩니다. 다음 조건이 참이면 작업이 추가되지 않습니다:

• (열거된 refs 중 하나 이상이 참) OR (열거된 변수 중 하나 이상이 참) OR (열거된 변경 사항 중 하나 이상이 참) OR (선택한 Kubernetes 상태가 일치)

다음 예에서 test 작업은 다음 중 어떤 하나라도 참인 경우에는 생성되지 않습니다:

• 파이프라인이 main 브랜치를 위해 실행됨.
• 리포지터리의 루트 디렉터리에 있는 README.md 파일에 변경 사항이 있음.

test:
  script: npm run test
  except:
    refs:
      - main
    changes:
      - "README.md"

매뉴얼으로 실행해야 하는 작업 생성

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

when: manual을 .gitlab-ci.yml 파일의 작업에 추가하여 작업을 매뉴얼으로 지정할 수 있습니다.

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

보호된 브랜치를 사용하여 더 엄격하게 매뉴얼 배포를 보호할 수 있습니다.

매뉴얼 작업 유형

매뉴얼 작업은 선택적 또는 차단될 수 있습니다.

선택적 매뉴얼 작업에서는:

• allow_failure가 true이며, 이는 when: manual과 rules이 없거나 rules 바깥에 when: manual이 정의된 작업에 대한 기본 설정입니다.
• 상태는 전체 파이프라인 상태에 기여하지 않습니다. 모든 매뉴얼 작업이 실패해도 파이프라인은 성공할 수 있습니다.

차단된 매뉴얼 작업에서는:

• allow_failure가 false이며, rules 내에서 when: manual이 정의된 작업에 대한 기본 설정입니다.
• 파이프라인은 작업이 정의된 단계에서 중지됩니다. 파이프라인을 계속 실행하려면 매뉴얼 작업을 실행하세요.
• 차단된 파이프라인으로 설정된 프로젝트의 Merge Request은 차단된 파이프라인과 함께 Merge할 수 없습니다.
• 파이프라인은 차단됨 상태로 표시됩니다.

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

매뉴얼 작업 실행

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

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

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

매뉴얼 작업 보호

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

• 환경으로의 배포를 제한합니다.
• 승인된 사용자가 “승인”할 때까지 파이프라인을 차단합니다.

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

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를 추가하여 파이프라인의 다음 단계가 승인된 사용자에 의해 트리거된 매뉴얼 작업 이후에만 실행되도록 할 수 있습니다.

지연 후 작업 실행

• GitLab 11.4에 도입되었습니다.

when: delayed를 사용하여 대기 기간 후에 스크립트를 실행하거나, 작업이 즉시 보류 상태로 전환되는 것을 피하려면 이 키워드를 사용할 수 있습니다.

start_in 키워드로 기간을 설정할 수 있습니다. start_in의 값은 단위가 제공되지 않는 경우 초 단위의 경과 시간이며, 최소값은 1초이고 최대값은 1주일입니다. 유효한 값의 예시는 다음과 같습니다:

• '5' (단위가 없는 값은 작은따옴표로 감싸야 함)
• 5 seconds
• 30 minutes
• 1 day
• 1 week

지연 작업이 포함된 단계가 있으면 파이프라인은 지연된 작업이 끝날 때까지 진행되지 않습니다. 이 키워드를 사용하여 다른 단계 사이에 지연을 삽입할 수 있습니다.

지연된 작업의 타이머는 이전 단계가 완료된 후 즉시 시작합니다. 다른 유형의 작업과 마찬가지로, 지연된 작업의 타이머는 이전 단계가 통과되지 않으면 시작하지 않습니다.

다음 예는 timed rollout 10%라는 작업을 생성하며, 이는 이전 단계가 완료된 후 30분 후에 실행됩니다:

timed rollout 10%:
  stage: deploy
  script: echo '10% 배포 중 ...'
  when: delayed
  start_in: 30 minutes
  environment: production

지연된 작업의 활성 타이머를 중지하려면 예약 해제 ()를 선택합니다. 이 작업은 자동으로 예약되지 않습니다. 하지만 매뉴얼으로 실행할 수는 있습니다.

지연된 작업을 매뉴얼으로 시작하려면 예약 해제 ()를 선택하여 지연 타이머를 중지한 후 실행 ()을 선택합니다. 그러면 곧바로 GitLab Runner가 작업을 시작합니다.

대규모 작업 병렬화

대규모 작업을 여러 개의 작은 작업으로 분할하여 병렬로 실행하려면 .gitlab-ci.yml 파일에서 parallel 키워드를 사용하세요.

다양한 언어 및 테스트 스위트에는 병렬 처리를 활성화하는 다양한 방법이 있습니다. 예를 들어 Ruby 테스트를 병렬로 실행하려면 Semaphore Test Boosters 및 RSpec를 사용하세요.

# Gemfile
source 'https://rubygems.org'

gem 'rspec'
gem 'semaphore_test_boosters'

test:
  parallel: 3
  script:
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

그런 다음 새 파이프라인 빌드의 작업 탭으로 이동하면 RSpec 작업이 세 개의 별도 작업으로 분할된 것을 볼 수 있습니다.

일차원 병렬 작업 행렬 실행

• GitLab 13.5에서 도입됨.

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

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: [aws, ovh, gcp, vultr]
  environment: production/$PROVIDER

또한 다차원 행렬을 생성할 수도 있습니다.

병렬 트리거 작업 행렬 실행

• GitLab 13.10에서 도입됨.

한 번의 파이프라인에서 트리거 작업을 병렬로 여러 번 실행할 수 있지만 각 작업 인스턴스마다 다른 변수 값을 사용할 수 있습니다.

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]

이 예제는 deploystacks 트리거 작업을 6개 병렬로 생성하며, 각각 PROVIDER 및 STACK에 대해 서로 다른 값을 사용하여 해당 변수로 6가지 다른 자식 파이프라인을 생성합니다.

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [gcp, data]
deploystacks: [vultr, data]

각 병렬 행렬 작업에 다른 실행자 태그 지정

• GitLab 14.1에서 도입됨.

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 작업에서 artifact 가져오기

parallel:matrix로 생성된 작업에서 artifact를 가져올 수 있습니다. dependencies 키워드를 사용하세요. dependencies에는 문자열 형식으로 작업 이름을 값으로 사용합니다.

예를 들어, RUBY_VERSION이 2.7이고 PROVIDER가 aws인 작업에서 artifact를 가져오려면:

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를 사용해 병렬화된 작업 지정

• GitLab 16.3에서 도입됨.

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 작업.
• mac:rspec 작업.
• production 작업.

이 작업은 세 가지 실행 경로를 갖습니다:

• Linux 경로: linux:build: [aws, app1] 작업이 완료되자마자 mac:build 작업을 기다리지 않고 즉시 linux:rspec 작업이 실행됩니다.
• macOS 경로: mac:build: [gcp, data] 및 mac:build: [vultr, data] 작업이 완료되자마자 linux:build 작업을 기다리지 않고 즉시 mac:rspec 작업이 실행됩니다.
• 이전 모든 작업이 완료되자마자 production 작업이 실행됩니다.

미리 정의된 CI/CD 변수 사용하여 특정 파이프라인 유형에서 작업 실행

다음과 같이 미리 정의된 CI/CD 변수를 사용하여 다음 파이프라인 유형에서 작업이 실행되도록 선택할 수 있습니다. - rules - only:variables - except:variables

다음 표는 사용할 수 있는 일부 변수와 변수가 제어할 수 있는 파이프라인 유형을 나열합니다. - 브랜치 파이프라인: 브랜치에 대한 Git push 이벤트(새로운 커밋 또는 태그) - 태그 파이프라인: 새로운 Git 태그가 브랜치로 푸시될 때만 실행 - Merge Request 파이프라인: Merge Request에 대한 변경 사항 시(새로운 커밋 또는 Merge Request의 파이프라인 탭에서 파이프라인 실행 버튼 선택) 실행 - 일정 파이프라인

예를 들어, Merge Request 파이프라인과 일정 파이프라인에서만 실행되도록 작업을 구성하려면 다음과 같이 할 수 있습니다. yaml job1: script: - echo rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_PIPELINE_SOURCE == "schedule" - if: $CI_PIPELINE_SOURCE == "push" when: never

정규 표현식

@ 기호는 ref의 리포지터리 경로의 시작을 나타냅니다. 정규 표현식에서 @ 문자를 포함하는 ref 이름과 일치시키려면 16진수 문자 코드 일치 \x40를 사용해야 합니다.

정규 표현식으로는 태그나 브랜치 이름만 일치시킬 수 있습니다. 제공된 경우 리포지터리 경로는 항상 문자 그대로 일치합니다.

태그 또는 브랜치 이름을 일치시키려면 패턴의 전체 ref 이름 부분을 반드시 정규 표현식으로 둘러싸야 합니다. 예를 들어, issue-/.*/를 모든 issue-로 시작하는 태그 이름 또는 브랜치 이름과 일치시키지 못하며 /issue-.*/을 사용해야 합니다.

정규 표현식 플래그는 닫는 / 뒤에 추가해야 합니다. 기본적으로 패턴 일치는 대소문자를 구분합니다. 패턴의 대소문자를 구분하지 않으려면 /pattern/i와 같이 i 플래그 수정자를 사용하세요.

job:
  # 정규 표현식 사용
  only:
    - /^issue-.*$/i
  # 특수 키워드 사용
  except:
    - branches

정규 표현식을 사용하여 태그 이름 또는 브랜치 이름의 부분 문자열만 일치하도록 하는 것을 피하려면 ^와 $ 앵커를 사용하세요. 예를 들어, /^issue-.*$/는 /^issue-/과 동일하며, /issue/는 severe-issues라는 브랜치도 일치시킵니다.

only / except 정규 표현식 구문

GitLab 11.9.4에서 GitLab은 only 및 except 키워드에서 사용되는 정규 표현식을 RE2로 내부적으로 변환하기 시작했습니다.

RE2은 계산 복잡성으로 인해 사용 가능한 기능 집합을 제한하며, 부정적인 봐(ahead)와 같은 일부 기능은 사용할 수 없게 되었습니다. 루비 정규 표현식에서 제공하는 기능의 하위 집합만 지원되고 있습니다.

GitLab 11.9.7에서 GitLab 14.9까지는 위험한 정규 표현식 구문 사용을 허용하는 피처 플래그를 제공했습니다. 우리는 지금 RE2로 완전히 이전되었으며 해당 피처 플래그는 더 이상 사용할 수 없습니다.

CI/CD 변수 표현식

• GitLab 10.7에 only 및 except CI 키워드에 대해 도입
• GitLab 12.3에 rules 키워드와 함께 확장

GitLab에 변경 사항이 푸시된 후에 파이프라인에서 생성할 작업을 제어하기 위해 변수 표현식을 사용할 수 있습니다. 변수 표현식은 다음과 함께 사용할 수 있습니다. - rules:if. - only:variables 및 except:variables.

예를 들어, rules:if로:

job1:
  variables:
    VAR1: "variable1"
  script:
    - echo "테스트 변수 비교"
  rules:
    - if: $VAR1 == "variable1"

변수와 문자열 비교

변수를 문자열과 비교하기 위해 동등 연산자 == 및 !=를 사용할 수 있습니다. 단일 따옴표와 이중 따옴표 모두 유효합니다. 순서는 중요하지 않으며 변수가 먼저거나 문자열이 먼저거나 상관없습니다. - if: $VARIABLE == "some value" - if: $VARIABLE != "some value" - if: "some value" == $VARIABLE

두 변수 비교

두 변수의 값을 비교할 수 있습니다. 예를 들어:

• if: $VARIABLE_1 == $VARIABLE_2
• if: $VARIABLE_1 != $VARIABLE_2

변수가 정의되지 않은지 확인

null 키워드와 변수를 비교하여 정의 여부를 확인할 수 있습니다. 예를 들어:

• if: $VARIABLE == null
• if: $VARIABLE != null

변수가 비어 있는지 확인

정의된 변수가 비어 있는지 확인할 수 있습니다. 예를 들어:

• if: $VARIABLE == ""
• if: $VARIABLE != ""

변수의 존재 여부 확인

식에서 변수 이름만 사용하여 변수의 존재 여부를 확인할 수 있습니다. 변수는 비어 있으면 안 됩니다. 예시:

• if: $VARIABLE

변수를 정규 표현식 패턴과 비교

=~ 및 !~ 연산자로 변수 값에 대한 정규 표현식 패턴 매칭을 수행할 수 있습니다. 정규 표현식을 사용한 변수 패턴 매칭은 RE2 정규 표현식 구문을 사용합니다.

식은 다음과 같이 true로 평가됩니다:

• =~를 사용하여 일치 항목을 찾을 때
• !~를 사용하여 일치 항목을 찾지 못할 때

예시:

• if: $VARIABLE =~ /^content.*/
• if: $VARIABLE !~ /^content.*/

단일 문자 정규 표현식(/./와 같은)은 지원되지 않으며 잘못된 표현식 구문 오류가 발생합니다.

기본적으로 패턴 매칭은 대소문자를 구분합니다. 패턴을 대소문자 구분 없이 만들려면 i 플래그 수정자를 사용하세요. 예시: /pattern/i.

정규 표현식 패턴을 변수에 저장

• GitLab 15.0에서 ci_fix_rules_if_comparison_with_regexp_variable이라는 플래그와 함께 도입되었으며, 기본적으로 비활성화되어 있습니다.
• GitLab 15.1에 일반적으로 사용 가능하며, 피처 플래그 ci_fix_rules_if_comparison_with_regexp_variable가 제거되었습니다.

=~ 및 !~ 식의 오른쪽에 있는 변수는 정규 표현식으로 평가됩니다. 정규 표현식은 슬래시(/)로 묶여야 합니다. 예시:

variables:
  pattern: '/^ab.*/'

regex-job1:
  variables:
    teststring: 'abcde'
  script: echo "'abcde'가 /^ab.*/ 패턴과 일치하기 때문에 이 작업이 실행될 것입니다."
  rules:
    - if: '$teststring =~ $pattern'

regex-job2:
  variables:
    teststring: 'fghij'
  script: echo "'fghi'가 /^ab.*/ 패턴과 일치하지 않기 때문에 이 작업이 실행되지 않을 것입니다."
  rules:
    - if: '$teststring =~ $pattern'

변수 식을 && 또는 ||로 결합

• GitLab 12.0에서 도입되었습니다.

&& (그리고) 또는 || (또는)을 사용하여 여러 식을 결합할 수 있습니다. 예시:

• $VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"
• $VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3
• $VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3

연산자의 우선 순위는 Ruby 2.5 표준을 따르므로 &&가 ||보다 먼저 계산됩니다.

변수 식을 괄호로 그룹화

• GitLab 13.3에서 도입되었습니다.
• GitLab 13.5에서 피처 플래그가 제거되었습니다.

괄호를 사용하여 식을 그룹화할 수 있습니다. 괄호는 &&와 ||보다 우선되므로 괄호로 묶인 식이 먼저 계산되고 결과가 나머지 식에 사용됩니다.

복잡한 조건을 만들려면 괄호를 중첩하여 사용하고, 괄호 안의 가장 안쪽 식이 먼저 계산됩니다.

예시:

• ($VARIABLE1 =~ /^content.*/ || $VARIABLE2) && ($VARIABLE3 =~ /thing$/ || $VARIABLE4)
• ($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3
• $CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)