작업

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

작업은 GitLab CI/CD 파이프라인의 기본 요소입니다. 작업은 .gitlab-ci.yml 파일에 구성되어 빌드, 테스트 또는 코드 배포와 같은 작업을 수행하는 명령어 디렉터리으로 설정됩니다.

작업은:

  • 실행 조건을 명시하는 제약 조건으로 정의됩니다.
  • 임의의 이름을 가진 최상위 요소이며 적어도 script 절을 포함해야 합니다.
  • 정의할 수 있는 개수에 제한이 없습니다.

예를 들어: 

job1:
  script: "job1을 위한 명령어 실행"

job2:
  script: "job2를 위한 명령어 실행"

위의 예는 두 개의 별개의 작업을 실행하는 가장 간단한 CI/CD 구성이며, 각 작업은 다른 명령어를 실행합니다. 물론 명령어는 직접 코드를 실행(./configure;make;make install)하거나 리포지터리 내의 스크립트(test.sh)를 실행할 수 있습니다.

작업은 러너(runner)에 의해 수집되어 러너의 환경에서 실행됩니다. 중요한 점은 각 작업이 서로 독립적으로 실행된다는 것입니다.

파이프라인에서 작업 보기

파이프라인에 액세스하면 해당 파이프라인에 대한 관련 작업을 볼 수 있습니다.

개별 작업을 선택하면 해당 작업 로그가 표시되며 다음과 같은 작업을 수행할 수 있습니다:

  • 작업 취소
  • 작업 다시 시도(실패한 경우)
  • 작업 다시 실행(통과한 경우)
  • 작업 로그 지우기

프로젝트에서 모든 작업 보기

프로젝트에서 실행된 전체 작업 디렉터리을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 빌드 > 작업을 선택합니다.

작업 상태별로 디렉터리을 필터링할 수 있습니다.

작업 실패 이유 확인

파이프라인이 실패하거나 실패해도 되도록 허용된 경우, 이유를 찾을 수 있는 여러 곳이 있습니다:

  • 파이프라인 그래프인 파이프라인 세부 정보 뷰에서
  • 파이프라인 위젯인 Merge Request 및 커밋 페이지에서
  • 작업 뷰인 작업의 전역 및 상세 뷰에서

각 위치에서 실패한 작업 위에 마우스를 올리면 실패한 이유가 표시됩니다.

파이프라인 세부 정보

또한 작업 세부 정보 페이지에서 실패한 이유를 확인할 수 있습니다.

파이프라인에서의 작업 순서

파이프라인의 작업 순서는 파이프라인 그래프 유형에 따라 다릅니다.

작업 상태 순서는 다음과 같습니다:

  • 실패
  • 경고
  • 대기 중
  • 실행 중
  • 매뉴얼
  • 예약됨
  • 취소됨
  • 성공
  • 건너뜀
  • 생성됨

예를 들어:

미니 파이프라인 그래프 정렬

작업 이름 제한

다음 키워드를 작업 이름으로 사용할 수 없습니다:

  • image
  • services
  • stages
  • types
  • before_script
  • after_script
  • variables
  • cache
  • include
  • true
  • false
  • nil
  • pages:deploy가 deploy 단계로 구성된 경우

작업 이름은 255자 이하여하여 합니다.

작업에 고유한 이름을 사용하세요. 파일에서 여러 작업이 동일한 이름을 가지는 경우 파이프라인에 하나만 추가되며 어떤 것이 선택될지 예측하기 어렵습니다. 하나 이상의 포함된 파일에서 동일한 작업 이름을 사용하는 경우, 매개변수가 Merge됩니다.

파이프라인에서 작업 그룹화

유사한 작업이 많은 경우 파이프라인 그래프가 길어지고 읽기 어려워집니다.

유사한 작업을 자동으로 그룹화할 수 있습니다. 작업 이름이 특정 방식으로 형식화된 경우 레귤러 파이프라인 그래프(미니 그래프가 아님)에서 그룹화됩니다.

파이프라인에서 작업이 그룹화되었음을 알 수 있습니다(재시도 또는 취소 버튼이 표시되지 않음) 상태를 보고 찾아볼 수 있습니다. 이를 선택하면 그룹화된 작업 수가 표시됩니다.

작업을 그룹화하려면 .gitlab-ci.yml 파일에서 각 작업 이름을 번호 및 다음 중 하나로 구분합니다:

  • 슬래시(/), 예: slash-test 1/3, slash-test 2/3, slash-test 3/3.
  • 콜론(:), 예: colon-test 1:3, colon-test 2:3, colon-test 3:3.
  • 공백, 예: space-test 0 3, space-test 1 3, space-test 2 3.

이러한 기호를 상호 교환하여 사용할 수 있습니다.

다음 예제에서 세 가지 작업은 build ruby라는 그룹에 속합니다. 

build ruby 1/3:
  stage: build
  script:
    - echo "루비1"

build ruby 2/3:
  stage: build
  script:
    - echo "루비2"

build ruby 3/3:
  stage: build
  script:
    - echo "루비3"

파이프라인 그래프에는 세 개의 작업이 있는 build ruby 그룹이 표시됩니다.

이러한 작업은 왼쪽에서 오른쪽으로 숫자를 비교하여 순서가 결정됩니다. 일반적으로 첫 번째 숫자를 인덱스로 사용하고 두 번째 숫자를 총 개수로 사용합니다.

이 정규식은 작업 이름을 평가합니다: ([\b\s:]+((\[.*\])|(\d+[\s:\/\\]+\d+))){1,3}\s*\z. [...], X Y, X/Y, 또는 X\Y 시퀀스 하나 이상이 작업 이름의 끝에서만 제거됩니다. 일치하는 부분 문자열은 이름의 시작이나 중간에 있어도 제거되지 않습니다.

작업 숨기기

작업을 구성 파일에서 삭제하지 않고 일시적으로 비활성화하려면:

  • 작업 구성을 주석 처리하십시오: 

    # hidden_job:
#   script:
#     - 테스트 실행

  • 작업 이름을 점(.)으로 시작하고 GitLab CI/CD에서 처리되지 않습니다: 

    .hidden_job:
  script:
    - 테스트 실행

.로 시작하는 숨겨진 작업을 템플릿으로 사용하여:

기본 키워드 및 전역 변수의 상속 제어

다음을 상속할 수 있습니다:

예를 들어: 

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
  WEBHOOK_URL: https://my-webhook.example.com

rubocop:
  inherit:
    default: false
    variables: false
  script: bundle exec rubocop

rspec:
  inherit:
    default: [image]
    variables: [WEBHOOK_URL]
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma

이 예에서:

  • rubocop:
    • 상속: 없음.
  • rspec:
    • 상속: 기본 image 및 WEBHOOK_URL 변수.
    • 상속되지 않음: 기본 before_script 및 DOMAIN 변수.
  • capybara:
    • 상속: 기본 before_script 및 image.
    • 상속되지 않음: DOMAIN 및 WEBHOOK_URL 변수.
  • karma:
    • 상속: 기본 image 및 before_script, 그리고 DOMAIN 변수.
    • 상속되지 않음: WEBHOOK_URL 변수.

매뉴얼 작업을 실행할 때 변수 지정

매뉴얼 작업을 실행할 때 작업별 추가 변수를 제공할 수 있습니다.

원하는 추가 변수가 있는 매뉴얼 작업의 작업 페이지에서 해당 페이지로 이동하여 실행할 수 있습니다. 파이프라인 뷰에서 매뉴얼 작업의 이름을 선택하고, Run이 아닌 을 선택합니다.

CI/CD 변수를 사용하는 작업을 실행할 때 여기서 CI/CD 변수를 정의할 수 있습니다.

CI/CD 설정이나 .gitlab-ci.yml 파일에서 이미 정의된 변수를 추가하면 변수가 덮어씌워집니다 새 값으로. 이 프로세스를 사용하여 덮어씌워진 변수는 펼쳐지게 되며 마스킹되지 않습니다.

매뉴얼 작업 변수

작업 지연

작업을 즉시 실행하고 싶지 않은 경우 when:delayed 키워드를 사용하여 일정 기간 동안 작업을 지연시킬 수 있습니다.

이는 새 코드를 점진적으로 배포하는 시간별 점진적 롤아웃에 특히 유용합니다.

예를 들어 새 코드를 배포를 시작하고:

  • 사용자가 문제를 경험하지 않는다면, GitLab은 자동으로 배포를 0%부터 100%로 완료할 수 있습니다.
  • 사용자가 새 코드로 문제를 경험한다면, 파이프라인을 취소하여 점진적 롤아웃을 중지하고 rolling하여 마지막 안정적인 버전으로 되돌릴 수 있습니다.

파이프라인 예제

작업 로그 섹션 확장 및 축소

작업 로그는 확장하거나 축소할 수 있는 섹션으로 나뉩니다. 각 섹션은 지속 시간을 표시합니다.

다음 예에서:

  • 세 개의 섹션이 축소되어 확장할 수 있습니다.
  • 세 개의 섹션이 확장되어 축소할 수 있습니다.

축소 가능한 섹션

사용자 정의 축소 가능한 섹션

직접 특별한 코드를 출력하여 GitLab이 축소할 섹션을 결정하도록 하는 작업 로그의 축소 가능한 섹션을 생성할 수 있습니다:

  • 섹션 시작 마커: \e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K + TEXT_OF_SECTION_HEADER
  • 섹션 종료 마커: \e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K

이 코드를 CI 구성의 스크립트 섹션에 추가해야 합니다. 예를 들어, echo를 사용하여: 

job1:
  script:
    - echo -e "\e[0Ksection_start:`date +%s`:my_first_section\r\e[0KHeader of the 1st collapsible section"
    - echo 'this line should be hidden when collapsed'
    - echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"

러너가 사용하는 쉘에 따라(예: Zsh를 사용하는 경우) 특수 문자를 이스케이프해야 할 수 있습니다. \\e 및 \\r과 같이:

  • date +%s: 유닉스 타임스탬프(예: 1560896352).
  • my_first_section: 섹션에 지정된 이름. 이름은 문자, 숫자 및 _, ., 또는 - 문자로만 구성될 수 있습니다.
  • \r\e[0K: 렌더링된(색이 칠해진) 작업 로그에 섹션 마커를 표시하지 않지만, 원시 작업 로그에 표시됩니다. 이를 확인하려면 작업 로그의 오른쪽 상단에서 전체 원본 표시를 선택합니다.
    • \r: 캐리지 리턴.
    • \e[0K: 라인을 지우는 ANSI 이스케이프 시퀀스(\e[K는 작동하지 않으며 0을 포함해야 함).

샘플 원시 작업 로그: 

\e[0Ksection_start:1560896352:my_first_section\r\e[0KHeader of the 1st collapsible section
this line should be hidden when collapsed
\e[0Ksection_end:1560896353:my_first_section\r\e[0K

샘플 작업 콘솔 로그:

사용자 정의 축소 가능한 섹션

축소 가능한 섹션 표시를 개선하기 위한 스크립트 사용

작업 출력에서 echo 문을 제거하려면 작업 내용을 스크립트 파일로 이동하고 작업에서 호출할 수 있습니다:

  1. 섹션 헤더를 처리할 수 있는 스크립트 생성. 예: 

    # 섹션 시작 함수
function section_start () {
  local section_title="${1}"
  local section_description="${2:-$section_title}"
     
  echo -e "section_start:`date +%s`:${section_title}[collapsed=true]\r\e[0K${section_description}"
}
   
# 섹션 종료 함수
function section_end () {
  local section_title="${1}"
     
  echo -e "section_end:`date +%s`:${section_title}\r\e[0K"
}
   
# 섹션 생성
section_start "my_first_section" "Header of the 1st collapsible section"
   
echo "this line should be hidden when collapsed"
   
section_end "my_first_section"
   
# 필요한 만큼 반복

  2. 스크립트를 .gitlab-ci.yml 파일에 추가: 

    job:
  script:
    - source script.sh

사전 축소 섹션

축소 가능한 섹션을 자동으로 축소하게 만들 수 있습니다. 섹션 시작에 collapsed 옵션을 추가합니다. 섹션 이름 뒤에 [collapsed=true]을 더하고 \r 앞에 추가합니다. 섹션 종료 마커는 변경되지 않습니다:

  • [collapsed=true]가 있는 섹션 시작 마커: \e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME[collapsed=true]\r\e[0K + TEXT_OF_SECTION_HEADER
  • 섹션 종료 마커: \e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K

갱신된 섹션 시작 텍스트를 CI 구성에 추가합니다. 예를 들어, echo를 사용하여: 

job1:
  script:
    - echo -e "\e[0Ksection_start:`date +%s`:my_first_section[collapsed=true]\r\e[0KHeader of the 1st collapsible section"
    - echo 'this line should be hidden automatically after loading the job log'
    - echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"

전체 화면 모드

전체 화면 보기를 클릭하여 작업 로그 내용을 전체 화면 모드로 볼 수 있습니다.

전체 화면 모드를 사용하려면 웹 브라우저도 지원해야 합니다. 웹 브라우저가 전체 화면 모드를 지원하지 않으면 해당 옵션이 제공되지 않습니다.

배포 작업

배포 작업은 환경으로 코드를 배포하는 특정 유형의 CI 작업입니다. 배포 작업은 environment 키워드와 start environment action을 사용하며 deploy 단계에 있을 필요도 없습니다. 아래 deploy me 작업은 배포 작업의 예입니다. action: start는 기본 동작이며 예시를 위해 정의되었지만 생략할 수 있습니다: 

deploy me:
  script:
    - deploy-to-cats.sh
  environment:
    name: production
    url: https://cats.example.com
    action: start

배포 작업의 동작은 배포 안전성 설정으로 제어할 수 있으며 오래된 배포 작업 방지 및 동시에 한 번에 하나의 배포 작업만 실행 보장과 같은 설정을 적용할 수 있습니다.

문제 해결

작업 로그 업데이트가 느림

실행 중인 작업의 작업 로그 페이지를 방문할 때 로그 업데이트까지 최대 60초의 지연이 발생할 수 있습니다. 기본 새로 고침 시간은 60초이지만, 한 번 UI에서 로그를 본 후에는 로그 업데이트가 3초마다 발생해야 합니다.

get_sources 작업 섹션이 HTTP/2 문제로 실패함

가끔, 다음과 같은 cURL 오류로 작업이 실패할 수 있습니다. 

++ git -c 'http.userAgent=gitlab-runner <version>' fetch origin +refs/pipelines/<id>:refs/pipelines/<id> ...
error: RPC failed; curl 16 HTTP/2 send again with decreased length
fatal: ...

Git과 libcurl을 HTTP/1.1을 사용하도록 구성하여 이 문제를 해결할 수 있습니다. 구성은 다음 위치에 추가할 수 있습니다:

resource_group를 사용하는 작업이 멈춤

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

resource_group을 사용하는 작업이 멈춘 경우, GitLab 관리자는 rails console에서 다음 명령을 실행해볼 수 있습니다. 

# 이름으로 resource group 찾기
resource_group = Project.find_by_full_path('...').resource_groups.find_by(key: 'the-group-name')
busy_resources = resource_group.resources.where('build_id IS NOT NULL')

# 해당 리소스를 점유하고 있는 빌드 식별
# (오늘 기준으로 1이어야 할 것 같습니다)
busy_resources.pluck(:build_id)

# 해당 빌드가 리소스를 점유하는 이유를 확인하는 것이 좋습니다.
# 멈춘 상태인가요? 시스템에서 강제로 삭제되었나요?
# 바쁜 리소스 해제
busy_resources.update_all(build_id: nil)