사용자 정의 스크립트를 사용하여 파이프라인 사용자 정의

사용자 정의 스크립트는 파이프라인에 추가된 사용자 정의입니다. 채택자, 팀 및 사용자는 전략의 지속적인 통합 및 지속적인 배치를 보장하기 위해 사용자 정의 태스크를 실행하는 스크립트를 제공합니다.

사용자 정의 스크립트는 파이프라인 스테이지를 제어합니다. 구성 파일(.pipeline-config.yaml)을 사용하여 스테이지의 동작, 스크립트 내용, 그리고 스크립트를 실행하는 기본 이미지를 구성할 수 있습니다. 파이프라인 스테이지의 스크립트 및 구성은 애플리케이션(앱) 저장소(.travis.yml 또는 Jenkinsfile과 유사) 또는 사용자 정의 저장소일 수 있는 Git 저장소에서 로드됩니다.

사용자 지정 스크립트가 시작되면 파일 이름과 커밋 해시를 포함한 사용자 지정 스크립트 파일의 전체 URL 가 파이프라인 로그의 시작 부분에 다음과 같이 인쇄됩니다: The custom script can be viewed using the following link: 'https://<source repo url>/<organization name>/<repository name>/blob/<commit hash>/.pipeline-config.yaml'. 이 위치 지정은 추적성을 향상시킵니다.

자세한 내용은 초보자를 위한 DevSecOps 파이프라인 사용자 지정을 참조하세요.

설정 위치: .pipeline-config.yaml

.pipeline-config.yaml 구성 파일을 사용하여 파이프라인 동작을 확장하십시오.

파일 위치

풀 리퀘스트 및 지속적 통합 파이프라인의 경우, .pipeline-config.yaml 구성 파일을 .travis.yml`` 또는 Jenkinsfile 파일과 동일한 방식으로 앱 저장소에 저장하십시오. 지속적 배포 파이프라인의 경우, 이 파일을 전용 저장소에 저장하십시오.

모든 파이프라인의 경우 다음 파이프라인 UI 매개변수를 사용하여 .pipeline-config.yaml의 위치 및 소스를 사용자 정의할 수 있습니다.

  • 구성 파일의 경로를 설정하려면 pipeline-config를 사용합니다. 기본값은 .pipeline-config.yaml입니다.
  • pipeline-config-repo 구성 및 스크립트를 가져올 저장소를 설정하려면. 기본값은 지속 통합 앱 저장소입니다.
  • pipeline-config-branch 구성 저장소의 구성에 대한 브랜치로 사용하기 위해. 기본값은 지속 통합(CI) 앱 저장소의 브랜치이며, 지속 배포(CD)의 경우 master 브랜치입니다.

구성 매개변수

.pipeline-config.yaml 파일의 구성은 다음 매개변수를 지원합니다.

이러한 설정은 파이프라인 매개변수가 아니며 .pipeline-config.yaml 파일의 일부여야 합니다.

  • image: 태스크의 기본 이미지로 파이프라인 작업자에서 액세스 가능한 Docker 이미지를 사용할 수 있습니다.

  • script: 스테이지에서 실행할 스크립트입니다. 이 필드는 스크립트 파일로 사용되므로, 제공한 기본 이미지에서 해당 내용이 스크립트 파일처럼 작동하는지 확인하십시오. 이 구성 파일 옆에 다른 스크립트를 포함하고 이 시작점에서 이 스크립트를 참조할 수 있습니다. 예를 들어, 다음과 같습니다.

test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    scripts/lint.sh
    scripts/unit-test.sh
  • dind: 스크립트 컨텍스트에 docker-in-docker를 사용할지 여부를 지정합니다. 기본 설정은 false입니다.

  • abort_on_failure: 기본적으로 스크립트가 실패하면 파이프라인이 중지됩니다. 이를 false 로 설정하면 단계가 경고 (황색 상태) 로 표시되고 (경고와 함께 전달됨) 파이프라인이 계속될 수 있으며 실패한 작업이 증거에서 참조됩니다.

  • image_pull_policy: 기본 이미지에 대해 이미지에 제공된 ‘ ImagePullPolicy ’ 설정을 지정하십시오. 가능한 값은 Kubernetes의 유효한 값(Always 또는 IfNotPresent)과 동일합니다. 기본값은 IfNotPresent입니다.

  • configmap: PipelineRun에서 액세스 가능한 제공된 configmap에서 키-값 쌍을 가져옵니다. 지원되는 값은 다음과 같습니다.

    • config-name: 직접 configmap 이름 구문입니다. 스테이지 실행기가 config-name이라는 configmap을 액세스하고 마운트하려고 합니다.
    • $prop-name: 간접적 configmap 이름 구문입니다. configmap 이름은 파이프라인 UI에 설정된 모든 환경 값을 포함하는 환경 특성 configmap에서 검색됩니다. 예를 들어, 환경 속성에 ‘ my-config ’라는 속성이 설정되어 있다면, ‘ $prop ’에 대해 ‘ my-config ’가 사용됩니다.
  • secret: PipelineRun에서 액세스 가능한 제공된 configmap에서 키-값 쌍을 가져옵니다. 지원되는 값은 다음과 같습니다.

    • secret-name: 직접 시크릿 이름 구문입니다. 스테이지 실행기가 secret-name이라는 시크릿을 액세스하고 마운트하려고 합니다.

    • $prop-name: 간접 시크릿 이름 구문입니다. 'Secret' 이름은 파이프라인 UI에서 설정된 모든 환경 값을 포함하는 environment-properties 구성 맵에 있습니다. 예를 들어, 환경 특성 configmap에 my-secret 특성이 포함된 경우 my-secret$prop에 사용됩니다.

  • runAfter: 이 특성에 지정된 스테이지가 완료된 후 현재 스테이지를 실행합니다. .pipeline-config.yaml 에서 사용한 스테이지 이름으로 값을 설정하십시오. 이 특성을 사용하지 말고 이 특성으로 지정된 단계가 파이프라인에 있는지 확인하십시오. 단계가 존재하지 않으면 파이프라인이 교착 상태가 될 수 있습니다.

  • skip: true 로 설정된 경우, 가능하면 v10 파이프라인에서 현재 단계를 생략하십시오. 모든 스테이지를 생략할 수 있는 것은 아닙니다. 다음 표에는 파이프라인 실행 중에 건너뛸 수 있는 단계가 나열되어 있습니다.

파이프라인 실행에서 건너뛸 수 있는 단계
파이프라인 스테이지
PR 파이프라인 code-unit-tests, code-compliance-testscode-pr-finish
CI 파이프라인 code-unit-tests, code-static-scan, code-compliance-checks, build-scan-artifact, code-dynamic-scan, deploy-acceptance-tests, deploy-releasecode-ci-finish
cd 파이프라인 prod-verify-artifact, prod-acceptance-testsprod-finish
CC 파이프라인 cc-static-scan, cc-dynamic-scan, cc-compliance-checks, cc-scan-artifactcc-finish
앱-PR 파이프라인 미리보기 code-unit-tests, code-static-scan, code-compliance-checks, build-scan-artifact, deploy-acceptance-testsapp-preview-pr-finish
개발 모드 CI 파이프라인 code-unit-tests, code-static-scan, deploy-releasecode-ci-finish
개발 모드 CD 파이프라인 prod-acceptance-testsprod-finish

구성 예

version: '1' # fixed, this value is used to track schema changes
# `setup` runs right after the app repo is cloned
setup:
  # the pipeline will break in case setup fails (default is true)
  abort_on_failure: true
  # any docker image can be used which is accessible by the private worker
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # you can reference configmaps, each key in the configmap is going to be available as `/config/{key}`
  configmap: my-config
    # `$prop` is the indirect config map syntax, the concrete configmap is looked
    # up from the `environment-properties` configmap
    #
    # Eg. if there's a `prop: my-config` entry in the environment properties,
    # then `my-config` is going to be used for `$prop`
  configmap: $prop
  # the mechanism described works for secrets as well!
  secret: $my-secrets
  # the script is executed inside the checked out app repo
  script: |
    #!/bin/sh
    ...
# `test` runs after `setup`, but before building the docker image
test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...
# `static-scan` runs after `test`, but before building the docker image
static-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `deploy` runs after building the docker image
deploy:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # the script has access to the built docker image, which is available at `/config/image`
  script: |
    #!/bin/sh
    cat /config/image
# `dynamic-scan` runs after `deploy`, but before the acceptance test run
dynamic-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `acceptance-test` runs after `deploy`
acceptance-test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...