GitLab CI/CD 설정 파일 최적화
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
다음을 사용하여 GitLab CI/CD 설정 파일의 복잡성과 중복 설정을 줄일 수 있습니다: 변수 값만 다른 유사한 잡을 여러 개 생성하려면 parallel:matrix를 사용하세요. YAML에는 문서 전체에서 콘텐츠를 복제할 수 있는 '앵커'라는 기능이 있습니다.
다음을 사용하여 GitLab CI/CD 설정 파일의 복잡성과 중복 설정을 줄일 수 있습니다:
- 앵커(
&), 별칭(*), 맵 병합(<<) 같은 YAML 고유 기능. 다양한 YAML 기능에 대해 더 읽어보세요. - 더 유연하고 가독성이 좋은
extends키워드. 가능한 경우extends를 사용하는 것이 좋습니다.
변수 값만 다른 유사한 잡을 여러 개 생성하려면 parallel:matrix를 사용하세요.
앵커 {#anchors}#
YAML에는 문서 전체에서 콘텐츠를 복제할 수 있는 '앵커'라는 기능이 있습니다.
앵커를 사용하여 속성을 복제하거나 상속할 수 있습니다. 잡의 템플릿을 제공하기 위해 숨겨진 잡과 함께 앵커를 사용하세요.
& 문자는 앵커 이름을 표시하고, * 문자는 앵커를 참조하는 별칭입니다. 앵커는 이를 참조하는 별칭보다 YAML 파일의 앞쪽에 정의해야 합니다.
중복 키가 있는 경우 마지막으로 포함된 키가 우선하여 다른 키를 재정의합니다.
특정 경우( 스크립트용 YAML 앵커 참조)에는 YAML 앵커를 사용하여 다른 곳에서 정의된 여러 구성 요소로 배열을 만들 수 있습니다. 예를 들어:
.default_scripts: &default_scripts
- ./default-script1.sh
- ./default-script2.sh
job1:
script:
- *default_scripts
- ./job-script.sh
include 키워드를 사용할 때 여러 파일에 걸쳐 YAML 앵커를 사용할 수 없습니다. 앵커는 정의된 파일 내에서만 유효합니다. 다른 YAML 파일의 설정을 재사용하려면 !reference 태그 또는 extends 키워드를 사용하세요.
다음 예시에서는 앵커와 맵 병합을 사용합니다. .job_template 설정을 상속하지만 각자 고유한 script가 정의된 두 개의 잡 test1과 test2를 생성합니다:
.job_template: &job_configuration # 'job_configuration'이라는 앵커를 정의하는 숨겨진 yaml 설정
image: ruby:2.6
services:
- postgres
- redis
test1:
<<: *job_configuration # 'job_configuration' 별칭의 내용을 추가
script:
- test1 project
test2:
<<: *job_configuration # 'job_configuration' 별칭의 내용을 추가
script:
- test2 project
&는 앵커 이름(job_configuration)을 설정하고, <<는 "주어진 해시를 현재 해시에 병합"을 의미하며, *는 명명된 앵커(job_configuration)를 포함합니다. 이 예시의 확장된 버전은 다음과 같습니다:
.job_template:
image: ruby:2.6
services:
- postgres
- redis
test1:
image: ruby:2.6
services:
- postgres
- redis
script:
- test1 project
test2:
image: ruby:2.6
services:
- postgres
- redis
script:
- test2 project
앵커를 사용하여 두 세트의 서비스를 정의할 수 있습니다. 예를 들어, test:postgres와 test:mysql은 .job_template에 정의된 script를 공유하지만, .postgres_services와 .mysql_services에 정의된 서로 다른 services를 사용합니다:
.job_template: &job_configuration
script:
- test project
tags:
- dev
.postgres_services:
services: &postgres_configuration
- postgres
- ruby
.mysql_services:
services: &mysql_configuration
- mysql
- ruby
test:postgres:
<<: *job_configuration
services: *postgres_configuration
tags:
- postgres
test:mysql:
<<: *job_configuration
services: *mysql_configuration
확장된 버전은 다음과 같습니다:
.job_template:
script:
- test project
tags:
- dev
.postgres_services:
services:
- postgres
- ruby
.mysql_services:
services:
- mysql
- ruby
test:postgres:
script:
- test project
services:
- postgres
- ruby
tags:
- postgres
test:mysql:
script:
- test project
services:
- mysql
- ruby
tags:
- dev
숨겨진 잡이 템플릿으로 편리하게 사용되고, tags: [postgres]가 tags: [dev]를 덮어쓰는 것을 확인할 수 있습니다.
스크립트용 YAML 앵커 {#yaml-anchors-for-scripts}#
여러 잡에서 미리 정의된 명령을 사용하기 위해 script, before_script, after_script와 함께 YAML 앵커를 사용할 수 있습니다:
.some-script-before: &some-script-before
- echo "Execute this script first"
.some-script: &some-script
- echo "Execute this script second"
- echo "Execute this script too"
.some-script-after: &some-script-after
- echo "Execute this script last"
job1:
before_script:
- *some-script-before
script:
- *some-script
- echo "Execute something, for this job only"
after_script:
- *some-script-after
job2:
script:
- *some-script-before
- *some-script
- echo "Execute something else, for this job only"
- *some-script-after
extends를 사용하여 설정 섹션 재사용 {#use-extends-to-reuse-configuration-sections}#
extends 키워드를 사용하여 여러 잡에서 설정을 재사용할 수 있습니다. YAML 앵커와 유사하지만 더 간단하며 extends와 includes를 함께 사용할 수 있습니다.
extends는 다단계 상속을 지원합니다. 추가적인 복잡성 때문에 세 단계 이상은 사용하지 않는 것이 좋지만, 최대 열한 단계까지 사용할 수 있습니다. 다음 예시에는 두 단계의 상속이 있습니다:
.tests:
rules:
- if: $CI_PIPELINE_SOURCE == "push"
.rspec:
extends: .tests
script: rake rspec
rspec 1:
variables:
RSPEC_SUITE: '1'
extends: .rspec
rspec 2:
variables:
RSPEC_SUITE: '2'
extends: .rspec
spinach:
extends: .tests
script: rake spinach
extends에서 키 제외 {#exclude-a-key-from-extends}#
확장된 콘텐츠에서 키를 제외하려면 다음 예시처럼 해당 키를 null로 지정해야 합니다:
.base:
script: test
variables:
VAR1: base var 1
test1:
extends: .base
variables:
VAR1: test1 var 1
VAR2: test2 var 2
test2:
extends: .base
variables:
VAR2: test2 var 2
test3:
extends: .base
variables: {}
test4:
extends: .base
variables: null
병합된 설정:
test1:
script: test
variables:
VAR1: test1 var 1
VAR2: test2 var 2
test2:
script: test
variables:
VAR1: base var 1
VAR2: test2 var 2
test3:
script: test
variables:
VAR1: base var 1
test4:
script: test
variables: null
extends와 include 함께 사용 {#use-extends-and-include-together}#
다른 설정 파일의 설정을 재사용하려면 extends와 include를 함께 사용하세요.
다음 예시에서 script는 included.yml 파일에 정의되어 있습니다. 그런 다음 .gitlab-ci.yml 파일에서 extends는 script의 내용을 참조합니다:
-
included.yml:.template: script: - echo Hello! -
.gitlab-ci.yml:include: included.yml useTemplate: image: alpine extends: .template
병합 세부 사항 {#merge-details}#
extends를 사용하여 해시를 병합할 수 있지만 배열은 병합할 수 없습니다. 중복 키가 있는 경우 GitLab은 키를 기반으로 역 깊이 우선 병합을 수행합니다. 마지막 멤버의 키가 항상 다른 단계에서 정의된 모든 것을 재정의합니다. 예를 들어:
.only-important:
variables:
URL: "http://my-url.internal"
IMPORTANT_VAR: "the details"
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_COMMIT_BRANCH == "stable"
tags:
- production
script:
- echo "Hello world!"
.in-docker:
variables:
URL: "http://docker-url.internal"
tags:
- docker
image: alpine
rspec:
variables:
GITLAB: "is-awesome"
extends:
- .only-important
- .in-docker
script:
- rake rspec
결과는 다음 rspec 잡입니다:
rspec:
variables:
URL: "http://docker-url.internal"
IMPORTANT_VAR: "the details"
GITLAB: "is-awesome"
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_COMMIT_BRANCH == "stable"
tags:
- docker
image: alpine
script:
- rake rspec
이 예시에서:
variables섹션은 병합되지만,URL: "http://docker-url.internal"이URL: "http://my-url.internal"을 덮어씁니다.tags: ['docker']가tags: ['production']을 덮어씁니다.script는 병합되지 않고,script: ['rake rspec']이script: ['echo "Hello world!"']를 덮어씁니다. 배열을 병합하려면 YAML 앵커를 사용할 수 있습니다.
!reference 태그 {#reference-tags}#
!reference 커스텀 YAML 태그를 사용하여 다른 잡 섹션에서 키워드 설정을 선택하고 현재 섹션에서 재사용할 수 있습니다. YAML 앵커와 달리, !reference 태그를 사용하여 포함된 설정 파일의 설정도 재사용할 수 있습니다.
!reference 태그를 사용하여 포함된 파일의 설정을 재정의하는 경우, 대신 CI/CD 입력을 사용하는 것을 고려하세요. !reference 태그는 입력 보간 전에 평가되므로 !reference 태그에서 CI/CD 입력을 사용할 수 없습니다.
다음 예시에서 두 개의 다른 위치에서 script와 after_script를 test 잡에서 재사용합니다:
-
configs.yml:.setup: script: - echo creating environment -
.gitlab-ci.yml:include: - local: configs.yml .teardown: after_script: - echo deleting environment test: script: - !reference [.setup, script] - echo running my own command after_script: - !reference [.teardown, after_script]
다음 예시에서 test-vars-1은 .vars의 모든 변수를 재사용하고, test-vars-2는 특정 변수를 선택하여 새 MY_VAR 변수로 재사용합니다.
.vars:
variables:
URL: "http://my-url.internal"
IMPORTANT_VAR: "the details"
test-vars-1:
variables: !reference [.vars, variables]
script:
- printenv
test-vars-2:
variables:
MY_VAR: !reference [.vars, variables, IMPORTANT_VAR]
script:
- printenv
여러 !reference 태그를 사용하여 rules, script, 또는 stages로 배열을 만들 수 있습니다. 예를 들어:
.rules_prod:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
.rules_staging:
- if: $CI_COMMIT_BRANCH =~ /^wip-.*/
- if: $CI_PIPELINE_SOURCE == "push"
deploy_job:
script: echo test
rules:
- !reference [.rules_prod]
- !reference [.rules_staging]
다른 모든 키워드에서는 config should be an array of 유효성 검사 오류가 발생합니다.
script, before_script, after_script에서 !reference 태그 중첩 {#nest-reference-tags-in-script-before_script-and-after_script}#
script, before_script, after_script 섹션에서 최대 10단계 깊이까지 !reference 태그를 중첩할 수 있습니다. 더 복잡한 스크립트를 만들 때 재사용 가능한 섹션을 정의하기 위해 중첩 태그를 사용하세요. 예를 들어:
.snippets:
one:
- echo "ONE!"
two:
- !reference [.snippets, one]
- echo "TWO!"
three:
- !reference [.snippets, two]
- echo "THREE!"
nested-references:
script:
- !reference [.snippets, three]
이 예시에서 nested-references 잡은 세 가지 echo 명령을 모두 실행합니다.
!reference 태그를 지원하도록 IDE 구성 {#configure-your-ide-to-support-reference-tags}#
파이프라인 편집기는 !reference 태그를 지원합니다. 그러나 !reference 같은 커스텀 YAML 태그에 대한 스키마 규칙은 기본적으로 편집기에서 유효하지 않은 것으로 처리될 수 있습니다. !reference 태그를 허용하도록 일부 편집기를 구성할 수 있습니다. 예를 들어:
-
VS Code에서
settings.json파일에서customTags를 파싱하도록vscode-yaml을 설정할 수 있습니다:"yaml.customTags": [ "!reference sequence" ] -
Sublime Text에서
LSP-yaml패키지를 사용하는 경우LSP-yaml사용자 설정에서customTags를 설정할 수 있습니다:{ "settings": { "yaml.customTags": ["!reference sequence"] } }
