사용자 정의 스크립트를 사용하여 파이프라인 사용자 정의
사용자 정의 스크립트는 파이프라인에 추가된 사용자 정의입니다. 채택자, 팀 및 사용자는 전략의 지속적인 통합 및 지속적인 배치를 보장하기 위해 사용자 정의 태스크를 실행하는 스크립트를 제공합니다.
사용자 정의 스크립트는 파이프라인 스테이지를 제어합니다. 구성 파일(.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-tests 및 code-pr-finish |
| CI 파이프라인 | code-unit-tests, code-static-scan, code-compliance-checks, build-scan-artifact, code-dynamic-scan, deploy-acceptance-tests, deploy-release 및 code-ci-finish |
| cd 파이프라인 | prod-verify-artifact, prod-acceptance-tests 및 prod-finish |
| CC 파이프라인 | cc-static-scan, cc-dynamic-scan, cc-compliance-checks, cc-scan-artifact 및 cc-finish |
| 앱-PR 파이프라인 미리보기 | code-unit-tests, code-static-scan, code-compliance-checks, build-scan-artifact, deploy-acceptance-tests 및 app-preview-pr-finish |
| 개발 모드 CI 파이프라인 | code-unit-tests, code-static-scan, deploy-release 및 code-ci-finish |
| 개발 모드 CD 파이프라인 | prod-acceptance-tests 및 prod-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
...