스크립트 및 작업 로그

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

특별한 구문을 사용하여 script 섹션에서 다음을 할 수 있습니다.

script에서 특수 문자 사용

가끔 script 명령은 단일 또는 이중 인용부호로 묶여야 합니다. 예를 들어, 콜론(:)을 포함하는 명령은 단일 인용부호(')로 묶어져야 합니다. YAML 파서는 텍스트를 “키: 값” 쌍이 아닌 문자열로 해석해아 합니다.

예를 들어, 다음 스크립트는 콜론을 사용합니다: 

job:
  script:
    - curl --request POST --header 'Content-Type: application/json' "https://gitlab/api/v4/projects"

유효한 YAML로 간주되려면 전체 명령을 단일 인용부호로 묶어야 합니다. 명령에 이미 단일 인용부호가 사용되었으면 가능하다면 이를 이중 인용부호(")로 변경해야 합니다: 

job:
  script:
    - 'curl --request POST --header "Content-Type: application/json" "https://gitlab/api/v4/projects"'

구문이 유효한지 확인하려면 CI Lint 도구를 사용할 수 있습니다.

또한 다음과 같이 주의해야 할 특수 문자들이 있습니다:

  • {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, `.

0 이 아닌 종료 코드 무시하기

스크립트 명령은 0이 아닌 종료 코드를 반환할 때 해당 작업이 실패하고 추가 명령이 실행되지 않습니다.

이 동작을 피하기 위해 종료 코드를 변수에 저장할 수 있습니다: 

job:
  script:
    - false || exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "이전 명령이 실패했습니다"; fi;

모든 작업에 대한 기본 before_script 또는 after_script 설정하기

default와 함께 before_script 및 after_script를 사용할 수 있습니다:

  • before_script에 default를 사용하여 모든 작업의 script 명령보다 먼저 실행하여야 하는 기본 명령 배열을 정의합니다.
  • after_script에 default를 사용하여 작업이 완료되거나 취소된 후 실행하여야 하는 기본 명령 배열을 정의합니다.

작업에서 다른 값을 정의하여 기본값을 무시할 수 있습니다. 기본값을 무시하려면 before_script: [] 또는 after_script: []를 사용하세요: 

default:
  before_script:
    - echo "기본적으로 모든 작업에서 이 `before_script`를 실행합니다."
  after_script:
    - echo "기본적으로 모든 작업 후에 이 `after_script`를 실행합니다."

job1:
  script:
    - echo "이 스크립트 명령은 기본 `before_script` 이후,"
    - echo "기본 `after_script` 이전에 실행됩니다."

job2:
  before_script:
    - echo "기본 `before_script` 대신 이 스크립트를 실행합니다."
  script:
    - echo "이 스크립트는 작업의 `before_script` 이후에 실행되지만,"
    - echo "작업은 기본 `after_script`를 사용하지 않습니다."
  after_script: []

작업 취소 시 after_script 실행

Offering: GitLab.com, Self-Managed
이 기능의 사용 가능 여부는 피처 플래그로 제어됩니다. 자세한 정보는 이력 참조하십시오.

after_script 명령은 작업이 running 상태일 때 작업이 취소될 때 실행됩니다. 이는 GitLab Runner 버전이 16.9 이상이며 ci_canceling_status 플래그가 활성화되어 있는 경우에 해당됩니다.

UI에 표시되는 작업 상태는 after_script 명령이 처리되는 동안 canceling이고, after_script 명령이 완료되면 canceled로 전환됩니다. after_script 명령이 처리되는 동안 $CI_JOB_STATUS 미리 정의된 변수는 canceled 값을 가집니다.

추가 정보:

  • 작업을 취소한 후에 after_script 명령이 실행되지 않도록 하려면, after_script에서 $CI_JOB_STATUS 미리 정의된 변수를 확인하고 값에 따라 실행을 일찍 종료하세요, 예를 들어: 

    - if [ "$CI_JOB_STATUS" == "canceled" ]; then exit 0; fi
  • 이 기능을 지원하려면 GitLab Runner 16.11.1 이상을 권장합니다:
    • GitLab Runner 16.11.1 패치 릴리스에서 $CI_JOB_STATUS에 canceled가 지원되었습니다. 패치 릴리스 이전에는 상태가 canceling되는 동안 failed가 될 것입니다.
    • GitLab Runner 16.11.1 패치 릴리스 이전에 버그로 인해 after_script 작업이 이른 종료될 수 있습니다.
  • GitLab.com의 공유 러너의 경우, 패치 버전 16.11.1 이상에서 $CI_JOB_STATUS는 canceled`로 바뀔 것입니다.
  • Self-Managed의 경우, ci_canceling_status 플래그가 17.0에서 기본적으로 활성화되며, 관리자가 이전 동작으로 되돌아가도록 해야 하는 경우 비활성화할 수 있습니다. 이 플래그는 다음 마일스톤에서 제거될 수 있으며 장기적으로 의존해서는 안 됩니다.

긴 명령 분할하기

| (리터럴) 및 > (접힌) YAML 여러 줄 블록 스칼라 표시기를 사용하여 긴 명령을 여러 줄 명령으로 분할할 수 있습니다.

caution
여러 명령이 하나의 명령 문자열로 결합되면 마지막 명령의 성공 또는 실패만이 보고됩니다. 이전 명령에서 오류가 무시되므로 문제가 있습니다. 이를 해결하려면 각 명령을 개별 script 항목으로 실행하거나 각 명령 문자열에 exit 1 명령을 추가하세요.

| (리터럴) YAML 여러 줄 블록 스칼라 표시기를 사용하여 script 섹션에서 여러 줄로 명령을 작성할 수 있습니다. 각 행은 별도의 명령으로 처리됩니다. 첫 번째 명령만 작업 로그에 표시되지만 추가 명령은 여전히 실행됩니다: 

job:
  script:
    - |
      echo "첫 번째 명령행."
      echo "두 번째 명령행."
      echo "세 번째 명령행."

위 예제는 작업 로그에 다음과 같이 표시됩니다: 

$ echo First command line # collapsed multiline command
First command line
Second command line.
Third command line.

> (접힌) YAML 여러 줄 블록 스칼라 표시기는 섹션 사이의 빈 줄을 새 명령의 시작으로 취급합니다: 

job:
  script:
    - >
      echo "첫 번째 명령행
      두 줄로 나뉩니다."
      
      echo "두 번째 명령행."

이는 > 또는 | 블록 스칼라 표시기 없는 여러 줄 명령과 유사하게 작동합니다: 

job:
  script:
    - echo "첫 번째 명령행
      두 줄로 나뉩니다."
      
      echo "두 번째 명령행."

위의 두 예제는 작업 로그에 다음과 같이 표시됩니다: 

$ echo First command line is split over two lines. # collapsed multiline command
First command line is split over two lines.
Second command line.

> 또는 | 블록 스칼라 표시기를 생략하면 GitLab은 비어 있지 않은 줄을 연결하여 명령을 형성합니다. 줄이 연결될 수 있는지 확인하세요.

스크립트 출력물에 색상 코드 추가하기

스크립트 출력물은 ANSI 이스케이프 코드를 사용하거나 ANSI 이스케이프 코드를 출력하는 명령 또는 프로그램을 실행하여 색상을 입힐 수 있습니다.

예를 들어, Bash와 색상 코드를 사용한 경우: 

job:
  script:
    - echo -e "\e[31m이 텍스트는 빨간색입니다,\e[0m 하지만 이 텍스트는 아닙니다\e[31m 그러나 이 텍스트는 다시 빨간색입니다."

Shell 환경 변수 또는 CI/CD 변수에 색상 코드를 정의할 수 있어 더 쉽게 읽고 재사용할 수 있습니다.

위의 예와 동일한 예를 사용하면서 before_script에서 환경 변수를 정의한 경우: 

job:
  before_script:
    - TXT_RED="\e[31m" && TXT_CLEAR="\e[0m"
  script:
    - echo -e "${TXT_RED}이 텍스트는 빨간색입니다,${TXT_CLEAR} 하지만 이 부분은 아닙니다${TXT_RED} 그러나 이 부분은 다시 빨간색입니다."
    - echo "이 텍스트는 색이 입혀지지 않았습니다."

또는 PowerShell 색상 코드를 사용하는 경우: 

job:
  before_script:
    - $esc="$([char]27)"; $TXT_RED="$esc[31m"; $TXT_CLEAR="$esc[0m"
  script:
    - Write-Host $TXT_RED"이 텍스트는 빨간색입니다,"$TXT_CLEAR" 하지만 이 텍스트는 아닙니다"$TXT_RED" 그러나 이 텍스트는 다시 빨간색입니다."
    - Write-Host "이 텍스트는 색이 입혀지지 않았습니다."

문제 해결

:을 사용하는 스크립트에서 구문이 잘못되었습니다 오류

스크립트에서 콜론(:)을 사용하면 GitLab이 다음과 같이 출력할 수 있습니다:

  • 구문이 잘못되었습니다
  • 스크립트 구성은 문자열이거나 문자열이 중첩된 배열이어야 합니다. 최대로 10단계를 지원합니다

예를 들어, cURL 명령어의 일부로 "PRIVATE-TOKEN: ${PRIVATE_TOKEN}"를 사용하는 경우: 

pages-job:
  stage: deploy
  script:
    - curl --header 'PRIVATE-TOKEN: ${PRIVATE_TOKEN}' "https://gitlab.example.com/api/v4/projects"
  environment: production

YAML 파서는 :을 YAML 키워드로 정의한다고 생각하고 구문이 잘못되었습니다 오류를 출력합니다.

콜론을 포함하는 명령을 사용하려면 전체 명령을 단일 인용부호로 감싸야 합니다. 기존 단일 인용부호(')를 이중 인용부호(")로 변경해야 할 수도 있습니다. 

pages-job:
  stage: deploy
  script:
    - 'curl --header "PRIVATE-TOKEN: ${PRIVATE_TOKEN}" "https://gitlab.example.com/api/v4/projects"'
  environment: production

스크립트에서 &&을 사용할 때 작업이 실패하지 않음

단일 스크립트 라인에 두 개의 명령을 결합하는 데 &&을 사용하는 경우, 하나의 명령이 실패하더라도 작업이 성공적으로 완료될 수 있습니다. 예를 들어: 

job-does-not-fail:
  script:
    - invalid-command xyz && invalid-command abc
    - echo $?
    - echo "작업은 이미 실패해야 하지만 이것은 예기치 않게 실행됩니다."

&& 연산자는 두 명령이 실패해도 종료 코드 0을 반환하고 작업이 계속 실행되므로 전체 라인을 괄호로 둘러싸서 명령어가 실패할 때 스크립트가 종료되도록 해야 합니다. 

job-fails:
  script:
    - (invalid-command xyz && invalid-command abc)
    - echo "작업은 이미 실패했고, 이 부분은 실행되지 않습니다."

접힌 YAML 다중 블록 스칼라로 여러 줄 명령이 보존되지 않음

긴 명령을 분할하기 위해 - >로 접힌 YAML 다중 블록 스칼라를 사용하는 경우, 추가 들여쓰기로 인해 각 줄이 개별 명령으로 처리될 수 있습니다.

예를 들어: 

script:
  - >
    RESULT=$(curl --silent
      --header
        "Authorization: Bearer $CI_JOB_TOKEN"
      "${CI_API_V4_URL}/job"
    )

들여쓰기로 인해 줄 바꿈이 보존되어 오류가 발생합니다. 

$ RESULT=$(curl --silent # 접힌 다중 라인 명령
curl: no URL specified!
curl: try 'curl --help' or 'curl --manual' for more information
/bin/bash: line 149: --header: command not found
/bin/bash: line 150: https://gitlab.example.com/api/v4/job: No such file or directory

이를 해결하려면 다음 중 하나를 수행합니다:

  • 추가 들여쓰기를 제거합니다: 

    script:
  - >
    RESULT=$(curl --silent
    --header
    "Authorization: Bearer $CI_JOB_TOKEN"
    "${CI_API_V4_URL}/job"
    )

  • 추가 줄바꿈이 처리되도록 스크립트를 수정합니다. 예를 들어 쉘 라인 이어짐을 사용합니다: 

    script:
  - >
    RESULT=$(curl --silent \
      --header \
        "Authorization: Bearer $CI_JOB_TOKEN" \
      "${CI_API_V4_URL}/job")

작업 로그 출력이 예상과 다르게 형식이 되거나 예상치 못한 문자가 포함됨

가끔 TERM 환경 변수에 의존하는 도구로 인해 작업 로그의 형식이 올바르게 표시되지 않을 수 있습니다. 예를 들어, mypy 명령어와 함께:

예시 출력

GitLab Runner는 컨테이너 쉘을 대화형 모드가 아닌 모드로 실행하므로 쉘의 TERM 환경 변수가 dumb로 설정됩니다. 이러한 도구의 형식을 수정하려면 다음을 수행할 수 있습니다:

  • 명령을 실행하기 전에 쉘 환경에서 TERM=ansi를 설정하는 추가 스크립트 라인을 추가합니다.
  • ansi 값으로 TERM CI/CD 변수를 추가합니다.