CI/CD 변수 문제 해결
Bash에서 export 명령, PowerShell에서 dir env:를 사용하여 스크립트에서 사용 가능한 모든 변수를 나열할 수 있습니다. 디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 디버그 로깅을 사용하여 파이프라인 구성 또는 작업 스크립트 문제를 해결할 수 있습니다.
모든 변수 나열#
Bash에서 export 명령, PowerShell에서 dir env:를 사용하여 스크립트에서 사용 가능한 모든 변수를 나열할 수 있습니다. 이는 사용 가능한 모든 변수의 값을 노출하며, 보안 위험이 될 수 있습니다.
마스킹된 변수는 [MASKED]로 표시됩니다.
예를 들어, Bash 사용:
job_name:
script:
- export
작업 로그 출력 예시(일부 발췌):
export CI_JOB_ID="50"
export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
export CI_COMMIT_SHORT_SHA="1ecfd275"
export CI_COMMIT_REF_NAME="main"
export CI_REPOSITORY_URL="https://gitlab-ci-token:[MASKED]@example.com/gitlab-org/gitlab.git"
export CI_COMMIT_TAG="1.0.0"
export CI_JOB_NAME="spec:other"
export CI_JOB_STAGE="test"
export CI_JOB_MANUAL="true"
export CI_JOB_TRIGGERED="true"
export CI_JOB_TOKEN="[MASKED]"
export CI_PIPELINE_ID="1000"
export CI_PIPELINE_IID="10"
export CI_PAGES_DOMAIN="gitlab.io"
export CI_PAGES_URL="https://gitlab-org.gitlab.io/gitlab"
export CI_PROJECT_ID="34"
export CI_PROJECT_DIR="/builds/gitlab-org/gitlab"
export CI_PROJECT_NAME="gitlab"
export CI_PROJECT_TITLE="GitLab"
...
디버그 로깅 활성화#
디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에는 작업에서 사용 가능한 모든 변수의 내용이 포함됩니다. 출력은 GitLab 서버에 업로드되어 작업 로그에서 볼 수 있습니다.
디버그 로깅을 사용하여 파이프라인 구성 또는 작업 스크립트 문제를 해결할 수 있습니다. 디버그 로깅은 러너에 의해 일반적으로 숨겨지는 작업 실행 세부 정보를 노출하고 작업 로그를 더 상세하게 만듭니다. 또한 작업에서 사용 가능한 모든 변수와 시크릿을 노출합니다.
디버그 로깅을 활성화하기 전에 팀원만 작업 로그를 볼 수 있는지 확인합니다. 또한 로그를 다시 공개하기 전에 디버그 출력이 포함된 작업 로그를 삭제해야 합니다.
디버그 로깅을 활성화하려면 CI_DEBUG_TRACE 변수를 true로 설정합니다:
job_name:
variables:
CI_DEBUG_TRACE: "true"
출력 예시(일부 발췌):
...
export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE"
if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
echo $'\''\x1b[32;1mFetching changes...\x1b[0;m'\''
$'\''cd'\'' "/builds/gitlab-examples/ci-debug-trace"
$'\''git'\'' "config" "fetch.recurseSubmodules" "false"
$'\''rm'\'' "-f" ".git/index.lock"
$'\''git'\'' "clean" "-ffdx"
$'\''git'\'' "reset" "--hard"
$'\''git'\'' "remote" "set-url" "origin" "https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git"
$'\''git'\'' "fetch" "origin" "--prune" "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/lds"
++ CI_BUILDS_DIR=/builds
++ export CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ export CI_CONCURRENT_ID=87
++ CI_CONCURRENT_ID=87
++ export CI_CONCURRENT_PROJECT_ID=0
++ CI_CONCURRENT_PROJECT_ID=0
++ export CI_SERVER=yes
++ CI_SERVER=yes
++ mkdir -p /builds/gitlab-examples/ci-debug-trace.tmp
++ echo -n '-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----'
++ export CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ export CI_PIPELINE_ID=52666
++ CI_PIPELINE_ID=52666
++ export CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ export CI_JOB_ID=7046507
++ CI_JOB_ID=7046507
++ export CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ export CI_JOB_TOKEN=[MASKED]
++ CI_JOB_TOKEN=[MASKED]
++ export CI_REGISTRY_USER=gitlab-ci-token
++ CI_REGISTRY_USER=gitlab-ci-token
++ export CI_REGISTRY_PASSWORD=[MASKED]
++ CI_REGISTRY_PASSWORD=[MASKED]
++ export CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ export CI_JOB_NAME=debug_trace
++ CI_JOB_NAME=debug_trace
++ export CI_JOB_STAGE=test
++ CI_JOB_STAGE=test
++ export CI_NODE_TOTAL=1
++ CI_NODE_TOTAL=1
++ export CI=true
++ CI=true
++ export GITLAB_CI=true
++ GITLAB_CI=true
++ export CI_SERVER_URL=https://gitlab.com:3000
++ CI_SERVER_URL=https://gitlab.com:3000
++ export CI_SERVER_HOST=gitlab.com
++ CI_SERVER_HOST=gitlab.com
++ export CI_SERVER_PORT=3000
++ CI_SERVER_PORT=3000
++ export CI_SERVER_SHELL_SSH_HOST=gitlab.com
++ CI_SERVER_SHELL_SSH_HOST=gitlab.com
++ export CI_SERVER_SHELL_SSH_PORT=22
++ CI_SERVER_SHELL_SSH_PORT=22
++ export CI_SERVER_PROTOCOL=https
++ CI_SERVER_PROTOCOL=https
++ export CI_SERVER_NAME=GitLab
++ CI_SERVER_NAME=GitLab
...
디버그 로깅 접근#
디버그 로깅 접근은 Developer, Maintainer 또는 Owner 역할을 가진 사용자로 제한됩니다. 더 낮은 역할을 가진 사용자는 디버그 로깅이 다음에서 변수로 활성화된 경우 로그를 볼 수 없습니다:
.gitlab-ci.yml파일.- GitLab UI에서 설정된 CI/CD 변수.
CI_DEBUG_TRACE를 러너에 로컬 변수로 추가하면 디버그 로그가 생성되어
작업 로그에 접근할 수 있는 모든 사용자에게 표시됩니다. 권한 수준은 러너에서 확인하지 않으므로
GitLab 자체에서만 변수를 사용해야 합니다.
argument list too long 오류#
이 문제는 작업에 정의된 모든 CI/CD 변수의 결합된 길이가 작업이 실행되는 셸이 부과하는 제한을 초과할 때 발생합니다. 여기에는 사전 정의된 변수와 사용자 정의 변수의 이름과 값이 포함됩니다. 이 제한은 일반적으로 ARG_MAX라고 하며 셸 및 운영 체제에 따라 다릅니다. 단일 파일 유형 변수의 내용이 ARG_MAX를 초과할 때도 이 문제가 발생합니다.
자세한 내용은 이슈 392406을 참조하세요.
해결 방법:
- 가능한 경우 대용량 환경 변수에 파일 유형 CI/CD 변수를 사용합니다.
- 단일 대용량 변수가
ARG_MAX보다 큰 경우 보안 파일을 사용하거나, 다른 메커니즘을 통해 파일을 작업에 가져오도록 시도합니다.
다운스트림 파이프라인에 대한 Insufficient permissions to set pipeline variables 오류#
다운스트림 파이프라인을 트리거할 때 이 오류가 예기치 않게 발생할 수 있습니다:
Failed - (downstream pipeline can not be created, Insufficient permissions to set pipeline variables)
이 오류는 다운스트림 프로젝트에 파이프라인 변수가 제한되어 있고 트리거 작업이 다음 중 하나인 경우 발생합니다:
-
변수가 정의되어 있습니다. 예를 들어:
trigger-job: variables: VAR_FOR_DOWNSTREAM: "test" trigger: my-group/my-project -
최상위
variables섹션에 정의된 기본 변수에서 변수를 받습니다. 예를 들어:variables: DEFAULT_VAR: "test" trigger-job: trigger: my-group/my-project
트리거 작업에서 다운스트림 파이프라인으로 전달된 변수는 파이프라인 변수이므로 해결 방법은 다음과 같습니다:
- 변수 전달을 피하기 위해 트리거 작업에 정의된
variables를 제거합니다. - 기본 변수가 다운스트림 파이프라인에 전달되는 것을 방지합니다.
기본 변수가 동일한 이름의 작업 변수에서 확장되지 않음#
기본 변수의 값을 동일한 이름의 작업 변수에서 사용할 수 없습니다. 기본 변수는 작업이 같은 이름으로 정의된 변수를 가지지 않을 때만 작업에서 사용할 수 있습니다. 작업에 같은 이름의 변수가 있으면 작업 변수가 우선하고 기본 변수는 작업에서 사용할 수 없습니다.
예를 들어, 다음 두 샘플은 동일합니다:
-
이 샘플에서
$MY_VAR은 어디에도 정의되지 않았기 때문에 값이 없습니다:Job-with-variable: variables: MY_VAR: $MY_VAR script: echo "Value is '$MY_VAR'" -
이 샘플에서
$MY_VAR은 같은 이름의 기본 변수가 작업에서 사용할 수 없기 때문에 값이 없습니다:variables: MY_VAR: "Default value" Job-with-same-name-variable: variables: MY_VAR: $MY_VAR script: echo "Value is '$MY_VAR'"
두 경우 모두 echo 명령은 Value is '$MY_VAR'를 출력합니다.
일반적으로 기본 변수를 새 변수에 재할당하는 것보다 작업에서 직접 사용해야 합니다. 이것이 필요한 경우 대신 다른 이름의 변수를 사용합니다. 예를 들어:
variables:
MY_VAR1: "Default value1"
MY_VAR2: "Default value2"
overwrite-same-name:
variables:
MY_VAR2_FROM_DEFAULTS: $MY_VAR2
script: echo "Values are '$MY_VAR1' and '$MY_VAR2_FROM_DEFAULTS'"
