CI/CD inputs 예시

CI/CD inputs 예시 (CI/CD input examples)

CI/CD inputs는 CI/CD 구성을 유연하게 만들어주는 기능이에요. 이 페이지의 예시들을 가이드로 삼아서 파이프라인이 inputs를 사용하도록 구성해 보세요.

출처: 문서

본문

같은 파일을 여러 번 include 하기 (Include the same file multiple times)

같은 파일을 서로 다른 inputs로 여러 번 include할 수 있어요. 다만 이름이 같은 job이 한 파이프라인에 여러 개 추가되면, 추가된 job이 같은 이름의 이전 job을 덮어씁니다. 중복된 job 이름이 생기지 않도록 구성을 보장해야 해요.

다른 inputs로 같은 구성을 여러 번 include하는 예시입니다.

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의 구성은 include될 때마다 job이 고유한 이름을 갖도록 보장합니다.

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

`inputs`에서 구성 재사용하기 (Reuse configuration in `inputs`)

inputs로 구성을 재사용하려면 YAML 앵커를 쓸 수 있어요. 예를 들어 inputs에서 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

inputs에는 !reference 태그를 사용할 수 없어요. 이 기능을 추가하는 이슈 424481이 제안되어 있습니다.

`inputs`를 `needs`와 함께 사용하기 (Use `inputs` with `needs`)

복잡한 job 의존성에는 배열 타입 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 ]]

여기서 inputs는 first_needs와 second_needs로 둘 다 배열 타입 inputs예요. 그다음 .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

include 될 때 `needs`가 확장되도록 하기 (Allow `needs` to be expanded when included)

include된 job에 needs를 두고, spec:inputs로 needs 배열에 추가 job을 넣을 수도 있어요. 예를 들면 이렇습니다.

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: 배열 inputs가 기본값으로 비어 있기 때문에 테스트 job은 다른 job을 필요로 하지 않습니다.

구성에서 test-job이 다른 job을 필요로 하도록 설정하려면 파일을 include할 때 test_needs inputs에 추가하면 돼요. 예를 들면 이렇습니다.

include:
  - component: $CI_SERVER_FQDN/project/path/[email protected]
    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`가 없는 include된 job에 `needs` 추가하기 (Add `needs` to an included job that doesn't have `needs`)

아직 needs가 정의되지 않은 include된 job에 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 섹션은 job 이름을 커스터마이즈할 수 있게 해줘요. 컴포넌트를 include한 뒤 추가 needs 구성으로 job을 확장할 수 있습니다. 예를 들면 이렇습니다.

include:
  - component: $CI_SERVER_FQDN/project/path/[email protected]
    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"

더 동적인 파이프라인을 위해 `inputs`를 `include`와 함께 사용하기 (Use `inputs` with `include` for more dynamic pipelines)

inputs를 include와 함께 쓰면 추가로 include할 파이프라인 구성 파일을 선택할 수 있어요. 예를 들면 이렇습니다.

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 파일이 include돼요. 하지만 다른 pipeline-type inputs 옵션을 쓰면 다른 구성 파일이 include됩니다.

변수 표현식에서 CI/CD inputs 사용하기 (Use CI/CD inputs in variable expressions)

CI/CD inputs으로 변수 표현식을 커스터마이즈할 수 있어요. 예를 들면 이렇습니다.

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

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

입력 보간(Input interpolation): 파이프라인이 만들어지기 전에 inputs가 입력 값으로 바뀌어요. 이 예시에서 $[[ inputs.some_example ]] inputs는 설정된 값으로 치환됩니다. 예를 들어 값이 test-branch라면 표현식은 if: '"test-branch" == "test-branch"'가 되고, $CI_COMMIT_BRANCH라면 if: '"$CI_COMMIT_BRANCH" == "test-branch"'가 돼요.
표현식 평가(Expression evaluation): inputs가 보간된 뒤 GitLab이 파이프라인 만들기를 시도합니다. 파이프라인 생성 중에 표현식을 평가해 파이프라인에 추가할 job을 결정해요.

더 알아보기

inputs의 가장 큰 이점은 같은 구성을 여러 상황에서 재사용하는 거예요. 같은 파일을 여러 번 include하거나, needs 배열을 inputs로 확장하거나, 변수 표현식에서 inputs를 참조하는 등 예시를 하나씩 적용해 보세요. 배열 타입 inputs와 include:inputs 전달 방식은 특히 재사용 컴포넌트를 만들 때 유용합니다.

CI/CD inputs 예시