InfoGrab Docs

작업 스크립트에서 CI/CD 변수 사용

요약

모든 CI/CD 변수는 작업 환경에서 환경 변수로 설정됩니다. 환경 변수에 접근하려면 러너 executor의 셸에 맞는 구문을 사용합니다. Bash, sh 및 유사한 셸에서 환경 변수에 접근하려면 CI/CD 변수 앞에 $를 붙입니다:

모든 CI/CD 변수는 작업 환경에서 환경 변수로 설정됩니다. 각 환경의 셸에 맞는 표준 형식으로 작업 스크립트에서 변수를 사용할 수 있습니다.

환경 변수에 접근하려면 러너 executor의 셸에 맞는 구문을 사용합니다.

Bash 및 sh 사용#

Bash, sh 및 유사한 셸에서 환경 변수에 접근하려면 CI/CD 변수 앞에 $를 붙입니다:

job_name:
  script:
    - echo "$CI_JOB_ID"

PowerShell 사용#

시스템에서 설정한 환경 변수를 포함하여 Windows PowerShell 환경에서 변수에 접근하려면 변수 이름 앞에 $env: 또는 $를 붙입니다:

job_name:
  script:
    - echo $env:CI_JOB_ID
    - echo $CI_JOB_ID
    - echo $env:PATH

Windows Batch 사용#

Windows Batch에서 CI/CD 변수에 접근하려면 변수를 %로 둘러쌉니다:

job_name:
  script:
    - echo %CI_JOB_ID%

지연 확장을 위해 변수를 !로 둘러쌀 수도 있습니다. 지연 확장은 공백이나 줄 바꿈을 포함하는 변수에 필요할 수 있습니다:

job_name:
  script:
    - echo !ERROR_MESSAGE!

서비스 컨테이너에서#

서비스 컨테이너는 CI/CD 변수를 사용할 수 있지만, 기본적으로 .gitlab-ci.yml 파일에 저장된 변수에만 접근할 수 있습니다. 서비스 컨테이너는 기본적으로 신뢰되지 않으므로 GitLab UI에서 추가된 변수는 서비스 컨테이너에서 사용할 수 없습니다.

UI에서 정의된 변수를 서비스 컨테이너에서 사용하려면 .gitlab-ci.yml에서 다른 변수에 재할당할 수 있습니다:

variables:
  SA_PASSWORD_YAML_FILE: $SA_PASSWORD_UI

재할당된 변수는 원래 변수와 같은 이름을 가질 수 없습니다. 그렇지 않으면 확장되지 않습니다.

파싱 오류 방지#

YAML 및 셸 파싱 오류를 방지하기 위해 스크립트 명령과 변수 값을 따옴표로 감쌉니다:

  • 콜론(:)을 포함하는 명령은 YAML이 이를 키-값 쌍으로 해석하지 못하도록 전체 명령을 따옴표로 감쌉니다:

    job_name:
      script:
        - 'echo "Status: Complete"'  # Single quotes prevent YAML colon parsing
    
  • 값에 공백이나 특수 문자가 포함될 수 있는 경우 변수를 따옴표로 감쌉니다:

    job_name:
      script:
        - echo "$FILE_PATH"          # Quote if FILE_PATH might have spaces
    
  • 변수를 별도의 셸 인수로 확장하려는 경우 따옴표를 사용하지 않습니다:

    job_name:
      variables:
        COMPILE_FLAGS: "-Wall -Werror -O2"
      script:
        - gcc $COMPILE_FLAGS main.c  # Expands to: gcc -Wall -Werror -O2 main.c
    

이후 작업에 환경 변수 전달#

dotenv 보고서를 사용하여 작업 스크립트에서 환경 변수를 정의하고 이후 스테이지의 다른 작업에 전달할 수 있습니다.

dotenv 보고서의 환경 변수는 파이프라인 구성이 아닌 작업 스크립트에서만 사용할 수 있습니다. 이 변수들은 .gitlab-ci.yml 파일에 정의된 작업 변수보다 우선순위를 갖습니다.

이후 작업에 dotenv 변수를 전달하려면:

  1. 작업 스크립트에서 변수를 VARIABLE_NAME=value 형식으로 .env 파일에 저장합니다. 예를 들어:

       build-job:
         stage: build
         script:
           - echo "BUILD_VARIABLE=value_from_build_job" >> build.env
         artifacts:
           reports:
             dotenv: build.env
    
  2. 이후 스테이지 작업에서 스크립트에 변수를 사용합니다. 예를 들어:

    test-job:
      stage: test
      script:
        - echo "$BUILD_VARIABLE"  # Output is: 'value_from_build_job'
    

다운스트림 파이프라인에 dotenv 변수를 전달할 수도 있습니다.

dotenv 변수를 받는 작업 제어#

dependencies 또는 needs 키워드를 사용하여 dotenv 아티팩트를 받는 작업을 제어할 수 있습니다.

dotenv 아티팩트의 환경 변수를 받지 않으려면:

  • dependencies 또는 needs 배열을 전달합니다.
  • needs:artifactsfalse로 전달합니다.
  • dotenv 아티팩트가 없는 작업만 나열하도록 needs를 설정합니다.

예를 들어:

build-job1:
  stage: build
  script:
    - echo "BUILD_VERSION=v1.0.0" >> build.env
  artifacts:
    reports:
      dotenv: build.env

build-job2:
  stage: build
  needs: []
  script:
    - echo "This job has no dotenv artifacts"

test-job1:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  dependencies:
    - build-job1

test-job2:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  dependencies: []

test-job3:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  needs:
    - build-job1

test-job4:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  needs:
    - job: build-job1
      artifacts: true

test-job5:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  needs:
    - job: build-job1
      artifacts: false

test-job6:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  needs:
    - build-job2

script 섹션에서 artifacts 또는 cache로 환경 변수 전달#

히스토리
  • GitLab 16.4에서 도입되었습니다.

$GITLAB_ENV를 사용하여 script 섹션에서 정의된 환경 변수를 artifacts 또는 cache 키워드에서 사용합니다. 예를 들어:

build-job:
  stage: build
  script:
    - echo "ARCH=$(arch)" >> $GITLAB_ENV
    - touch some-file-$(arch)
  artifacts:
    paths:
      - some-file-$ARCH

하나의 변수에 여러 값 저장#

값 배열인 CI/CD 변수를 만들 수는 없지만, 유사한 동작을 위해 셸 스크립팅 기법을 사용할 수 있습니다.

예를 들어, 변수에 공백으로 구분된 여러 값을 저장한 다음 스크립트로 값을 반복할 수 있습니다:

job1:
  variables:
    FOLDERS: src test docs
  script:
    - |
      for FOLDER in $FOLDERS
        do
          echo "The path is root/${FOLDER}"
        done

다른 변수에서 CI/CD 변수 사용#

변수 내에서 변수를 사용할 수 있습니다:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'

문자열의 일부로#

변수를 문자열의 일부로 사용할 수 있습니다. 변수 이름을 주변 텍스트와 구분하는 데 도움이 되도록 변수를 중괄호({})로 둘러쌀 수 있습니다. 중괄호 없이는 인접한 텍스트가 변수 이름의 일부로 해석됩니다. 예를 들어:

job:
  variables:
    FLAGS: '-al'
    DIR: 'path/to/directory'
    LS_CMD: 'ls "$FLAGS"'
    CD_CMD: 'cd "${DIR}_files"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'
    - 'eval "$CD_CMD"'  # Executes 'cd path/to/directory_files'

CI/CD 변수에서 $ 문자 사용#

$ 문자를 다른 변수의 시작으로 해석하지 않으려면 대신 $$를 사용합니다:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al $TMP_DIR'

이것은 CI/CD 변수를 다운스트림 파이프라인에 전달할 때는 작동하지 않습니다.

작업 스크립트에서 CI/CD 변수 사용

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

모든 CI/CD 변수는 작업 환경에서 환경 변수로 설정됩니다. 환경 변수에 접근하려면 러너 executor의 셸에 맞는 구문을 사용합니다. Bash, sh 및 유사한 셸에서 환경 변수에 접근하려면 CI/CD 변수 앞에 $를 붙입니다:

모든 CI/CD 변수는 작업 환경에서 환경 변수로 설정됩니다. 각 환경의 셸에 맞는 표준 형식으로 작업 스크립트에서 변수를 사용할 수 있습니다.

환경 변수에 접근하려면 러너 executor의 셸에 맞는 구문을 사용합니다.

Bash 및 sh 사용#

Bash, sh 및 유사한 셸에서 환경 변수에 접근하려면 CI/CD 변수 앞에 $를 붙입니다:

job_name:
  script:
    - echo "$CI_JOB_ID"

PowerShell 사용#

시스템에서 설정한 환경 변수를 포함하여 Windows PowerShell 환경에서 변수에 접근하려면 변수 이름 앞에 $env: 또는 $를 붙입니다:

job_name:
  script:
    - echo $env:CI_JOB_ID
    - echo $CI_JOB_ID
    - echo $env:PATH

Windows Batch 사용#

Windows Batch에서 CI/CD 변수에 접근하려면 변수를 %로 둘러쌉니다:

job_name:
  script:
    - echo %CI_JOB_ID%

지연 확장을 위해 변수를 !로 둘러쌀 수도 있습니다. 지연 확장은 공백이나 줄 바꿈을 포함하는 변수에 필요할 수 있습니다:

job_name:
  script:
    - echo !ERROR_MESSAGE!

서비스 컨테이너에서#

서비스 컨테이너는 CI/CD 변수를 사용할 수 있지만, 기본적으로 .gitlab-ci.yml 파일에 저장된 변수에만 접근할 수 있습니다. 서비스 컨테이너는 기본적으로 신뢰되지 않으므로 GitLab UI에서 추가된 변수는 서비스 컨테이너에서 사용할 수 없습니다.

UI에서 정의된 변수를 서비스 컨테이너에서 사용하려면 .gitlab-ci.yml에서 다른 변수에 재할당할 수 있습니다:

variables:
  SA_PASSWORD_YAML_FILE: $SA_PASSWORD_UI

재할당된 변수는 원래 변수와 같은 이름을 가질 수 없습니다. 그렇지 않으면 확장되지 않습니다.

파싱 오류 방지#

YAML 및 셸 파싱 오류를 방지하기 위해 스크립트 명령과 변수 값을 따옴표로 감쌉니다:

  • 콜론(:)을 포함하는 명령은 YAML이 이를 키-값 쌍으로 해석하지 못하도록 전체 명령을 따옴표로 감쌉니다:

    job_name:
      script:
        - 'echo "Status: Complete"'  # Single quotes prevent YAML colon parsing
    
  • 값에 공백이나 특수 문자가 포함될 수 있는 경우 변수를 따옴표로 감쌉니다:

    job_name:
      script:
        - echo "$FILE_PATH"          # Quote if FILE_PATH might have spaces
    
  • 변수를 별도의 셸 인수로 확장하려는 경우 따옴표를 사용하지 않습니다:

    job_name:
      variables:
        COMPILE_FLAGS: "-Wall -Werror -O2"
      script:
        - gcc $COMPILE_FLAGS main.c  # Expands to: gcc -Wall -Werror -O2 main.c
    

이후 작업에 환경 변수 전달#

dotenv 보고서를 사용하여 작업 스크립트에서 환경 변수를 정의하고 이후 스테이지의 다른 작업에 전달할 수 있습니다.

dotenv 보고서의 환경 변수는 파이프라인 구성이 아닌 작업 스크립트에서만 사용할 수 있습니다. 이 변수들은 .gitlab-ci.yml 파일에 정의된 작업 변수보다 우선순위를 갖습니다.

이후 작업에 dotenv 변수를 전달하려면:

  1. 작업 스크립트에서 변수를 VARIABLE_NAME=value 형식으로 .env 파일에 저장합니다. 예를 들어:

       build-job:
         stage: build
         script:
           - echo "BUILD_VARIABLE=value_from_build_job" >> build.env
         artifacts:
           reports:
             dotenv: build.env
    
  2. 이후 스테이지 작업에서 스크립트에 변수를 사용합니다. 예를 들어:

    test-job:
      stage: test
      script:
        - echo "$BUILD_VARIABLE"  # Output is: 'value_from_build_job'
    

다운스트림 파이프라인에 dotenv 변수를 전달할 수도 있습니다.

dotenv 변수를 받는 작업 제어#

dependencies 또는 needs 키워드를 사용하여 dotenv 아티팩트를 받는 작업을 제어할 수 있습니다.

dotenv 아티팩트의 환경 변수를 받지 않으려면:

  • dependencies 또는 needs 배열을 전달합니다.
  • needs:artifactsfalse로 전달합니다.
  • dotenv 아티팩트가 없는 작업만 나열하도록 needs를 설정합니다.

예를 들어:

build-job1:
  stage: build
  script:
    - echo "BUILD_VERSION=v1.0.0" >> build.env
  artifacts:
    reports:
      dotenv: build.env

build-job2:
  stage: build
  needs: []
  script:
    - echo "This job has no dotenv artifacts"

test-job1:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  dependencies:
    - build-job1

test-job2:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  dependencies: []

test-job3:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  needs:
    - build-job1

test-job4:
  stage: test
  script:
    - echo "$BUILD_VERSION"  # Output is: 'v1.0.0'
  needs:
    - job: build-job1
      artifacts: true

test-job5:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  needs:
    - job: build-job1
      artifacts: false

test-job6:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is ''
  needs:
    - build-job2

script 섹션에서 artifacts 또는 cache로 환경 변수 전달#

히스토리
  • GitLab 16.4에서 도입되었습니다.

$GITLAB_ENV를 사용하여 script 섹션에서 정의된 환경 변수를 artifacts 또는 cache 키워드에서 사용합니다. 예를 들어:

build-job:
  stage: build
  script:
    - echo "ARCH=$(arch)" >> $GITLAB_ENV
    - touch some-file-$(arch)
  artifacts:
    paths:
      - some-file-$ARCH

하나의 변수에 여러 값 저장#

값 배열인 CI/CD 변수를 만들 수는 없지만, 유사한 동작을 위해 셸 스크립팅 기법을 사용할 수 있습니다.

예를 들어, 변수에 공백으로 구분된 여러 값을 저장한 다음 스크립트로 값을 반복할 수 있습니다:

job1:
  variables:
    FOLDERS: src test docs
  script:
    - |
      for FOLDER in $FOLDERS
        do
          echo "The path is root/${FOLDER}"
        done

다른 변수에서 CI/CD 변수 사용#

변수 내에서 변수를 사용할 수 있습니다:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'

문자열의 일부로#

변수를 문자열의 일부로 사용할 수 있습니다. 변수 이름을 주변 텍스트와 구분하는 데 도움이 되도록 변수를 중괄호({})로 둘러쌀 수 있습니다. 중괄호 없이는 인접한 텍스트가 변수 이름의 일부로 해석됩니다. 예를 들어:

job:
  variables:
    FLAGS: '-al'
    DIR: 'path/to/directory'
    LS_CMD: 'ls "$FLAGS"'
    CD_CMD: 'cd "${DIR}_files"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'
    - 'eval "$CD_CMD"'  # Executes 'cd path/to/directory_files'

CI/CD 변수에서 $ 문자 사용#

$ 문자를 다른 변수의 시작으로 해석하지 않으려면 대신 $$를 사용합니다:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al $TMP_DIR'

이것은 CI/CD 변수를 다운스트림 파이프라인에 전달할 때는 작동하지 않습니다.