• 변수 사용 방법
  • .gitlab-ci.yml 파일
  • config.toml 파일
• 확장 메커니즘
  • GitLab 내부 변수 확장 메커니즘
    • 중첩 변수 확장
  • GitLab Runner 내부 변수 확장 메커니즘
  • 실행 쉘 환경
• 보존된 변수
• 환경 범위를 가진 변수

변수를 사용할 수 있는 곳

CI/CD variables 문서에 설명된대로 다양한 변수를 정의할 수 있습니다. 일부 변수는 GitLab CI/CD의 모든 기능에 사용될 수 있지만, 일부는 더 나은 한도가 있는 경우도 있습니다.

변수 사용 방법

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

1. GitLab 측, .gitlab-ci.yml 파일에서
2. GitLab Runner 측, config.toml에서

.gitlab-ci.yml 파일

• GitLab 16.4에서 소개된 CI_ENVIRONMENT_SLUG를 제외한 CI_ENVIRONMENT_* 변수를 지원합니다.

config.toml 파일

config.toml에 대해 더 읽어보려면 GitLab Runner 문서를 확인하세요.

확장 메커니즘

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

• GitLab
• GitLab Runner
• 실행 쉘 환경

GitLab 내부 변수 확장 메커니즘

확장된 부분은 $variable, 또는 ${variable}, 또는 %variable% 형식이어야 합니다. 각 형식은 어떤 OS/쉘이 작업을 처리하든 상관없이 처리되며, 이는 확장이 Runner가 작업을 받기 전에 GitLab에서 수행되기 때문입니다.

중첩 변수 확장

• GitLab 13.10에 도입되었습니다. 기본적으로 비활성화된 variable_inside_variable 기능 플래그에 의해 배포되었습니다.
• GitLab 14.3에서 GitLab.com에 활성화되었습니다.
• GitLab 14.4에서 자체 호스팅 환경에서도 활성화되었습니다.
• 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). 예를 들어, job의 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에서는 관련 script의 이후 줄 및 모든 before_script의 줄에서 작동합니다.
  • script에서는 script의 이후 줄에서 작동합니다.
  • after_script에서는 after_script의 이후 줄에서 작동합니다.

after_script 스크립트의 경우:

• 같은 after_script 섹션 내에서 스크립트 이전에 정의된 변수만 사용할 수 있습니다.
• before_script 및 script에서 정의된 변수는 사용할 수 없습니다.

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

보존된 변수

일부 사전 정의된 변수를 “보존된”이라고 합니다. 보존된 변수는 다음과 같습니다:

• 다음을 사용할 수 있는 정의에 대한 “확장 위치”:
  • 러너.
  • 스크립트 실행 셸.
• 다음을 사용할 수 없음:
  • “확장 위치”가 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
• 애플 앱 스토어 연동:
  • 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'