CI/CD 입력 예시
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_needs와 second_needs이며 둘 다 배열 유형 입력입니다.
그런 다음 .gitlab-ci.yml 파일에서 이 구성을 추가하고 입력 값을 설정할 수 있습니다:
include:
- local: 'component.yml'
inputs:
first_needs:
- build1
second_needs:
- build2
파이프라인이 시작되면 test_job의 needs 배열에 있는 항목들이 다음과 같이 연결됩니다:
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"'
표현식은 두 단계로 평가됩니다:
-
입력 보간: 파이프라인이 생성되기 전에 입력이 입력 값으로 대체됩니다. 이 예시에서
$[[ inputs.some_example ]]입력은 설정된 값으로 대체됩니다. 예를 들어 값이 다음과 같은 경우:test-branch이면 표현식은if: '"test-branch" == "test-branch"'이 됩니다.$CI_COMMIT_BRANCH이면 표현식은if: '"$CI_COMMIT_BRANCH" == "test-branch"'이 됩니다.
-
표현식 평가: 입력이 보간된 후 GitLab은 파이프라인을 만들려고 시도합니다. 파이프라인 생성 중에 표현식을 평가하여 파이프라인에 추가할 작업을 결정합니다.
