• 변수 사용법
  • .gitlab-ci.yml 파일
  • config.toml 파일
• 확장 메커니즘
  • GitLab 내부 변수 확장 메커니즘
    • 중첩 변수 확장
  • GitLab Runner 내부 변수 확장 메커니즘
  • 실행 쉘 환경
• 지속 변수
• 환경 범위를 갖는 변수

변수 사용 위치

CI/CD 변수 설명서에 설명된대로 여러 가지 다른 변수를 정의할 수 있습니다. 일부는 GitLab CI/CD의 모든 기능에 사용할 수 있지만, 일부는 덜하거나 더 제한될 수 있습니다.

변수 사용법

정의된 변수를 사용할 수 있는 두 곳이 있습니다. 바로:

1. GitLab 측인 .gitlab-ci.yml 파일.
2. GitLab Runner 측인 config.toml.

.gitlab-ci.yml 파일

• CI_ENVIRONMENT_SLUG를 제외한 CI_ENVIRONMENT_* 변수를 GitLab 16.4에서 도입되었습니다.

config.toml 파일

config.toml에 대해 더 알아보려면 GitLab Runner 문서를 참조하세요.

확장 메커니즘

세 가지 확장 메커니즘이 있습니다:

• GitLab
• GitLab Runner
• 실행 쉘 환경

GitLab 내부 변수 확장 메커니즘

확장된 부분은 $variable, ${variable} 또는 %variable% 형식이어야 합니다. 각 형식은 OS/셸에 관계없이 동일하게 처리되며, 실행 쉘이 작업을 처리하기 전에 GitLab에서 확장이 수행됩니다.

중첩 변수 확장

• GitLab 13.10에서 도입됨. 기본적으로 비활성화되어 있으며 variable_inside_variable 피처 플래그로 배포됨.
• GitLab 14.3에서 GitLab.com에서 활성화됨.
• GitLab 14.4에서 GitLab 셀프매니지(온프레미스)에서 활성화됨.
• GitLab 14.5에서 피처 플래그 variable_inside_variable가 제거됨.

GitLab은 작업 변수 값을 재귀적으로 확장하여 이를 Runner에 전송합니다. 예를 들어, 다음 시나리오에서:

- 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)에 따라 달라집니다. 예를 들어, 작업의 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 스크립트의 경우:

• 해당 섹션 내에서 정의된 변수만 사용할 수 있습니다.
• before_script 및 script에서 정의된 변수는 사용할 수 없습니다.

이러한 제한은 after_script 스크립트가 별도의 쉘 컨텍스트에서 실행되기 때문에 존재합니다.

지속 변수

일부 사전 정의된 변수는 “지속 변수(persisted)”라고 합니다. 지속 변수에는 다음이 포함됩니다:

• “확장 위치”이 “GitLab인 경우”와 같이 정의에 대해 지원됩니다:
  • Runner.
  • 스크립트 실행 쉘.
• 다음 사항은 지원되지 않습니다:
  • “확장 위치”이 GitLab인 경우와 같이 정의에 대해.
  • rules, only, except 변수 표현식에서.

파이프라인 트리거 작업은 작업 수준의 지속 변수를 사용할 수 없지만 파이프라인 수준의 지속 변수는 사용할 수 있습니다.

일부 지속 변수에는 토큰이 포함되어 있어 일부 정의에서는 사용할 수 없습니다.

파이프라인 수준의 지속 변수:

• 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

환경 범위를 갖는 변수

환경 범위로 정의된 변수는 지원됩니다. 변수 $STAGING_SECRET이 review/staging/* 범위에서 정의된 경우, 다음과 같은 동적 환경을 사용하는 작업이 해당 변수 표현식과 일치하는 기반으로 생성됩니다:

my-job:
  stage: staging
  environment:
    name: review/$CI_JOB_STAGE/deploy
  script:
    - 'deploy staging'
  rules:
    - if: $STAGING_SECRET == 'something'