• 변수 사용
  • .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_* 변수를 지원합니다. 단, CI_ENVIRONMENT_SLUG는 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'

실행자는 유효하고 완전하게 형성된 경로를 받습니다. 예를 들어, ${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에서 중첩 변수 확장이 활성화되어 있는지 여부에 따라 달라질 수 있습니다.

실행 셸 환경

이는 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 스크립트가 별도 셸 컨텍스트에서 실행되기 때문에 존재합니다.

지속 변수

일부 미리 정의된 변수는 “지속 변수”라고 합니다. 지속 변수는 다음과 같습니다:

• 다음이 “확장 위치”로 지원됩니다 물리적으로 찾아보세요:
  • 러너.
  • 스크립트 실행 셸.
• 지원되지 않음:
  • “확장 위치”가 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

환경 범위가 있는 변수

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

my-job:
  stage: staging
  environment:
    name: review/$CI_JOB_STAGE/deploy
  script:
    - '배포 스테이징'
  rules:
    - if: $STAGING_SECRET == 'something'