다음을 사용하면 GitLab CI/CD 구성 파일의 복잡성과 중복된 구성을 줄일 수 있습니다.

• 앵커(&), 별칭(*), 맵 병합(<<)과 같은 YAML 고유 기능. 다양한 YAML 기능에 대해 자세히 알아보세요.
• 더 유연하고 가독성이 높은 extends 키워드. 가능하면 extends를 사용해야 합니다.

변수 값만 다르고 유사한 job을 여러 개 생성하려면 parallel:matrix를 사용합니다.

앵커#

YAML에는 문서 전체에서 콘텐츠를 복제하는 데 사용할 수 있는 '앵커'라는 기능이 있습니다.

앵커를 사용하면 속성을 복제하거나 상속할 수 있습니다. 숨겨진 job과 함께 앵커를 사용하면 job에 대한 템플릿을 제공할 수 있습니다.

& 문자는 앵커 이름을 표시하고, * 문자는 해당 앵커를 참조하는 별칭입니다. 앵커를 참조하는 별칭보다 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가 정의된 두 개의 job, test1과 test2를 생성합니다.

.job_template: &job_configuration  # Hidden yaml configuration that defines an anchor named 'job_configuration'
  image: ruby:2.6
  services:
    - postgres
    - redis

test1:
  <<: *job_configuration           # Add the contents of the 'job_configuration' alias
  script:
    - test1 project

test2:
  <<: *job_configuration           # Add the contents of the 'job_configuration' alias
  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

숨겨진 job 이 템플릿으로 편리하게 사용되며, tags: [postgres]가 tags: [dev]를 덮어쓰는 것을 확인할 수 있습니다.

스크립트용 YAML 앵커#

script, before_script, after_script와 함께 YAML 앵커를 사용하면 여러 job에서 미리 정의된 명령을 사용할 수 있습니다.

.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 사용#

extends 키워드를 사용하면 여러 job에서 구성을 재사용할 수 있습니다. YAML 앵커와 유사하지만 더 단순하며, extends를 include와 함께 사용할 수 있습니다.

extends는 다단계 상속을 지원합니다. 복잡성이 추가되므로 3단계를 초과해 사용하는 것은 피해야 하지만, 최대 11단계까지 사용할 수 있습니다. 다음 예시는 2단계 상속을 보여줍니다.

.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에서 키 제외하기#

확장된 콘텐츠에서 키를 제외하려면 해당 키를 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 함께 사용하기#

서로 다른 구성 파일의 구성을 재사용하려면 extends와 include를 함께 사용합니다.

다음 예시에서는 included.yml 파일에 script가 정의되어 있습니다. 이후 .gitlab-ci.yml 파일에서 extends가 해당 script의 내용을 참조합니다.

• included.yml:

  .template:
    script:
      - echo Hello!
  

• .gitlab-ci.yml:

  include: included.yml
  
  useTemplate:
    image: alpine
    extends: .template
  

병합 세부 정보#

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 job 입니다.

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 사용자 지정 YAML 태그를 사용하면 다른 job 섹션의 키워드 구성을 선택해 현재 섹션에서 재사용할 수 있습니다. YAML 앵커와 달리 !reference 태그는 포함된 구성 파일의 구성도 재사용할 수 있습니다.

포함된 파일의 구성을 재정의하기 위해 !reference 태그를 사용하고 있다면 대신 CI/CD 입력을 사용하는 것을 고려합니다.

!reference 태그와 입력을 함께 사용할 수 없습니다.

• !reference 태그의 경로 안에서는 입력을 사용할 수 없습니다. 예를 들어 !reference [.settings, "$[[ inputs.key ]]"]는 사용할 수 없습니다. 경로 세그먼트는 입력이 보간되기 전, YAML 파일이 파싱될 때 읽히기 때문에 입력이 리터럴 텍스트로 처리되어 참조를 찾을 수 없습니다.
• 입력 값에는 !reference 태그를 사용하지 않습니다. 태그는 입력이 보간된 후 확인되기 때문입니다.

다음 예시에서는 서로 다른 두 위치의 script와 after_script가 test job에서 재사용됩니다.

• 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 또는 stage로 배열을 구성할 수 있습니다. 예를 들면 다음과 같습니다.

.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 태그 중첩하기#

script, before_script, after_script 섹션에서 !reference 태그를 최대 10단계까지 중첩할 수 있습니다. 더 복잡한 스크립트를 작성할 때 중첩된 태그를 사용해 재사용 가능한 섹션을 정의합니다. 예를 들면 다음과 같습니다.

.snippets:
  one:
    - echo "ONE!"
  two:
    - !reference [.snippets, one]
    - echo "TWO!"
  three:
    - !reference [.snippets, two]
    - echo "THREE!"

nested-references:
  script:
    - !reference [.snippets, three]

이 예시에서 nested-references job은 세 개의 echo 명령을 모두 실행합니다.

!reference 태그를 지원하도록 IDE 구성하기#

파이프라인 에디터는 !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"]
    }
  }