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_DEPENDENCY_PROXY}
변수를 재정의하지 않습니다. 왜냐하면 그룹 수준의
변수가 .gitlab-ci.yml
변수보다 높은 우선순위를 가지기 때문입니다.공통 작업 정의
대부분의 작업은 .gitlab/ci/global.gitlab-ci.yml
에 정의된
몇 가지 CI 정의에서 가져옵니다. 이는 단일 구성 키워드에 대해 범위가 지정된 작업입니다.
작업 정의 | 설명 |
---|---|
.default-retry
|
unknown_failure , api_failure , runner_system_failure , job_execution_timeout 또는 stuck_or_timeout_failure 발생시 작업을 다시 시도할 수 있도록 합니다.
|
.default-before_script
| 루비/레일 작업에 적합한 기본적인 before_script 정의를 사용할 수 있도록 합니다. 예를 들어, 데이터베이스가 실행되어야 하는 루비/레일 작업(예: 테스트)에 사용됩니다.
|
.repo-from-artifacts
| 작업이 clone-gitlab-repo 에서 아티팩트로부터 리포지터리를 가져오도록 하며, 클론하는 대신 아티팩트에서 다운로드하기 때문에 GitLab.com Gitaly 부하가 감소되고 속도가 약간 향상됩니다. 일반적으로 모든 작업이 가능한 빨리 시작되기를 원하기 때문에 needs: [] 와 함께 사용하지 않도록 주의해야 합니다. 다른 의존성이 있는 작업에만 사용하도록 하여 오로지 클론하는 것보다 기다릴 필요가 없도록 합니다. 이 동작은 CI_FETCH_REPO_GIT_STRATEGY 를 통해 제어 가능합니다. 자세한 내용은 Gitaly에서 클론/가져오기 대신 아티팩트를 통해 리포지터리 가져오기를 참조하십시오.
|
.setup-test-env-cache
| 후속 루비/레일 작업에 대한 테스트 환경을 설정하는 데 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.ruby-cache
| 루비 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.static-analysis-cache
| 정적 분석 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.ruby-gems-coverage-cache
| 커버리지 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.qa-cache
| QA 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.yarn-cache
|
yarn install 을 하는 프론트엔드 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다.
|
.assets-compile-cache
| 에셋을 컴파일하는 프론트엔드 작업에 적합한 기본 캐시 정의를 사용할 수 있도록 합니다. |
.use-pg13
| 작업에서 postgres 13, redis , 및 rediscluster 서비스를 사용할 수 있도록 합니다 (서비스의 구체적인 버전은 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg13-ee
|
.use-pg13 와 동일하되, elasticsearch 서비스도 사용합니다 (서비스의 구체적인 버전에 대해서는 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg14
| 작업에서 postgres 14, redis , 및 rediscluster 서비스를 사용할 수 있도록 합니다 (서비스의 구체적인 버전은 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg14-ee
|
.use-pg14 와 동일하되, elasticsearch 서비스도 사용합니다 (서비스의 구체적인 버전에 대해서는 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg15
| 작업에서 postgres 15, redis , 및 rediscluster 서비스를 사용할 수 있도록 합니다 (서비스의 구체적인 버전은 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg15-ee
|
.use-pg15 와 동일하되, elasticsearch 서비스도 사용합니다 (서비스의 구체적인 버전에 대해서는 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg16
| 작업에서 postgres 16, redis , 및 rediscluster 서비스를 사용할 수 있도록 합니다 (서비스의 구체적인 버전은 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-pg16-ee
|
.use-pg16 와 동일하되, elasticsearch 서비스도 사용합니다 (서비스의 구체적인 버전에 대해서는 .gitlab/ci/global.gitlab-ci.yml을 참조하십시오).
|
.use-kaniko
| 작업에서 kaniko 도구를 사용할 수 있도록 합니다.
|
.as-if-foss
|
FOSS_ONLY='1' CI/CD 변수를 설정하여 FOSS 프로젝트를 모의할 수 있습니다.
|
.use-docker-in-docker
| 작업에서 도커 인 도커를 사용할 수 있도록 합니다. 자세한 내용은 CI/CD 구성에 대한 핸드북을 참조하십시오. |
rules
, if:
조건 및 changes:
패턴
우리는 rules
키워드를 광범위하게 사용하고 있습니다.
모든 rules
정의는
rules.gitlab-ci.yml
에 정의되어 있으며,
그런 다음 YAML 앵커를 통해 extends
를 통해 개별 작업에 포함됩니다.
rules
정의는 if:
조건 및 changes:
패턴으로 구성되어 있으며,
이 역시
rules.gitlab-ci.yml
에 정의되어 있으며,
rules
정의에서 YAML 앵커를 통해 포함됩니다.
if:
조건
if: 조건
| 설명 | 비고 |
---|---|---|
if-not-canonical-namespace
| 프로젝트가 정식 (gitlab-org/ 및 gitlab-cn/ ) 또는 보안 (gitlab-org/security ) 네임스페이스에 있는 경우에 일치합니다.
| 포크를 위한 작업을 생성하기 위해 when: on_success 또는 when: manual 을 사용하거나, 포크에서는 작업을 만들지 않도록하기 위해 when: never 를 사용합니다.
|
if-not-ee
| 프로젝트 이름이 gitlab 또는 gitlab-ee 가 아닌 경우에 일치합니다 (즉, 프로젝트가 EE가 아닌 경우).
| FOSS 프로젝트에서만 작업을 생성하기 위해 when: on_success 또는 when: manual 을 사용하거나, 프로젝트가 EE인 경우에는 작업을 만들지 않기 위해 when: never 를 사용합니다.
|
if-not-foss
| 프로젝트 이름이 gitlab-foss , gitlab-ce , 또는 gitlabhq 가 아닌 경우에 일치합니다 (즉, 프로젝트가 FOSS가 아닌 경우).
| EE 프로젝트에서만 작업을 생성하기 위해 when: on_success 또는 when: manual 을 사용하거나, 프로젝트가 FOSS인 경우에는 작업을 만들지 않기 위해 when: never 를 사용합니다.
|
if-default-refs
| 파이프라인이 master , main , /^[\d-]+-stable(-ee)?$/ (안정 브랜치), /^\d+-\d+-auto-deploy-\d+$/ (자동 배포 브랜치), /^security\// (보안 브랜치), 머지 요청, 및 태그용인 경우 일치합니다.
| 브랜치에 대한 해당 기본 구성으로 작업이 생성되지 않음에 유의하십시오. |
if-master-refs
| 현재 브랜치가 master 또는 main 인 경우에 일치합니다.
| |
if-master-push
| 현재 브랜치가 master 또는 main 이며 파이프라인 소스가 push 인 경우에 일치합니다.
| |
if-master-schedule-maintenance
| 현재 브랜치가 master 또는 main 이며 파이프라인이 2시간마다 스케줄링된 경우에 일치합니다.
| |
if-master-schedule-nightly
| 현재 브랜치가 master 또는 main 이며 파이프라인이 매일 밤 스케줄링된 경우에 일치합니다.
| |
if-auto-deploy-branches
| 현재 브랜치가 자동 배포 브랜치인 경우 일치합니다. | |
if-master-or-tag
| 파이프라인이 master 또는 main 브랜치이거나 태그인 경우 일치합니다.
| |
if-merge-request
| 파이프라인이 머지 요청인 경우 일치합니다. | |
if-merge-request-title-as-if-foss
| 파이프라인이 머지 요청이며 MR에 라벨 ~"pipeline:run-as-if-foss"가 있는 경우 일치합니다. | |
if-merge-request-title-update-caches
| 파이프라인이 머지 요청이며 MR에 라벨 ~"pipeline:update-cache"가 있는 경우 일치합니다. | |
if-merge-request-labels-run-all-rspec
| 파이프라인이 머지 요청이며 MR에 라벨 ~"pipeline:run-all-rspec"가 있는 경우 일치합니다. | |
if-merge-request-labels-run-cs-evaluation
| 파이프라인이 머지 요청이며 MR에 라벨 ~"pipeline:run-CS-evaluation"가 있는 경우 일치합니다. | |
if-security-merge-request
| 파이프라인이 보안 머지 요청인 경우 일치합니다. | |
if-security-schedule
| 파이프라인이 보안 스케줄링된 파이프라인인 경우 일치합니다. | |
if-nightly-master-schedule
| 파이프라인이 $NIGHTLY 가 설정된 master 스케줄링된 파이프라인인 경우 일치합니다.
| |
if-dot-com-gitlab-org-schedule
| GitLab.com의 gitlab-org 그룹에 대한 스케줄링된 파이프라인을 위한 작업 생성을 제한합니다.
| |
if-dot-com-gitlab-org-master
| GitLab.com의 gitlab-org 그룹에서 master 또는 main 브랜치에 대한 작업 생성을 제한합니다.
| |
if-dot-com-gitlab-org-merge-request
| GitLab.com의 gitlab-org 그룹에 대한 머지 요청을 위한 작업 생성을 제한합니다.
| |
if-dot-com-ee-schedule
| GitLab.com의 gitlab-org/gitlab 프로젝트에 대한 스케줄링된 파이프라인을 위한 작업을 제한합니다.
|
changes:
패턴
changes: 패턴
| 설명 |
---|---|
ci-patterns
| CI 구성 관련 변경 사항에 대한 작업만 생성합니다. |
ci-build-images-patterns
|
build-images 단계와 관련된 CI 구성 관련 변경 사항에 대한 작업만 생성합니다.
|
ci-review-patterns
|
review 단계와 관련된 CI 구성 관련 변경 사항에 대한 작업만 생성합니다.
|
ci-qa-patterns
|
qa 단계와 관련된 CI 구성 관련 변경 사항에 대한 작업만 생성합니다.
|
yaml-lint-patterns
| YAML 관련 변경 사항에 대한 작업만 생성합니다. |
docs-patterns
| 문서 관련 변경 사항에 대한 작업만 생성합니다. |
frontend-dependency-patterns
| 프론트엔드 의존성 업데이트 시(예: package.json , yarn.lock 변경)에만 작업을 생성합니다.
|
frontend-patterns-for-as-if-foss
| FOSS에 영향을 미치는 프론트엔드 관련 변경 사항에 대한 작업만 생성합니다. |
backend-patterns
| 백엔드 관련 변경 사항에 대한 작업만 생성합니다. |
db-patterns
| DB 관련 변경 사항에 대한 작업만 생성합니다. |
backstage-patterns
| Backstage 관련 변경 사항에 대한 작업만 생성합니다(Danger, fixtures, RuboCop, specs). |
code-patterns
| 코드 관련 변경 사항에 대한 작업만 생성합니다. |
qa-patterns
| QA 관련 변경 사항에 대한 작업만 생성합니다. |
code-backstage-patterns
|
code-patterns 및 backstage-patterns 의 조합.
|
code-qa-patterns
|
code-patterns 및 qa-patterns 의 조합.
|
code-backstage-qa-patterns
|
code-patterns , backstage-patterns , qa-patterns 의 조합.
|
static-analysis-patterns
| 정적 분석 구성 관련 변경 사항에 대한 작업만 생성합니다. |
모범 사례
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
블록이 이미 정의된 경우(또는 그와 관련된 작업에 정의된 경우)
이 경우 다음을 수행해야 합니다.
- 첫 번째 시나리오와 마찬가지로
.fast-no-clone-job
을 확장하여(이로써FILES_TO_DOWNLOAD
변수를 다른 변수와 Merge합니다) - 해당 작업에서 사용하는
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 핸드북 페이지를 참조하세요.