InfoGrab Docs

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"
...

디버그 로깅 활성화#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에는 작업에서 사용 가능한 모든 변수의 내용이 포함됩니다. 출력은 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 역할을 가진 사용자로 제한됩니다. 더 낮은 역할을 가진 사용자는 디버그 로깅이 다음에서 변수로 활성화된 경우 로그를 볼 수 없습니다:

Warning

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
    

트리거 작업에서 다운스트림 파이프라인으로 전달된 변수는 파이프라인 변수이므로 해결 방법은 다음과 같습니다:

기본 변수가 동일한 이름의 작업 변수에서 확장되지 않음#

기본 변수의 값을 동일한 이름의 작업 변수에서 사용할 수 없습니다. 기본 변수는 작업이 같은 이름으로 정의된 변수를 가지지 않을 때만 작업에서 사용할 수 있습니다. 작업에 같은 이름의 변수가 있으면 작업 변수가 우선하고 기본 변수는 작업에서 사용할 수 없습니다.

예를 들어, 다음 두 샘플은 동일합니다:

  • 이 샘플에서 $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'"

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"
...

디버그 로깅 활성화#

Warning

디버그 로깅은 심각한 보안 위험이 될 수 있습니다. 출력에는 작업에서 사용 가능한 모든 변수의 내용이 포함됩니다. 출력은 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 역할을 가진 사용자로 제한됩니다. 더 낮은 역할을 가진 사용자는 디버그 로깅이 다음에서 변수로 활성화된 경우 로그를 볼 수 없습니다:

Warning

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
    

트리거 작업에서 다운스트림 파이프라인으로 전달된 변수는 파이프라인 변수이므로 해결 방법은 다음과 같습니다:

기본 변수가 동일한 이름의 작업 변수에서 확장되지 않음#

기본 변수의 값을 동일한 이름의 작업 변수에서 사용할 수 없습니다. 기본 변수는 작업이 같은 이름으로 정의된 변수를 가지지 않을 때만 작업에서 사용할 수 있습니다. 작업에 같은 이름의 변수가 있으면 작업 변수가 우선하고 기본 변수는 작업에서 사용할 수 없습니다.

예를 들어, 다음 두 샘플은 동일합니다:

  • 이 샘플에서 $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'"