GitLab CI/CD 구성 파일 최적화

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 관리, GitLab Dedicated

GitLab CI/CD 구성 파일에서 복잡성과 중복 구성을 줄일 수 있습니다. 다음을 사용하여:

  • anchors (&), 별칭 (*), 및 맵 병합 (<<)과 같은 YAML 특정 기능. 다양한 YAML 기능에 대해 더 알아보세요.
  • 더 유연하고 가독성 있는 extends 키워드를 사용하세요. 가능한 경우 extends를 사용해야 합니다.

Anchors

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

앵커를 사용하여 속성을 복제하거나 상속하세요. hidden jobs에 앵커를 사용하여 작업의 템플릿을 제공하세요. 중복 키가 있는 경우, 최신 포함된 키가 다른 키를 재정의합니다.

특정 경우(참조: 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 구성을 상속하는 두 개의 작업 test1 및 test2을 만들어, 각각 고유한 script가 정의됩니다: 

.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 앵커(스크립트용)

앵커를 script, before_script, 그리고 after_script와 함께 사용하여 여러 작업에서 사전에 정의된 명령을 사용할 수 있습니다: 

.some-script-before: &some-script-before
  - echo "먼저 이 스크립트를 실행"

.some-script: &some-script
  - echo "두 번째로 이 스크립트를 실행"
  - echo "이 스크립트도 실행"

.some-script-after: &some-script-after
  - echo "마지막으로 이 스크립트를 실행"

job1:
  before_script:
    - *some-script-before
  script:
    - *some-script
    - echo "이 작업 전용으로 무언가 실행"
  after_script:
    - *some-script-after

job2:
  script:
    - *some-script-before
    - *some-script
    - echo "다른 작업 전용으로 무언가 실행"
    - *some-script-after

extends를 사용하여 구성 섹션 재사용

여러 작업에서 구성을 재사용하려면 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에서 키 제외

확장된 내용에서 키를 제외하려면 해당 키를 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 작업: 

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 태그를 사용하세요. YAML 앵커와 달리 !reference 태그를 사용하여 포함된 구성 파일에서 구성을 재사용할 수 있습니다.

다음 예시에서 서로 다른 위치에 있는 script 및 after_script를 test 작업에서 재사용합니다:

  • setup.yml: 

    .setup:
  script:
    - echo creating environment

  • .gitlab-ci.yml: 

    include:
  - local: setup.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

script, before_script, 및 after_script에서 !reference 태그를 중첩시킵니다

  • GitLab 14.8에서 도입되었습니다.
  • stages 키워드로 !reference를 지원하는 기능은 GitLab 16.9에서 도입되었습니다.

!reference 태그를 script, before_script, 및 after_script 섹션에서 최대 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 작업은 모든 세 개의 echo 명령을 실행합니다.

IDE를 !reference 태그를 지원하도록 구성합니다

파이프라인 에디터는 !reference 태그를 지원합니다. 그러나 !reference와 같은 사용자 지정 YAML 태그에 대한 스키마 규칙은 기본적으로 편집기에서 잘못 처리될 수 있습니다. 몇몇 편집기를 !reference 태그를 수용하도록 설정할 수 있습니다. 예를 들어:

  • VS Code에서 settings.json 파일에서 vscode-yaml을 사용하여 customTags를 설정할 수 있습니다: 

    "yaml.customTags": [
   "!reference sequence"
]

  • Sublime Text를 사용하는 경우 LSP-yaml 패키지를 사용하고 있다면 LSP-yaml 사용자 설정에서 customTags를 설정할 수 있습니다: 

    {
  "settings": {
    "yaml.customTags": ["!reference sequence"]
  }
}