작업

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

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

작업은:

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

예시: 

job1:
  script: "execute-script-for-job1"

job2:
  script: "execute-script-for-job2"

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

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

파이프라인에서 작업 보기

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

개별 작업을 선택하면 해당 작업 로그를 볼 수 있고 다음을 수행할 수 있습니다:

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

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

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

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

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

작업 실패 원인 보기

파이프라인이 실패하거나 실패해도 괜찮다고 허용된 경우 실패한 이유를 여러 곳에서 찾을 수 있습니다:

  • 파이프라인 그래프에서 파이프라인 상세 보기.
  • 머지 요청 및 커밋 페이지의 파이프라인 위젯.
  • 전역 및 작업 상세보기에서 작업 보기.

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

파이프라인 상세

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

파이프라인의 작업 순서

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

작업 상태 순서는:

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

예시:

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

작업 이름 제한

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

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

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

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

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

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

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

파이프라인이 작업을 그룹화했는지 여부를 알 수 있습니다. 해당 그룹 내에서 다시 시도 또는 취소 버튼이 표시되지 않은 경우입니다. 해당 항목 위로 마우스를 올리면 그룹화된 작업 수를 볼 수 있습니다. 확장하려면 선택합니다.

그룹화된 파이프라인

파이프라인 그래프에 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

.로 시작하는 숨겨진 작업을 재사용 가능한 구성의 템플릿으로 사용할 수 있습니다. 이때 다음을 활용하세요:

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

다음을 통해 상속을 관리할 수 있습니다:

예시: 

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 'this line should be hidden when collapsed'
    - echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"

Runner가 사용하는 쉘에 따라 (예: Zsh라면) 특수 문자를 이스케이핑해야 할 수 있습니다. 예를 들어 \\e 및 \\r과 같이 사용합니다.

위의 예시에서:

  • date +%s: 유닉스 타임스탬프 (예: 1560896352).
  • my_first_section: 섹션에 부여된 이름. 이름은 문자, 숫자, _, ., 또는 - 문자로만 구성될 수 있습니다.
  • \r\e[0K: 렌더링(컬러)된 작업 로그에 섹션 마커가 표시되지 않지만, 그림자 때문에 원시 작업 로그에 표시됩니다. 이를 보려면 작업 로그의 오른쪽 상단에서 Show complete raw()를 선택하세요.
    • \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. 섹션 헤더를 처리할 수 있는 스크립트를 만듭니다. 예:
   
   ```shell
   # 섹션 시작을 위한 함수
   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" "1번 접을 수 있는 섹션의 헤더"
   
   echo "이 줄은 접혔을 때 숨겨져야 합니다"
   
   section_end "my_first_section"
   
   # 필요에 따라 반복

  1. .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[0K1번 접을 수 있는 섹션의 헤더"
    - echo '작업 로그를 불러온 후 자동으로 숨겨져야 하는 이 줄'
    - echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"

전체 화면 모드

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

전체 화면 모드를 사용하려면 웹 브라우저도 지원해야 합니다. 웹 브라우저가 전체 화면 모드를 지원하지 않는 경우, 해당 옵션이 사용할 수 없습니다.

배포 작업

배포 작업은 environments로 코드를 배포하는 특정 유형의 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 설정을 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')
바쁜 리소스 = resource_group.resources.where('build_id IS NOT NULL')

# 리소스를 점유하는 빌드 식별
# (오늘을 기준으로 1이어야 할 것으로 생각됨)
바쁜 리소스.pluck(:build_id)

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

```