변수 사용 위치
CI/CD 변수 문서에 설명된대로 다양한 변수를 정의할 수 있습니다. 일부 변수는 GitLab CI/CD의 모든 기능에 사용될 수 있지만, 일부는 좀 더 제한적입니다.
변수 사용법
정의된 변수는 두 곳에서 사용할 수 있습니다. 다음 위치에서:
-
.gitlab-ci.yml
파일에서 GitLab 측. -
config.toml
에서 GitLab Runner 측.
.gitlab-ci.yml
파일
CI_ENVIRONMENT_SLUG
를 제외한CI_ENVIRONMENT_*
변수는 GitLab 16.4에서 도입되었습니다.
정의 | 확장 가능? | 확장 위치 | 설명 |
---|---|---|---|
after_script
| 예 | 스크립트 실행 쉘 | 변수 확장은 실행 쉘 환경에 의해 이루어집니다. |
artifacts:name
| 예 | Runner | 변수 확장은 GitLab Runner의 쉘 환경에 의해 이루어집니다. |
artifacts:paths
| 예 | Runner | 변수 확장은 GitLab Runner의 쉘 환경에 의해 이루어집니다. |
before_script
| 예 | 스크립트 실행 쉘 | 변수 확장은 실행 쉘 환경에 의해 이루어집니다. |
cache:key
| 예 | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
cache:policy
| 예 | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
environment:name
| 예 | GitLab |
environment:url 과 유사하지만, 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_* 변수.- 지속 변수. |
environment:url
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. 작업에 정의된 모든 변수가 지원됩니다(프로젝트/그룹 변수, .gitlab-ci.yml 의 변수, 트리거의 변수, 파이프라인 스케줄의 변수).GitLab Runner config.toml 에 정의된 변수와 작업의 script 에 생성된 변수는 지원되지 않습니다.
|
environment:auto_stop_in
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. 대체될 변수의 값은 인간이 읽기 쉬운 자연어 형식의 시간 기간이어야 합니다. 자세한 정보는 가능한 입력을 참조하십시오. |
except:variables (Deprecated)
| 아니오 | 해당 없음 | 변수는 $variable 형식이어야 합니다. 다음을 지원하지 않습니다:- CI_ENVIRONMENT_SLUG 변수.- 지속 변수. |
id_tokens:aud
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. 변수 확장은 GitLab 16.1에서 도입되었습니다. |
image
| 예 | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
include
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. 자세한 정보는 include로 변수 사용를 참조하십시오. |
only:variables (Deprecated)
| 아니오 | 해당 없음 | 변수는 $variable 형식이어야 합니다. 다음을 지원하지 않습니다:- CI_ENVIRONMENT_SLUG 변수.- 지속 변수. |
resource_group
| 예 | GitLab |
environment:url 과 유사하지만, 변수 확장은 다음을 지원하지 않습니다:- CI_ENVIRONMENT_URL - 지속 변수. |
rules:changes
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
rules:exists
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
rules:if
| 아니오 | 해당 없음 | 변수는 $variable 형식이어야 합니다. 다음을 지원하지 않습니다:- CI_ENVIRONMENT_SLUG 변수.- 지속 변수. |
script
| 예 | 스크립트 실행 쉘 | 변수 확장은 실행 쉘 환경에 의해 이루어집니다. |
services:name
| 예 | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
services
| 예 | Runner | 변수 확장은 GitLab Runner의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
tags
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. |
trigger 및 trigger:project
| 예 | GitLab | 변수 확장은 GitLab의 내부 변수 확장 메커니즘에 의해 이루어집니다. trigger:project 의 변수 확장은 GitLab 15.3에서 도입되었습니다.
|
variables
| 예 | GitLab/Runner | 변수 확장은 먼저 GitLab의 내부 변수 확장 메커니즘에 의해 이루어지고, 인식되지 않거나 사용할 수 없는 변수는 GitLab Runner의 내부 변수 확장 메커니즘에 의해 확장됩니다. |
workflow:name
| 예 | 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'
Runner는 유효한 완전한 경로를 받게 됩니다. 예를 들어, ${CI_BUILDS_DIR}
가 /output
인 경우 PACKAGE_PATH
는 /output/out/pkg
가 될 것입니다.
사용할 수 없는 변수에 대한 참조는 그대로 남아 있습니다. 이 경우 Runner는
실행시 변수 값을 확장하려고 시도합니다.
예를 들어, CI_BUILDS_DIR
와 같은 변수는 실행 시에만 Runner에서 알 수 있습니다.
GitLab Runner 내부 변수 확장 메커니즘
- 지원됨: 프로젝트/그룹 변수,
.gitlab-ci.yml
변수,config.toml
변수, 그리고 트리거, 파이프라인 스케줄, 매뉴얼 파이프라인의 변수. - 지원되지 않음: 스크립트 내에서 정의된 변수 (예:
export MY_VARIABLE="test"
).
Runner는 변수 확장을 위해 Go의 os.Expand()
메서드를 사용합니다. 이는 $variable
및 ${variable}
로 정의된 변수만 처리한다는 것을 의미합니다. 또한, 확장은 한 번만 이루어지므로 중첩 변수는 GitLab에서 활성화된 중첩 변수 확장 및 변수 정의의 순서에 따라 작동할 수도, 작동하지 않을 수도 있습니다.
실행 쉘 환경
이는 script
실행 중에 발생하는 확장 단계입니다.
이 동작은 사용된 셸에 따라 달라집니다 (bash
, sh
, cmd
, PowerShell). 예를 들어, job의
script
에 echo $MY_VARIABLE-${MY_VARIABLE_2}
와 같은 줄이 포함되어 있다면,
bash나 sh에서는 올바르게 처리가 될 것이고 (변수가 정의되었는지에 따라 빈 문자열 또는 일부 값이 남게 될 것입니다),
하지만 Windows의 cmd
나 PowerShell에서는 작동하지 않을 것입니다. 왜냐하면 이러한 셸들은 다른 변수 구문을 사용하기 때문입니다.
지원됨:
-
script
에서는 기본적으로 해당 셸에 사용 가능한 모든 변수를 사용할 수 있습니다(bash
또는sh
셸에는 모두 기본적으로 존재하는$PATH
와 같은 변수 및 프로젝트/그룹 변수,.gitlab-ci.yml
변수,config.toml
변수, 그리고 트리거 및 파이프라인 스케줄의 모든 변수 포함). -
script
에서 이전에 정의된 모든 변수를 사용할 수 있습니다. 예를 들어,export MY_VARIABLE="test"
와 같은 변수를 정의하면:-
before_script
에서는 관련script
의 이후 라인 및 관련script
의 모든 라인에서 작동합니다. -
script
에서는script
의 이후 라인에서 작동합니다. -
after_script
에서는after_script
내의 스크립트에서 정의된 변수만 사용할 수 있습니다.
-
after_script
스크립트의 경우:
- 동일한
after_script
섹션 내에서 스크립트 이전에 정의된 변수만 사용할 수 있습니다. -
before_script
및script
에서 정의된 변수를 사용할 수 없습니다.
이러한 제한은 after_script
스크립트가 분리된 셸 컨텍스트에서 실행되기 때문에 존재합니다.
지속 변수
일부 사전 정의된 변수는 “지속 변수”라고 합니다. 지속 변수는 다음과 같은 정의에서 지원됩니다 (“확장 위치”인 곳): - Runner. - 스크립트 실행 셸.
지원되지 않음: - “확장 위치”로서의 GitLab에서.
rules
변수 표현식에서 지속 변수를 사용할 수 없습니다.
파이프라인 트리거 작업은 작업 수준의 지속 변수를 사용할 수 없지만, 파이프라인 수준의 지속 변수를 사용할 수 있습니다.
일부 지속 변수에는 토큰이 포함되어 있어서 일부 정의에서는 사용할 수 없습니다.
파이프라인 수준의 지속 변수:
CI_PIPELINE_ID
CI_PIPELINE_URL
작업 수준의 지속 변수:
CI_DEPLOY_PASSWORD
CI_DEPLOY_USER
CI_JOB_ID
CI_JOB_STARTED_AT
CI_JOB_TOKEN
CI_JOB_URL
CI_REGISTRY_PASSWORD
CI_REGISTRY_USER
CI_REPOSITORY_URL
특정 통합에 대한 지속 변수:
-
Harbor:
HARBOR_URL
HARBOR_HOST
HARBOR_OCI
HARBOR_PROJECT
HARBOR_USERNAME
HARBOR_PASSWORD
-
Apple App Store Connect:
APP_STORE_CONNECT_API_KEY_ISSUER_ID
APP_STORE_CONNECT_API_KEY_KEY_ID
APP_STORE_CONNECT_API_KEY_KEY
APP_STORE_CONNECT_API_KEY_IS_KEY_CONTENT_BASE64
-
Google Play:
SUPPLY_PACKAGE_NAME
SUPPLY_JSON_KEY_DATA
-
Diffblue Cover:
DIFFBLUE_LICENSE_KEY
DIFFBLUE_ACCESS_TOKEN_NAME
DIFFBLUE_ACCESS_TOKEN
환경 범위로 정의된 변수:
환경 범위로 정의된 변수는 지원됩니다. 예를 들어, review/staging/*
범위에서 $STAGING_SECRET
변수가 정의된 경우, 동적 환경을 사용하는 다음 작업이 일치하는 변수 표현식에 기반하여 생성됩니다:
my-job:
stage: staging
environment:
name: review/$CI_JOB_STAGE/deploy
script:
- 'deploy staging'
rules:
- if: $STAGING_SECRET == 'something'