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

변수 사용 위치

CI/CD 변수 문서에 설명된대로 다양한 변수를 정의할 수 있습니다. 일부 변수는 GitLab CI/CD의 모든 기능에 사용될 수 있지만, 일부는 좀 더 제한적입니다.

변수 사용법

정의된 변수는 두 곳에서 사용할 수 있습니다. 다음 위치에서:

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

.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은 실행 전에 작업 변수 값을 재귀적으로 확장합니다. 예를 들어, 다음 시나리오에서:

- 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'