• Workflow rules
  • $FORCE_GITLAB_CI 사용 피하기
    • $FORCE_GITLAB_CI 대체 방법
• 기본 이미지
• 기본 변수
• 단계
• 의존성 프록시
  • 프로젝트 액세스 토큰 사용자에 의한 파이프라인 시작을 위한 해결책
• 공통 작업 정의
• rules, if: 조건 및 changes: 패턴
  • if: 조건
  • changes: 패턴
• 모범 사례
  • extends:, <<: *xyz (YAML 앵커), 또는 !reference를 사용해야 하는 경우
    • 주요 포인트
    • extends 및 YAML 앵커의 기능
      • extends
      • YAML 앵커
    • 훌륭한 예제
  • .fast-no-clone-job 작업 확장
    • 시나리오 1: 작업에 before_script가 정의되지 않은 경우
    • 시나리오 2: 작업에 before_script 블록이 이미 정의된 경우(또는 그와 관련된 작업에 정의된 경우)
    • 주의사항
    • 이 패턴이 사용되는 곳은 어디인가요?
    • Runner 태그

CI 구성 내부

Workflow rules

GitLab 프로젝트의 파이프라인은 GitLab CI/CD의 workflow:rules 키워드 기능을 사용하여 생성됩니다.

파이프라인은 항상 다음 시나리오에 대해 생성됩니다:

• main 브랜치, 스케줄, 푸시, Merge 등.
• Merge Request.
• 태그.
• Stable, auto-deploy, 보안 브랜치.

파이프라인 생성은 다음 CI/CD 변수에도 영향을 받습니다:

• $FORCE_GITLAB_CI가 설정되어 있으면 파이프라인이 생성됩니다. 권장되지 않습니다. Avoid $FORCE_GITLAB_CI 참조.
• $GITLAB_INTERNAL이 설정되지 않은 경우 파이프라인이 생성되지 않습니다.

다른 경우에는 파이프라인이 생성되지 않습니다 (예: 해당하는 MR이 없는 브랜치를 푸시할 때).

이러한 Workflow 규칙의 진실의 출처는 .gitlab-ci.yml 에서 정의됩니다.

$FORCE_GITLAB_CI 사용 피하기

파이프라인은 매우 복잡하며 트리거하고자 하는 파이프라인의 종류를 명확히 이해해야 합니다. 실행해야 할 작업과 실행하면 안 되는 작업을 파악해야 합니다.

$FORCE_GITLAB_CI를 사용하여 파이프라인을 강제로 트리거하려면, 실제로 어떤 종류의 파이프라인인지 알 수 없습니다. 결과적으로 우리가 원하는 작업을 실행하지 않을 수도 있고, 우리가 신경 쓰지 않는 너무 많은 작업을 실행할 수도 있습니다.

자세한 내용과 배경은 다음에서 확인할 수 있습니다: 예상치 못한 실행을 피하기

현재 우리가 언제 $FORCE_GITLAB_CI를 사용하고 있는지 알아봐서 $FORCE_GITLAB_CI를 사용하지 않도록 노력해야 합니다.

• 지후 유효성 검사 파이프라인

$FORCE_GITLAB_CI를 사용하지 않으면서 파이프라인을 활성화하는 방법에 대한 내용은 다음 섹션을 참조하세요.

$FORCE_GITLAB_CI 대체 방법

기본적으로, 다른 변수를 사용하여 여러 파이프라인을 활성화합니다. 이를 수행하는 예시로는 $START_AS_IF_FOSS가 있습니다. 교차 프로젝트 FOSS 파이프라인을 트리거하려면 $START_AS_IF_FOSS를 설정하고, $ENABLE_RSPEC_UNIT, $ENABLE_RSPEC_SYSTEM 등의 다른 변수들과 함께 관련 작업을 활성화합니다. 이러한 $START_AS_IF_FOSS를 사용하는 장점은 파이프라인을 실행하는 방법에 대해 완전한 제어권을 가질 수 있다는 것입니다. $START_AS_IF_FOSS는 오직 이 목적으로만 사용되며, 이 변수를 통해 파이프라인의 동작을 변경해도 다른 종류의 파이프라인에 영향을 미치지 않습니다. 반면에, $FORCE_GITLAB_CI를 사용하면 파이프라인이 정확히 어떤지 모르기 때문에 여러 목적으로 사용되므로 다른 종류의 파이프라인에 영향을 줄 수 있습니다.

기본 이미지

기본 이미지는 .gitlab-ci.yml에 정의되어 있습니다.

이미지에는 Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL 및 Graphics Magick이 포함됩니다.

우리 파이프라인에서 사용하는 이미지는 gitlab-org/gitlab-build-images 프로젝트에서 구성되며, 이는 여분의 으로 push-mirrored됩니다.

현재 빌드 이미지의 버전은 “GitLab 섹션에서 사용 중”에서 찾을 수 있습니다.

기본 변수

미리 정의된 CI/CD 변수에 추가로, 각 파이프라인에는 .gitlab-ci.yml에서 정의된 기본 변수가 포함됩니다.

단계

현재 단계는 다음과 같습니다:

• sync: 이 단계는 gitlab-org/gitlab에서 gitlab-org/gitlab-foss로 변경 사항을 동기화하는 데 사용됩니다.
• prepare: 이 단계에는 후속 단계에서 필요한 아티팩트를 준비하는 작업이 포함됩니다.
• build-images: 이 단계에는 후속 단계 또는 다운스트림 파이프라인에서 필요한 Docker 이미지를 준비하는 작업이 포함됩니다.
• fixtures: 이 단계에는 프론트엔드 테스트에 필요한 fixtures를 준비하는 작업이 포함됩니다.
• lint: 이 단계에는 린트 및 정적 분석 작업이 포함됩니다.
• test: 이 단계에는 대부분의 테스트 및 DB/migration 작업이 포함됩니다.
• post-test: 이 단계에는 test 단계의 작업에서 보고서를 작성하거나 데이터를 수집하는 작업이 포함됩니다 (예: 커버리지, Knapsack 메타데이터 등).
• review: 이 단계에는 CNG 이미지를 빌드하고 배포하며 리뷰 앱에 대한 엔드 투 엔드 테스트를 실행하는 작업이 포함됩니다. (리뷰 앱에 대한 자세한 내용은 해당 링크를 참조하세요). 이 단계에는 문서 리뷰 앱 작업도 포함됩니다.
• qa: 이 단계에는 review 단계에 배포된 리뷰 앱에 대한 QA 작업이 포함됩니다.
• post-qa: 이 단계에는 qa 단계의 작업에서 보고서를 작성하거나 데이터를 수집하는 작업이 포함됩니다 (예: 리뷰 앱 성능 보고서).
• pages: 이 단계에는 다양한 보고서를 GitLab Pages로 배포하는 작업이 포함됩니다 (예: coverage-ruby와 webpack-report (https://gitlab-org.gitlab.io/gitlab/webpack-report/)에서 찾을 수 있지만, 배포에 문제가 있습니다).
• notify: 이 단계에는 다양한 실패를 Slack에 알리는 작업이 포함됩니다.

의존성 프록시

일부 작업에서는 Docker Hub의 이미지를 사용하며, 여기서 우리는 이미지 경로의 접두어로 ${GITLAB_DEPENDENCY_PROXY_ADDRESS}를 사용하여 우리의 의존성 프록시에서 이미지를 풀기 위해 사용합니다. 기본적으로, 이 변수는 ${GITLAB_DEPENDENCY_PROXY}의 값에서 설정됩니다.

${GITLAB_DEPENDENCY_PROXY}는 gitlab-org 그룹의 CI/CD 변수로 ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/로 정의됩니다. 이는 다음과 같이 정의된 이미지를 사용할 때 의미를 갖습니다:

image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}alpine:edge

gitlab-org 그룹의 프로젝트는 의존성 프록시에서 끌어오고, 그 외의 개인 네임스페이스나 그룹에 있는 포크에서는 ${GITLAB_DEPENDENCY_PROXY}도 거기에 정의되어 있지 않은 한 Docker Hub로 되돌아가게 됩니다.

프로젝트 액세스 토큰 사용자에 의한 파이프라인 시작을 위한 해결책

프로젝트 액세스 토큰 사용자(예: release-tools approver bot 사용자 등)에 의해 파이프라인이 시작될 때, 의존성 프록시에 액세스할 수 없습니다 그리고 작업은 Preparing the "docker+machine" executor 단계에서 실패합니다. 이를 해결하기 위해, 우리는 ${GITLAB_DEPENDENCY_PROXY_ADDRESS} 변수를 재정의하는 특별한 Workflow 규칙이 있어서 이 경우에는 의존성 프록시를 사용하지 않도록 변수를 재정의합니다:

- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $GITLAB_USER_LOGIN =~ /project_\d+_bot\d*/'
  variables:
    GITLAB_DEPENDENCY_PROXY_ADDRESS: ""

공통 작업 정의

대부분의 작업은 .gitlab/ci/global.gitlab-ci.yml에 정의된 몇 가지 CI 정의에서 가져옵니다. 이는 단일 구성 키워드에 대해 범위가 지정된 작업입니다.

rules, if: 조건 및 changes: 패턴

우리는 rules 키워드를 광범위하게 사용하고 있습니다.

모든 rules 정의는 rules.gitlab-ci.yml에 정의되어 있으며, 그런 다음 YAML 앵커를 통해 extends를 통해 개별 작업에 포함됩니다.

rules 정의는 if: 조건 및 changes: 패턴으로 구성되어 있으며, 이 역시 rules.gitlab-ci.yml에 정의되어 있으며, rules 정의에서 YAML 앵커를 통해 포함됩니다.

if: 조건

changes: 패턴

모범 사례

extends:, <<: *xyz (YAML 앵커), 또는 !reference를 사용해야 하는 경우

참조

주요 포인트

• 해시를 확장해야 하는 경우, extends를 사용해야 합니다.
• 배열을 확장해야 하는 경우, !reference 또는 YAML 앵커를 사용해야 합니다. 마지막 수단으로 사용합니다.
• 더 복잡한 경우(예: 배열 내의 해시 확장, 해시 내의 배열 확장 등)에는 !reference 또는 YAML 앵커를 사용해야 합니다.

extends 및 YAML 앵커의 기능

extends

• 해시에 대한 깊은 Merge
• 배열에 대한 Merge은 없음. 덮어씁니다(원본).

YAML 앵커

• 해시에 대한 깊은 Merge은 없지만, 해시를 확장하는 데 사용할 수 있습니다(아래 예제 참조).
• 배열에 대한 Merge은 없지만, 배열을 확장하는 데 사용할 수 있습니다(아래 예제 참조).

훌륭한 예제

이 예제는 !reference 및 YAML 앵커를 사용하여 복잡한 YAML 데이터 구조를 확장하는 방법을 보여줍니다.

.strict-ee-only-rules:
  # `rules`는 해시의 배열입니다.
  rules:
    - if: '$CI_PROJECT_NAME !~ /^gitlab(-ee)?$/ '
      when: never

# `if-security-merge-request`는 해시입니다.
.if-security-merge-request: &if-security-merge-request
  if: '$CI_PROJECT_NAMESPACE == "gitlab-org/security"'

# `code-qa-patterns`는 배열입니다.
.code-qa-patterns: &code-qa-patterns
  - "{package.json,yarn.lock}"
  - ".browserslistrc"
  - "babel.config.js"
  - "jest.config.{base,integration,unit}.js"

.qa:rules:as-if-foss:
  rules:
    # 해시의 배열을 직접 확장합니다
    - !reference [".strict-ee-only-rules", rules]
    # 해시를 한 개의 배열 항목으로 확장합니다.
    - <<: *if-security-merge-request
      # `changes`는 배열이므로 전체 배열을 전달합니다.
      changes: *code-qa-patterns

qa:selectors-as-if-foss:
  # .qa:rules:as-if-foss에서 규칙을 포함합니다.
  extends:
    - .qa:rules:as-if-foss

.fast-no-clone-job 작업 확장

근본 프로젝트의 브랜치 다운로드에는 20~30초가 소요됩니다.

몇몇 작업은 파일을 한정적으로 필요로 할 뿐 존재하는데, 해당 파일은 GitLab API를 통해 다운로드할 수 있습니다.

작업에서 git clone/git fetch를 건너뛸 수 있습니다. 이를 위해 다음과 같은 패턴을 추가할 수 있습니다.

시나리오 1: 작업에 before_script가 정의되지 않은 경우

이는 해당 작업을 확장하는 상위 섹션에도 적용됩니다.

.fast-no-clone-job를 직접 확장하면 됩니다.

변경 전:

  # 참고: 작업에 `extends:`가 없음
  a-job:
    script:
      - source scripts/rspec_helpers.sh scripts/slack
      - echo "git clone이 필요하지 않습니다!"

변경 후:

  # 참고: 작업에 `extends:`가 없음
  a-job:
    extends:
      - .fast-no-clone-job
    variables:
      FILES_TO_DOWNLOAD: >
        scripts/rspec_helpers.sh
        scripts/slack
    script:
      - source scripts/rspec_helpers.sh scripts/slack
      - echo "git clone이 필요하지 않습니다!"

시나리오 2: 작업에 before_script 블록이 이미 정의된 경우(또는 그와 관련된 작업에 정의된 경우)

이 경우 다음을 수행해야 합니다.

1. 첫 번째 시나리오와 마찬가지로 .fast-no-clone-job을 확장하여(이로써 FILES_TO_DOWNLOAD 변수를 다른 변수와 Merge합니다)
2. 해당 작업에서 사용하는 before_script에 .fast-no-clone-job의 before_script 섹션을 참조하는지 확인합니다.

변경 전:

  .base-job:
    before_script:
      echo "Hello from .base-job"
  
  a-job:
    extends:
      - .base-job
    script:
      - source scripts/rspec_helpers.sh scripts/slack
      - echo "git clone이 필요하지 않습니다!"

변경 후:

  .base-job:
    before_script:
      echo "Hello from .base-job"
  
  a-job:
    extends:
      - .base-job
      - .fast-no-clone-job
    variables:
      FILES_TO_DOWNLOAD: >
        scripts/rspec_helpers.sh
        scripts/slack
    before_script:
      - !reference [".fast-no-clone-job", before_script]
      - !reference [".base-job", before_script]
    script:
      - source scripts/rspec_helpers.sh scripts/slack
      - echo "git clone이 필요하지 않습니다!"

주의사항

• 이 패턴은 작업에서 리포지터리에 액세스하기 위해 git에 의존하는 스크립트의 경우 작동하지 않습니다. 왜냐하면 복제하거나 가져오지 않기 때문입니다.
• 이 패턴을 사용하는 작업은 curl을 사용할 수 있어야 합니다.
• 작업에서 bundle install을 실행해야 하는 경우(BUNDLE_ONLY를 사용하더라도), 다음을 수행해야 합니다:
  • gitlab-org/gitlab 프로젝트에 저장된 젬을 다운로드합니다.
    • 이를 위해 download_local_gems 셸 명령을 사용할 수 있습니다.
  • Gemfile, Gemfile.lock, Gemfile.checksum을 포함해야 합니다(해당되는 경우).

이 패턴이 사용되는 곳은 어디인가요?

• 현재 이 패턴은 다음 작업에서 사용하고 있으며 이러한 작업은 개인 리포지터리를 차단하지 않습니다:
  • review-build-cng-env 작업
    • GITALY_SERVER_VERSION
    • GITLAB_ELASTICSEARCH_INDEXER_VERSION
    • GITLAB_KAS_VERSION
    • GITLAB_PAGES_VERSION
    • GITLAB_SHELL_VERSION
    • scripts/trigger-build.rb
    • VERSION
  • review-deploy 작업
    • GITALY_SERVER_VERSION
    • GITLAB_SHELL_VERSION
    • scripts/review_apps/review-apps.sh
    • scripts/review_apps/seed-dast-test-data.sh
    • VERSION
  • rspec:coverage 작업
    • config/bundler_setup.rb
    • Gemfile
    • Gemfile.checksum
    • Gemfile.lock
    • scripts/merge-simplecov
    • spec/simplecov_env_core.rb
    • spec/simplecov_env.rb
  • prepare-as-if-foss-env 작업
    • scripts/setup/generate-as-if-foss-env.rb

또한, 이 패턴이 사용될 때 항상 scripts/utils.sh가 GitLab API를 통해 다운로드됩니다(이 파일에는 .fast-no-clone-job의 코드가 포함되어 있습니다).

Runner 태그

GitLab.com에서는 권한이 없는 러너와 권한이 있는 러너가 모두 사용 가능합니다. gitlab-org 그룹의 프로젝트 및 해당 프로젝트의 포크를 위해 작업에 다음 태그 중 하나만 추가해야 합니다:

• gitlab-org: 작업은 무작위로 권한이 있는 러너와 권한이 없는 러너를 사용합니다.
• gitlab-org-docker: 작업은 권한이 있는 러너를 반드시 사용해야 합니다. Docker-in-Docker 지원이 필요한 경우 gitlab-org 대신 gitlab-org-docker를 사용하세요.

gitlab-org-docker 태그는 위의 .use-docker-in-docker 작업 정의에 추가됩니다.

포크와의 호환성을 보장하기 위해 gitlab-org 및 gitlab-org-docker를 동시에 사용하지 않도록 주의하세요. 어떤 인스턴스 러너도 gitlab-org 및 gitlab-org-docker 태그를 모두 가지고 있지 않습니다. gitlab-org 프로젝트의 포크인 경우, 양쪽 태그가 함께 제공되면 일치하는 러너가 없기 때문에 작업이 막힐 수 있습니다.

더 많은 정보는 GitLab Repositories 핸드북 페이지를 참조하세요.