InfoGrab Docs

GitLab CI/CD 설정 파일 최적화

요약

다음을 사용하여 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가 정의된 두 개의 잡 test1test2를 생성합니다:

.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:postgrestest: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}#

히스토리
  • stages 키워드와 함께 앵커 지원이 GitLab 16.9에서 도입되었습니다.

여러 잡에서 미리 정의된 명령을 사용하기 위해 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 앵커와 유사하지만 더 간단하며 extendsincludes를 함께 사용할 수 있습니다.

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

extendsinclude 함께 사용 {#use-extends-and-include-together}#

다른 설정 파일의 설정을 재사용하려면 extendsinclude를 함께 사용하세요.

다음 예시에서 scriptincluded.yml 파일에 정의되어 있습니다. 그런 다음 .gitlab-ci.yml 파일에서 extendsscript의 내용을 참조합니다:

  • 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 입력을 사용할 수 없습니다.

다음 예시에서 두 개의 다른 위치에서 scriptafter_scripttest 잡에서 재사용합니다:

  • 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}#

히스토리
  • stages 키워드와 함께 !reference 지원이 GitLab 16.9에서 도입되었습니다.

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"]
      }
    }
    

GitLab CI/CD 설정 파일 최적화

Tier: Free, Premium, Ultimate
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가 정의된 두 개의 잡 test1test2를 생성합니다:

.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:postgrestest: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}#

히스토리
  • stages 키워드와 함께 앵커 지원이 GitLab 16.9에서 도입되었습니다.

여러 잡에서 미리 정의된 명령을 사용하기 위해 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 앵커와 유사하지만 더 간단하며 extendsincludes를 함께 사용할 수 있습니다.

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

extendsinclude 함께 사용 {#use-extends-and-include-together}#

다른 설정 파일의 설정을 재사용하려면 extendsinclude를 함께 사용하세요.

다음 예시에서 scriptincluded.yml 파일에 정의되어 있습니다. 그런 다음 .gitlab-ci.yml 파일에서 extendsscript의 내용을 참조합니다:

  • 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 입력을 사용할 수 없습니다.

다음 예시에서 두 개의 다른 위치에서 scriptafter_scripttest 잡에서 재사용합니다:

  • 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}#

히스토리
  • stages 키워드와 함께 !reference 지원이 GitLab 16.9에서 도입되었습니다.

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"]
      }
    }