InfoGrab Docs

CI/CD 입력 예시

요약

CI/CD 입력은 CI/CD 구성의 유연성을 높입니다. 같은 파일을 다른 입력으로 여러 번 포함할 수 있습니다. 예를 들어, 다른 입력으로 동일한 구성을 여러 번 포함하는 경우: path/to/my-super-linter.yml의 구성은 포함될 때마다 작업에 고유한 이름을 갖도록 합니다:

CI/CD 입력은 CI/CD 구성의 유연성을 높입니다. 이 예시를 파이프라인에서 입력을 사용하도록 구성하는 가이드라인으로 사용하세요.

동일한 파일을 여러 번 포함#

같은 파일을 다른 입력으로 여러 번 포함할 수 있습니다. 그러나 같은 이름의 여러 작업이 하나의 파이프라인에 추가되면 각 추가 작업은 같은 이름의 이전 작업을 덮어씁니다. 구성이 중복 작업 이름을 방지하도록 해야 합니다.

예를 들어, 다른 입력으로 동일한 구성을 여러 번 포함하는 경우:

include:
  - local: path/to/my-super-linter.yml
    inputs:
      linter: docs
      lint-path: "doc/"
  - local: path/to/my-super-linter.yml
    inputs:
      linter: yaml
      lint-path: "data/yaml/"

path/to/my-super-linter.yml의 구성은 포함될 때마다 작업에 고유한 이름을 갖도록 합니다:

spec:
  inputs:
    linter:
    lint-path:
---
"run-$[[ inputs.linter ]]-lint":
  script: ./lint --$[[ inputs.linter ]] --path=$[[ inputs.lint-path ]]

inputs에서 구성 재사용#

inputs로 구성을 재사용하려면 YAML 앵커를 사용할 수 있습니다.

예를 들어, 입력에서 rules 배열을 지원하는 여러 컴포넌트와 함께 동일한 rules 구성을 재사용하려면:

.my-job-rules: &my-job-rules
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

include:
  - component: $CI_SERVER_FQDN/project/path/component1@main
    inputs:
      job-rules: *my-job-rules
  - component: $CI_SERVER_FQDN/project/path/component2@main
    inputs:
      job-rules: *my-job-rules

입력에서 !reference 태그를 사용할 수 없지만 이슈 424481에서 이 기능 추가를 제안하고 있습니다.

needs와 함께 inputs 사용#

복잡한 작업 의존성을 위해 needs와 함께 배열 유형 입력을 사용할 수 있습니다.

예를 들어, component.yml이라는 파일에서:

spec:
  inputs:
    first_needs:
      type: array
    second_needs:
      type: array
---

test_job:
  script: echo "this job has needs"
  needs:
    - $[[ inputs.first_needs ]]
    - $[[ inputs.second_needs ]]

이 예시에서 입력은 first_needssecond_needs이며 둘 다 배열 유형 입력입니다. 그런 다음 .gitlab-ci.yml 파일에서 이 구성을 추가하고 입력 값을 설정할 수 있습니다:

include:
  - local: 'component.yml'
    inputs:
      first_needs:
        - build1
      second_needs:
        - build2

파이프라인이 시작되면 test_jobneeds 배열에 있는 항목들이 다음과 같이 연결됩니다:

test_job:
  script: echo "this job has needs"
  needs:
  - build1
  - build2

포함 시 needs 확장 허용#

포함된 작업에 needs가 있을 수 있지만 spec:inputs를 사용하여 needs 배열에 추가 작업을 추가할 수도 있습니다.

예:

spec:
  inputs:
    test_job_needs:
      type: array
      default: []
---

build-job:
  script:
    - echo "My build job"

test-job:
  script:
    - echo "My test job"
  needs:
    - build-job
    - $[[ inputs.test_job_needs ]]

이 예시에서:

  • test-job 작업은 항상 build-job이 필요합니다.
  • 기본적으로 test_job_needs: 배열 입력이 기본적으로 비어 있으므로 테스트 작업은 다른 작업이 필요하지 않습니다.

test-job이 구성에서 다른 작업을 필요로 하도록 설정하려면 파일을 포함할 때 test_needs 입력에 추가합니다. 예:

include:
  - component: $CI_SERVER_FQDN/project/path/component@1.0.0
    inputs:
      test_job_needs: [my-other-job]

my-other-job:
  script:
    - echo "I want build-job` in the component to need this job too"

needs가 없는 포함된 작업에 needs 추가#

이미 needs가 정의되지 않은 포함된 작업에 needs를 추가할 수 있습니다. 예를 들어, CI/CD 컴포넌트의 구성에서:

spec:
  inputs:
    test_job:
      default: test-job
---

build-job:
  script:
    - echo "My build job"

"$[[ inputs.test_job ]]":
  script:
    - echo "My test job"

이 예시에서 spec:inputs 섹션을 통해 작업 이름을 커스터마이징할 수 있습니다.

그런 다음 컴포넌트를 포함한 후 추가 needs 구성으로 작업을 확장할 수 있습니다. 예:

include:
  - component: $CI_SERVER_FQDN/project/path/component@1.0.0
    inputs:
      test_job: my-test-job

my-test-job:
  needs: [my-other-job]

my-other-job:
  script:
    - echo "I want `my-test-job` to need this job"

더 동적인 파이프라인을 위해 include와 함께 inputs 사용#

include와 함께 inputs를 사용하여 포함할 추가 파이프라인 구성 파일을 선택할 수 있습니다.

예:

spec:
  inputs:
    pipeline-type:
      type: string
      default: development
      options: ['development', 'canary', 'production']
      description: "The pipeline type, which determines which set of jobs to include."
---

include:
  - local: .gitlab/ci/$[[ inputs.pipeline-type ]].gitlab-ci.yml

이 예시에서 기본적으로 .gitlab/ci/development.gitlab-ci.yml 파일이 포함됩니다. 그러나 다른 pipeline-type 입력 옵션이 사용되면 다른 구성 파일이 포함됩니다.

변수 표현식에서 CI/CD 입력 사용#

CI/CD 입력을 사용하여 변수 표현식을 커스터마이징할 수 있습니다. 예:

example-job:
  script: echo "Testing"
  rules:
    - if: '"$[[ inputs.some_example ]]" == "test-branch"'

표현식은 두 단계로 평가됩니다:

  1. 입력 보간: 파이프라인이 생성되기 전에 입력이 입력 값으로 대체됩니다. 이 예시에서 $[[ inputs.some_example ]] 입력은 설정된 값으로 대체됩니다. 예를 들어 값이 다음과 같은 경우:

    • test-branch이면 표현식은 if: '"test-branch" == "test-branch"'이 됩니다.
    • $CI_COMMIT_BRANCH이면 표현식은 if: '"$CI_COMMIT_BRANCH" == "test-branch"'이 됩니다.
  2. 표현식 평가: 입력이 보간된 후 GitLab은 파이프라인을 만들려고 시도합니다. 파이프라인 생성 중에 표현식을 평가하여 파이프라인에 추가할 작업을 결정합니다.

CI/CD 입력 예시

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

CI/CD 입력은 CI/CD 구성의 유연성을 높입니다. 같은 파일을 다른 입력으로 여러 번 포함할 수 있습니다. 예를 들어, 다른 입력으로 동일한 구성을 여러 번 포함하는 경우: path/to/my-super-linter.yml의 구성은 포함될 때마다 작업에 고유한 이름을 갖도록 합니다:

CI/CD 입력은 CI/CD 구성의 유연성을 높입니다. 이 예시를 파이프라인에서 입력을 사용하도록 구성하는 가이드라인으로 사용하세요.

동일한 파일을 여러 번 포함#

같은 파일을 다른 입력으로 여러 번 포함할 수 있습니다. 그러나 같은 이름의 여러 작업이 하나의 파이프라인에 추가되면 각 추가 작업은 같은 이름의 이전 작업을 덮어씁니다. 구성이 중복 작업 이름을 방지하도록 해야 합니다.

예를 들어, 다른 입력으로 동일한 구성을 여러 번 포함하는 경우:

include:
  - local: path/to/my-super-linter.yml
    inputs:
      linter: docs
      lint-path: "doc/"
  - local: path/to/my-super-linter.yml
    inputs:
      linter: yaml
      lint-path: "data/yaml/"

path/to/my-super-linter.yml의 구성은 포함될 때마다 작업에 고유한 이름을 갖도록 합니다:

spec:
  inputs:
    linter:
    lint-path:
---
"run-$[[ inputs.linter ]]-lint":
  script: ./lint --$[[ inputs.linter ]] --path=$[[ inputs.lint-path ]]

inputs에서 구성 재사용#

inputs로 구성을 재사용하려면 YAML 앵커를 사용할 수 있습니다.

예를 들어, 입력에서 rules 배열을 지원하는 여러 컴포넌트와 함께 동일한 rules 구성을 재사용하려면:

.my-job-rules: &my-job-rules
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

include:
  - component: $CI_SERVER_FQDN/project/path/component1@main
    inputs:
      job-rules: *my-job-rules
  - component: $CI_SERVER_FQDN/project/path/component2@main
    inputs:
      job-rules: *my-job-rules

입력에서 !reference 태그를 사용할 수 없지만 이슈 424481에서 이 기능 추가를 제안하고 있습니다.

needs와 함께 inputs 사용#

복잡한 작업 의존성을 위해 needs와 함께 배열 유형 입력을 사용할 수 있습니다.

예를 들어, component.yml이라는 파일에서:

spec:
  inputs:
    first_needs:
      type: array
    second_needs:
      type: array
---

test_job:
  script: echo "this job has needs"
  needs:
    - $[[ inputs.first_needs ]]
    - $[[ inputs.second_needs ]]

이 예시에서 입력은 first_needssecond_needs이며 둘 다 배열 유형 입력입니다. 그런 다음 .gitlab-ci.yml 파일에서 이 구성을 추가하고 입력 값을 설정할 수 있습니다:

include:
  - local: 'component.yml'
    inputs:
      first_needs:
        - build1
      second_needs:
        - build2

파이프라인이 시작되면 test_jobneeds 배열에 있는 항목들이 다음과 같이 연결됩니다:

test_job:
  script: echo "this job has needs"
  needs:
  - build1
  - build2

포함 시 needs 확장 허용#

포함된 작업에 needs가 있을 수 있지만 spec:inputs를 사용하여 needs 배열에 추가 작업을 추가할 수도 있습니다.

예:

spec:
  inputs:
    test_job_needs:
      type: array
      default: []
---

build-job:
  script:
    - echo "My build job"

test-job:
  script:
    - echo "My test job"
  needs:
    - build-job
    - $[[ inputs.test_job_needs ]]

이 예시에서:

  • test-job 작업은 항상 build-job이 필요합니다.
  • 기본적으로 test_job_needs: 배열 입력이 기본적으로 비어 있으므로 테스트 작업은 다른 작업이 필요하지 않습니다.

test-job이 구성에서 다른 작업을 필요로 하도록 설정하려면 파일을 포함할 때 test_needs 입력에 추가합니다. 예:

include:
  - component: $CI_SERVER_FQDN/project/path/component@1.0.0
    inputs:
      test_job_needs: [my-other-job]

my-other-job:
  script:
    - echo "I want build-job` in the component to need this job too"

needs가 없는 포함된 작업에 needs 추가#

이미 needs가 정의되지 않은 포함된 작업에 needs를 추가할 수 있습니다. 예를 들어, CI/CD 컴포넌트의 구성에서:

spec:
  inputs:
    test_job:
      default: test-job
---

build-job:
  script:
    - echo "My build job"

"$[[ inputs.test_job ]]":
  script:
    - echo "My test job"

이 예시에서 spec:inputs 섹션을 통해 작업 이름을 커스터마이징할 수 있습니다.

그런 다음 컴포넌트를 포함한 후 추가 needs 구성으로 작업을 확장할 수 있습니다. 예:

include:
  - component: $CI_SERVER_FQDN/project/path/component@1.0.0
    inputs:
      test_job: my-test-job

my-test-job:
  needs: [my-other-job]

my-other-job:
  script:
    - echo "I want `my-test-job` to need this job"

더 동적인 파이프라인을 위해 include와 함께 inputs 사용#

include와 함께 inputs를 사용하여 포함할 추가 파이프라인 구성 파일을 선택할 수 있습니다.

예:

spec:
  inputs:
    pipeline-type:
      type: string
      default: development
      options: ['development', 'canary', 'production']
      description: "The pipeline type, which determines which set of jobs to include."
---

include:
  - local: .gitlab/ci/$[[ inputs.pipeline-type ]].gitlab-ci.yml

이 예시에서 기본적으로 .gitlab/ci/development.gitlab-ci.yml 파일이 포함됩니다. 그러나 다른 pipeline-type 입력 옵션이 사용되면 다른 구성 파일이 포함됩니다.

변수 표현식에서 CI/CD 입력 사용#

CI/CD 입력을 사용하여 변수 표현식을 커스터마이징할 수 있습니다. 예:

example-job:
  script: echo "Testing"
  rules:
    - if: '"$[[ inputs.some_example ]]" == "test-branch"'

표현식은 두 단계로 평가됩니다:

  1. 입력 보간: 파이프라인이 생성되기 전에 입력이 입력 값으로 대체됩니다. 이 예시에서 $[[ inputs.some_example ]] 입력은 설정된 값으로 대체됩니다. 예를 들어 값이 다음과 같은 경우:

    • test-branch이면 표현식은 if: '"test-branch" == "test-branch"'이 됩니다.
    • $CI_COMMIT_BRANCH이면 표현식은 if: '"$CI_COMMIT_BRANCH" == "test-branch"'이 됩니다.
  2. 표현식 평가: 입력이 보간된 후 GitLab은 파이프라인을 만들려고 시도합니다. 파이프라인 생성 중에 표현식을 평가하여 파이프라인에 추가할 작업을 결정합니다.