스크립트 및 작업 로그 형식
Offering: GitLab.com, Self-managed, GitLab Dedicated
script
섹션에서 특별한 구문을 사용하여 다음을 수행할 수 있습니다.
- 긴 명령을 여러 줄로 나눕니다. (#split-long-commands)
- 작업 로그를 쉽게 검토할 수 있도록 색 코드를 사용합니다. (#add-color-codes-to-script-output)
- 사용자 정의 접을 수 있는 섹션을 만들어 작업 로그 출력을 단순화합니다.
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이 아닌 종료 코드를 반환하면 작업이 실패하고 추가적인 명령이 실행되지 않습니다.
이 동작을 피하려면 종료 코드를 변수에 저장하세요.
job:
script:
- false || exit_code=$?
- if [ $exit_code -ne 0 ]; then echo "이전 명령이 실패했습니다"; fi;
모든 작업에 대한 기본 before_script
또는 after_script
설정하기
before_script
및 after_script
을 default
와 함께 사용할 수 있습니다.
-
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: []
긴 명령 나누기
|
(literal) 및 >
(folded) YAML 다중 블록 스칼라 표시를 사용하여 긴 명령을 여러 줄로 나눌 수 있습니다.
script
항목으로 실행하거나 각 명령 문자열에 exit 1
명령을 추가하세요.|
(literal) YAML 다중 블록 스칼라 표시를 사용하여 작업 설명의 script
섹션에서 여러 줄로 명령을 작성할 수 있습니다.
각 줄은 별도의 명령으로 취급됩니다.
첫 번째 명령만 작업 로그에 반복되지만 추가 명령은 여전히 실행됩니다.
job:
script:
- |
echo "첫 번째 명령 행."
echo "두 번째 명령 행."
echo "세 번째 명령 행."
위 예제는 작업 로그에 다음과 같이 표시됩니다.
$ echo 첫 번째 명령 행 # 펼쳐진 여러 줄 명령
첫 번째 명령 행
두 번째 명령 행
세 번째 명령 행.
>
(folded) YAML 다중 블록 스칼라 표시는 섹션 사이의 빈 줄을 새 명령의 시작으로 취급합니다.
job:
script:
- >
echo "첫 번째 명령 행
두 줄로 분할됩니다."
echo "두 번째 명령 행."
이는 >
또는 |
블록 스칼라 표시 없는 다중 줄 명령과 유사하게 동작합니다.
job:
script:
- echo "첫 번째 명령 행
두 줄로 분할됩니다."
echo "두 번째 명령 행."
위의 예제는 모두 작업 로그에 다음과 같이 표시됩니다.
$ echo "첫 번째 명령 행 두 줄로 분할됩니다." # 펼쳐진 여러 줄 명령
첫 번째 명령 행 두 줄로 분할됩니다.
두 번째 명령 행.
>
또는 |
블록 스칼라 표시를 생략하면 GitLab은 비어 있지 않은 줄을 연결하여 명령을 형성합니다.
줄을 연결했을 때 명령을 실행할 수 있는지 확인하세요.
Shell here documents는 |
및 >
연산자와 함께 작동합니다. 아래 예제는 소문자를 대문자로 변환합니다.
job:
script:
- |
tr a-z A-Z << END_TEXT
one two three
four five six
END_TEXT
다음과 같이 실행됩니다.
$ tr a-z A-Z << END_TEXT # 펼쳐진 여러 줄 명령
ONE TWO THREE
FOUR FIVE SIX
스크립트 출력에 색 코드 추가하기
스크립트 출력은 ANSI 이스케이프 코드를 사용하여 색을 입힐 수도 있고, ANSI 이스케이프 코드를 출력하는 명령이나 프로그램을 실행하여 색을 입힐 수도 있습니다.
예를 들어, Bash 색 코드 사용:
job:
script:
- echo -e "\e[31m이 텍스트는 빨간색입니다,\e[0m 하지만 이 텍스트는 아닙니다\e[31m 그러나 이 텍스트는 다시 빨간색입니다."
이 샘플은 환경 변수를 정의한 before_script
에서 색 코드를 정의할 수도 있습니다.
job:
before_script:
- TXT_RED="\e[31m" && TXT_CLEAR="\e[0m"
script:
- echo -e "${TXT_RED}이 텍스트는 빨간색입니다,${TXT_CLEAR} 하지만 이 부분은 아닙니다${TXT_RED} 그러나 이 부분은 다시 빨간색입니다."
- echo "이 텍스트는 색이 입혀지지 않았습니다."
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 "이 텍스트는 색이 입혀지지 않았습니다"
Troubleshooting
스크립트에서 :
를 사용하면 구문이 잘못되었다(Syntax is incorrect)
라는 오류가 발생합니다.
스크립트에서 콜론(:
)을 사용하는 경우 GitLab은 다음과 같은 결과를 출력할 수 있습니다:
구문이 잘못되었습니다(Syntax is incorrect)
스크립트 구성은 문자열이거나 10단계까지 중첩된 문자열 배열이어야 합니다(script config should be a string or a nested array of strings up to 10 levels deep)
예를 들어, 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 키워드로 인식하고 구문이 잘못되었습니다(Syntax is incorrect)
오류를 출력합니다.
콜론을 포함하는 명령어를 사용하려면 전체 명령어를 단일 인용부호로 감싸야 합니다. 기존의 단일 인용부호('
)를 이중 인용부호("
)로 변경해야 할 수도 있습니다:
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
를 설정하는 추가 스크립트 라인을 추가합니다. -
TERM
CI/CD 변수에ansi
값을 추가합니다.