작업

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

파이프라인 구성은 작업으로 시작됩니다. 작업은 .gitlab-ci.yml 파일의 가장 기본적인 요소입니다.

작업은 다음과 같습니다.

  • 실행 조건을 명시하여 정의됨.
  • 임의의 이름으로 상위 요소로 정의되어 있어야 하며 적어도 script 절을 포함해야 함.
  • 정의할 수 있는 개수에 제약이 없음.

예를 들어: 

job1:
  script: "job1을 위한 스크립트 실행"

job2:
  script: "job2을 위한 스크립트 실행"

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

작업은 런너에 의해 선택되고 러너 환경에서 실행됩니다. 각 작업이 서로 독립적으로 실행되는 것이 중요합니다.

파이프라인에서 작업 보기

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

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

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

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

프로젝트에서 실행된 전체 작업 목록을 보려면:

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

작업 상태로 목록을 필터링할 수 있습니다.

작업 실패 원인 보기

파이프라인이 실패하거나 실패할 수 있는 경우, 다음 위치에서 원인을 찾을 수 있습니다.

  • 파이프라인 그래프의 파이프라인 세부 정보 화면.
  • 통합 요청 및 커밋 페이지의 파이프라인 위젯.
  • 작업 보기의 작업 전반적인 및 자세한 화면.

각 위치에서 실패한 작업 위로 마우스를 가져가면 실패한 이유를 볼 수 있습니다.

파이프라인 상세

또한 작업 상세 페이지에서 실패한 이유를 볼 수 있습니다.

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

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

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

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

예를 들어:

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

작업 이름 제한

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

  • image
  • services
  • stages
  • types
  • before_script
  • after_script
  • variables
  • cache
  • include
  • true
  • false
  • nil
  • pages:deploy는 deploy 단계에 구성된 경우 사용할 수 없음.

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

작업 이름에는 고유한 이름을 사용해야 합니다. 파일에 동일한 이름의 작업이 여러 개 있는 경우에는 하나만 파이프라인에 추가되며 선택된 작업이 예측하기 어려울 수 있습니다. 하나 이상의 포함된 파일에서 동일한 작업 이름이 사용된 경우에는 매개변수가 병합됩니다.

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

많은 유사한 작업이 있는 경우, 파이프라인 그래프는 길어지고 파악하기 어려워집니다.

유사한 작업을 자동으로 그룹화할 수 있습니다. 작업 이름이 특정한 방식으로 서식이 지정된 경우에는 정규 파이프라인 그래프(미니 그래프가 아님)에 단일 그룹으로 축소됩니다.

작업이 그룹화된 파이프라인을 인식하는 방법은 그룹 내에서 재시도 또는 취소 단추를 볼 수 없는 경우입니다. 해당 작업 위에 마우스를 가져가면 그룹화된 작업 수를 볼 수 있습니다. 확장하려면 선택하세요.

그룹화된 파이프라인

그룹화된 작업을 만들려면 .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 "ruby1"

build ruby 2/3:
  stage: build
  script:
    - echo "ruby2"

build ruby 3/3:
  stage: build
  script:
    - echo "ruby3"

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

숫자를 왼쪽에서 오른쪽으로 비교하여 작업을 순서대로 나열합니다. 첫 번째 번호가 인덱스이고 두 번째 번호가 전체 개수 여야 합니다.

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

GitLab 13.8 및 이전에서는 정규 표현식이 \d+[\s:\/\\]+\d+\s*입니다. 기능 플래그는 GitLab 13.11에서 제거되었습니다.

작업 숨기기

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

  • 작업 설정을 주석 처리하세요. 

    # hidden_job:
#   script:
#     - run test

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

    .hidden_job:
  script:
    - run test

extends 키워드 및 YAML 앵커로 재사용 가능한 구성의 템플릿으로 사용할 수 있습니다.

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

다음을 상속으로 제어할 수 있습니다:

예를 들어: 

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 변수.

수동 작업 실행 시 변수 지정

수동 작업 실행 시 작업별 변수를 추가로 지정할 수 있습니다.

이를 위해 파이프라인 뷰에서 버튼이 아닌 수동 작업의 이름을 선택하여 작업 페이지에서 추가 변수를 지정할 수 있습니다.

CI/CD 변수를 사용하는 작업의 실행을 변경하려면 여기에서 CI/CD 변수를 정의하세요.

CI/CD 설정 또는 .gitlab-ci.yml 파일에 이미 정의된 변수를 추가하는 경우, 변수가 덮어씌워집니다.

수동 작업 변수

작업 지연

작업을 즉시 실행시키지 않으려면 when:delayed 키워드를 사용하여 일정 기간 작업 실행을 지연시킬 수 있습니다.

특히 새 코드를 점진적으로 배포하는 타이밍별 점진적 배포에 유용합니다.

예를 들어, 새 코드를 점진적으로 배포 시작하고:

  • 사용자들에게 문제가 발생하지 않으면, GitLab은 자동으로 배포를 0%부터 100%로 완료할 수 있습니다.
  • 사용자들이 새 코드로 문제를 경험한다면, 파이프라인을 취소하여 타이밍별 점진적 배포를 중지하고 마지막 안정 버전으로 롤백할 수 있습니다.

파이프라인 예시

작업 로그 섹션 확장 및 축소

작업 로그는 확장 또는 축소할 수 있는 섹션으로 분할되어 있습니다. 각 섹션에는 기간이 표시됩니다.

다음 예에서:

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

접기 가능한 섹션

사용자 정의 접기 가능한 섹션

작업 로그에서 접기 가능한 섹션을 만들려면 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 '이 줄은 숨겨져야 합니다.'
    - 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
이 줄은 접혀있을 때 숨겨져야 합니다.
\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 "이 줄은 접혀있을 때 숨겨져야 합니다."

section_end "my_first_section"

# 필요한 만큼 반복

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

    job:
  script:
    - source script.sh

미리 접힌 섹션

접기 가능한 섹션을 자동으로 접게 하려면 섹션 시작에 collapsed 옵션을 추가하여 작업 로그를 만들 수 있습니다. 섹션 이름 뒤에 \r 전에 [collapsed=true]를 추가합니다. 섹션 끝 마커는 변경되지 않습니다:

  • [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 '이 줄은 작업 로그를 로드한 후 자동으로 숨겨집니다.'
    - 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

작업이 멈추는 경우, GitLab 관리자는 다음 명령어를 레일즈 콘솔에서 실행해 볼 수 있습니다: 

# 이름으로 리소스 그룹 찾기
resource_group = Project.find_by_full_path('...').resource_groups.find_by(key: 'the-group-name')
바쁜 리소스 = resource_group.resources.where('build_id IS NOT NULL')

# 어떤 작업이 리소스를 점유하고 있는지 확인
# (오늘 기준으로 1이어야 합니다)
바쁜 리소스.pluck(:build_id)

# 이 작업이 왜 리소스를 확보하고 있는지 확인하는 것이 좋습니다.
# 멈춘 상태인지, 시스템에 의해 강제로 해제되었는지 등을 확인하세요.
# 바쁜 리소스 해제하기
바쁜 리소스.update_all(build_id: nil)