변수를 사용할 수 있는 위치
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
CI/CD 변수 문서에서 설명한 것처럼 다양한 변수를 정의할 수 있습니다. 이 문서는 다양한 유형의 변수를 어디에서 어떻게 사용할 수 있는지 설명합니다. 정의된 변수를 사용할 수 있는 두 곳이 있습니다: config.toml에 대한 자세한 내용은 GitLab Runner 문서를 참조하세요.
CI/CD 변수 문서에서 설명한 것처럼 다양한 변수를 정의할 수 있습니다. 일부는 모든 GitLab CI/CD 기능에 사용할 수 있지만, 일부는 다소 제한되어 있습니다.
이 문서는 다양한 유형의 변수를 어디에서 어떻게 사용할 수 있는지 설명합니다.
변수 사용#
정의된 변수를 사용할 수 있는 두 곳이 있습니다:
- GitLab 측,
.gitlab-ci.yml파일에서. - GitLab Runner 측,
config.toml에서.
.gitlab-ci.yml 파일#
히스토리
CI_ENVIRONMENT_SLUG를 제외한CI_ENVIRONMENT_*변수 지원이 GitLab 16.4에서 도입됨.
| 정의 | 확장 가능? | 확장 위치 | 설명 |
|---|---|---|---|
after_script |
yes | 스크립트 실행 셸 | 변수 확장은 실행 셸 환경에 의해 수행됩니다. |
artifacts:name |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
artifacts:paths |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
artifacts:exclude |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
before_script |
yes | 스크립트 실행 셸 | 변수 확장은 실행 셸 환경에 의해 수행됩니다. |
cache:key |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
cache:paths |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
cache:policy |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
environment:name |
yes | GitLab | environment:url과 유사하지만 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_* 변수.- 지속된 변수. |
environment:url |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. 잡에 대해 정의된 모든 변수가 지원됩니다(프로젝트/그룹 변수, .gitlab-ci.yml의 변수, 트리거의 변수, 파이프라인 예약의 변수).GitLab Runner config.toml에 정의된 변수와 잡의 script에서 생성된 변수는 지원되지 않습니다. |
environment:deployment_tier |
yes | GitLab | environment:url과 유사하지만 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_* 변수.- 지속된 변수. |
environment:auto_stop_in |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. 대체되는 변수의 값은 사람이 읽을 수 있는 자연어 형식의 기간이어야 합니다. 자세한 내용은 지원되는 값을 참조하세요. |
environment:kubernetes:agent |
yes | GitLab | environment:url과 유사하지만 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_* 변수.- 지속된 변수. |
environment:kubernetes:namespace |
yes | GitLab | environment:url과 유사하지만 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_* 변수.- 지속된 변수. |
id_tokens:aud |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. 변수 확장은 GitLab 16.1에서 도입됨. |
image |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
include |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. 지원되는 변수에 대한 자세한 내용은 include로 변수 사용을 참조하세요. |
resource_group |
yes | GitLab | environment:url과 유사하지만 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_URL- 지속된 변수. |
rules:changes |
no | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
rules:changes:compare_to |
no | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
rules:exists |
no | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
rules:if |
no | 해당 없음 | 변수는 $variable 형식이어야 합니다. 다음은 지원되지 않습니다:- CI_ENVIRONMENT_SLUG 변수.- 지속된 변수. |
script |
yes | 스크립트 실행 셸 | 변수 확장은 실행 셸 환경에 의해 수행됩니다. |
services:name |
yes | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
tags |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
trigger 및 trigger:project |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다. trigger:project에 대한 변수 확장은 GitLab 15.3에서 도입됨. |
variables |
yes | GitLab/Runner | 변수 확장은 먼저 GitLab의 내부 변수 확장 메커니즘에 의해 수행된 다음, 인식되지 않거나 사용할 수 없는 변수는 GitLab Runner의 내부 변수 확장 메커니즘에 의해 확장됩니다. |
workflow:name |
yes | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 수행됩니다.workflow에서 사용 가능한 모든 변수가 지원됩니다:- 프로젝트/그룹 변수. - 전역 variables 및 workflow:rules:variables(규칙과 일치할 때).- 상위 파이프라인에서 상속된 변수. - 트리거의 변수. - 파이프라인 예약의 변수. GitLab Runner config.toml에 정의된 변수, 잡에 정의된 변수, 또는 지속된 변수는 지원되지 않습니다. |
config.toml 파일#
| 정의 | 확장 가능? | 설명 |
|---|---|---|
runners.environment |
yes | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
runners.kubernetes.pod_labels |
yes | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
runners.kubernetes.pod_annotations |
yes | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 수행됩니다. |
config.toml에 대한 자세한 내용은 GitLab Runner 문서를 참조하세요.
확장 메커니즘#
세 가지 확장 메커니즘이 있습니다:
- GitLab
- GitLab Runner
- 실행 셸 환경
GitLab 내부 변수 확장 메커니즘#
확장될 부분은 $variable, ${variable} 또는 %variable% 형식이어야 합니다. 각 형식은 OS/셸에 상관없이 동일하게 처리됩니다. 확장이 러너가 잡을 받기 전에 GitLab에서 수행되기 때문입니다.
중첩 변수 확장#
GitLab은 잡 변수 값을 러너에게 보내기 전에 재귀적으로 확장합니다. 예를 들어 다음 시나리오에서:
- BUILD_ROOT_DIR: '${CI_BUILDS_DIR}'
- OUT_PATH: '${BUILD_ROOT_DIR}/out'
- PACKAGE_PATH: '${OUT_PATH}/pkg'
러너는 유효하고 완전히 형성된 경로를 받습니다. 예를 들어 ${CI_BUILDS_DIR}이 /output이면 PACKAGE_PATH는 /output/out/pkg가 됩니다.
사용할 수 없는 변수에 대한 참조는 그대로 유지됩니다. 이 경우 러너는 런타임에 변수 값을 확장하려고 시도합니다. 예를 들어 CI_BUILDS_DIR과 같은 변수는 런타임에만 러너에게 알려집니다.
GitLab Runner 내부 변수 확장 메커니즘#
- 지원됨: 프로젝트/그룹 변수,
.gitlab-ci.yml변수,config.toml변수, 트리거, 파이프라인 예약, 수동 파이프라인의 변수. - 지원되지 않음: 스크립트 내부에서 정의된 변수(예:
export MY_VARIABLE="test").
러너는 변수 확장에 Go의 os.Expand() 메서드를 사용합니다. 즉 $variable 및 ${variable}로 정의된 변수만 처리합니다. 또한 중요한 점은 확장이 한 번만 수행된다는 것으로, 중첩 변수는 변수 정의 순서와 GitLab에서 중첩 변수 확장이 활성화되어 있는지 여부에 따라 작동할 수도 있고 작동하지 않을 수도 있습니다.
아티팩트 및 캐시 업로드의 경우 러너는 os.Expand()가 파라미터 확장을 지원하므로 Go의 os.Expand() 대신 변수 확장에 mvdan.cc/sh/v3/expand를 사용합니다.
실행 셸 환경#
이것은 script 실행 중에 발생하는 확장 단계입니다. 동작은 사용된 셸(bash, sh, cmd, PowerShell)에 따라 다릅니다. 예를 들어 잡의 script에 echo $MY_VARIABLE-${MY_VARIABLE_2} 줄이 포함된 경우 bash/sh에서는 올바르게 처리해야 하지만(변수가 정의되었는지 여부에 따라 빈 문자열이나 일부 값을 남김), Windows의 cmd나 PowerShell에서는 작동하지 않습니다. 이러한 셸은 다른 변수 구문을 사용하기 때문입니다.
지원됨:
script는 셸의 기본값인 모든 사용 가능한 변수(예: 모든 bash/sh 셸에 있어야 하는$PATH)와 GitLab CI/CD에서 정의된 모든 변수(프로젝트/그룹 변수,.gitlab-ci.yml변수,config.toml변수, 트리거 및 파이프라인 예약의 변수)를 사용할 수 있습니다.script는 또한 이전 줄에서 정의된 모든 변수를 사용할 수 있습니다. 예를 들어export MY_VARIABLE="test"변수를 정의하면:before_script에서 정의 시before_script의 후속 줄과 관련script의 모든 줄에서 작동합니다.script에서 정의 시script의 후속 줄에서 작동합니다.after_script에서 정의 시after_script의 후속 줄에서 작동합니다.
after_script 스크립트의 경우:
- 동일한
after_script섹션 내에서 스크립트 이전에 정의된 변수만 사용할 수 있습니다. before_script및script에서 정의된 변수는 사용할 수 없습니다.
이러한 제한이 존재하는 이유는 after_script 스크립트가 별도의 셸 컨텍스트에서 실행되기 때문입니다.
지속된 변수#
일부 사전 정의 변수는 지속된 변수라고 합니다. 지속된 변수는:
파이프라인 트리거 잡은 잡 레벨 지속된 변수를 사용할 수 없지만 파이프라인 레벨 지속된 변수는 사용할 수 있습니다.
일부 지속된 변수에는 토큰이 포함되어 있으며 보안 이유로 일부 정의에서 사용할 수 없습니다.
파이프라인 레벨 지속된 변수:
CI_PIPELINE_IDCI_PIPELINE_URL
잡 레벨 지속된 변수:
CI_DEPLOY_PASSWORDCI_DEPLOY_USERCI_JOB_IDCI_JOB_STARTED_ATCI_JOB_TOKENCI_JOB_URLCI_PIPELINE_CREATED_ATCI_REGISTRY_PASSWORDCI_REGISTRY_USERCI_REPOSITORY_URL
환경 범위가 있는 변수#
환경 범위로 정의된 변수가 지원됩니다. review/staging/* 범위에서 $STAGING_SECRET 변수가 정의되어 있다면, 일치하는 변수 표현식을 기반으로 동적 환경을 사용하는 다음 잡이 생성됩니다:
my-job:
stage: staging
environment:
name: review/$CI_JOB_STAGE/deploy
script:
- 'deploy staging'
rules:
- if: $STAGING_SECRET == 'something'