- 파이프라인에서 작업보기
- 작업 실패 사유 확인
- 파이프라인 내 작업의 순서
- 작업 이름 제한
- 파이프라인 내 작업 그룹화
- 작업 숨기기
- 기본 키워드 및 전역 변수의 상속 제어
- 수동 작업 실행 시 변수 지정
- 작업 지연
- 전체 화면 작업 로그 보기
- 배포 작업
- 문제 해결
작업
작업은 GitLab CI/CD 파이프라인의 기본 요소입니다. 작업은 .gitlab-ci.yml 파일에 명령어 목록으로 구성되어 빌드, 테스트 또는 코드 배포와 같은 작업을 수행하는 데 사용됩니다.
작업은 다음과 같습니다.
- 실행 조건을 명시하는 제약 조건으로 정의됩니다.
- 임의의 이름을 가진 최상위 요소이며 적어도
script절을 포함해야 합니다. - 정의할 수 있는 수에 제한이 없습니다.
예를 들어,
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
위의 예는 두 개의 별도 작업을 실행하는 가장 간단한 CI/CD 구성입니다. 각 작업은 다른 명령을 실행합니다.
물론 명령어는 직접 코드를 실행할 수 있습니다(./configure;make;make install)
또는 저장소에서 스크립트(test.sh)를 실행할 수 있습니다.
작업은 러너에 의해 수행되며 러너의 환경에서 실행됩니다. 각 작업이 서로 독립적으로 실행된다는 것이 중요합니다.
파이프라인에서 작업보기
파이프라인에 액세스하면 해당 파이프라인의 관련 작업을 볼 수 있습니다.
개별 작업을 선택하면 해당 작업 로그를 볼 수 있으며 다음을 수행할 수 있습니다.
- 작업 취소
- 작업 다시 시도 (실패한 경우)
- 작업 다시 실행 (성공한 경우)
- 작업 로그 지우기
- 프로젝트 내 모든 작업 보기
- GitLab.com과 Self-managed에 도입된 작업 이름으로 작업 필터링 기능 발표 및
populate_and_use_build_names_table이라는 플래그로 GitLab 17.3에 도입됨. GitLab.com에서는 이 기능이 기본적으로 활성화되어 있지만 Self-managed에서는 기본적으로 비활성화되어 있습니다.
플래그: 이 기능의 가용성은 특성 플래그로 제어됩니다. 자세한 내용은 히스토리를 참조하십시오.
프로젝트에서 실행된 작업의 전체 목록을 보려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 빌드 > 작업을 선택합니다.
작업 상태 및 작업 이름으로 목록을 필터링할 수 있습니다.
작업 실패 사유 확인
파이프라인이 실패하거나 실패할 수 있을 때 사유를 여러 곳에서 찾을 수 있습니다.
- 파이프라인 그래프 및 파이프라인 세부 정보보기를 확인하면 알 수 있습니다.
- 병합 요청 및 커밋 페이지의 파이프라인 위젯에서 확인할 수 있습니다.
- 작업 보기에서 전역 및 상세 보기에서 확인할 수 있습니다.
각 위치에서 실패한 작업 위에 마우스를 올리면 실패한 이유를 확인할 수 있습니다.
또한 작업 세부 정보 페이지에서 실패한 이유를 확인할 수 있습니다.
루트 원인 분석으로 실패한 작업 문제 해결
GitLab Duo 채팅의 GitLab Duo 루트 원인 분석을 사용하여 실패한 CI/CD 작업을 해결할 수 있습니다.
파이프라인 내 작업의 순서
파이프라인 내 작업의 순서는 파이프라인 그래프의 종류에 따라 달라집니다.
- 전체 파이프라인 그래프의 경우 작업이 이름별로 정렬됩니다.
- 파이프라인 미니 그래프](../pipelines/index.md#pipeline-mini-graphs)의 경우 작업이 상태별로 정렬된 뒤 이름별로 정렬됩니다.
작업 상태 순서는 다음과 같습니다.
- 실패함
- 경고
- 보류 중
- 실행 중
- 수동
- 예약됨
- 취소됨
- 성공
- 건너뜀
- 생성됨
작업 이름 제한
다음과 같은 키워드는 작업 이름으로 사용할 수 없습니다.
imageservicesstagesbefore_scriptafter_scriptvariablescacheinclude-
pages:deploy가deploy단계에 대해 구성된 경우
또한 다음과 같은 이름은 따옴표로 감싸지 않으면 유효하지만 파이프라인 구성을 애매하게 만들 수 있어 사용을 권장하지 않습니다.
"true":"false":"nil":
작업 이름은 255자 이하이어야 합니다.
작업에는 고유한 이름을 사용해야 합니다. 파일에서 여러 작업이 같은 이름을 가지는 경우 파이프라인에 적용되는 작업은 하나뿐이며 어떤 작업이 선택되는지 예측하기 어려울 수 있습니다. 하나 이상의 포함된 파일에서 동일한 작업 이름을 사용하는 경우, 매개변수가 병합됩니다.
파이프라인 내 작업 그룹화
유사한 작업이 많을 경우 파이프라인 그래프가 길고 읽기 어렵게 됩니다.
유사한 작업을 자동으로 그룹화할 수 있습니다. 작업 이름을 특정 방식으로 형식화하면 일반적인 파이프라인 그래프(미니 그래프가 아님)에서 해당 작업이 단일 그룹으로 병합됩니다.
작업을 그룹화한 파이프라인을 인식할 수 있습니다. 해당 작업 안에 다시 시도 또는 취소 버튼이 표시되지 않습니다. 해당 작업에 마우스를 올리면 그룹화된 작업 수를 확인할 수 있습니다. 확장을 선택하면 해당 작업을 볼 수 있습니다.
예를 들어, 다음 세 개의 작업은 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 시퀀스가 끝에 있는 작업 이름에서만 제거됩니다. 작업 이름의 시작 부분이나 중간에서 발견된 일치하는 부분은 제거되지 않습니다.
작업 숨기기
구성 파일에서 작업을 삭제하지 않고 임시로 작업을 비활성화하려면:
-
작업 구성을 주석 처리하세요.
# hidden_job: # script: # - run test -
작업 이름을 마침표(
.)로 시작하면 GitLab CI/CD에서 처리되지 않습니다..hidden_job: script: - run test
.로 시작하는 숨겨진 작업을 사용하여 재사용 가능한 구성에 대한 템플릿으로 사용할 수 있습니다. 다음을 사용하여:
기본 키워드 및 전역 변수의 상속 제어
다음을 통해 상속을 제어할 수 있습니다:
-
inherit:default로 기본 키워드를 제어합니다. -
inherit:variables로 전역 변수를 제어합니다.
예를 들어:
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변수.
- 상속: 기본
수동 작업 실행 시 변수 지정
수동 작업을 실행할 때 추가 작업별 변수를 제공할 수 있습니다.
이를 수행하려면 웹 브라우저가 해당 기능을 지원해야 합니다. 웹 브라우저가 전체 화면 모드를 지원하지 않으면 해당 옵션이 표시되지 않습니다.
작업 지연
작업을 즉시 실행하고 싶지 않은 경우, 특정 기간 동안 작업 실행을 지연시키려면 when:delayed 키워드를 사용할 수 있습니다.
전체 화면 작업 로그 보기
- GitLab 16.7에서 도입되었습니다.
“전체 화면 표시”를 클릭하여 작업 로그 내용을 전체 화면 모드로 볼 수 있습니다.
전체 화면 모드를 사용하려면 웹 브라우저가 해당 기능을 지원해야 합니다. 웹 브라우저가 전체 화면 모드를 지원하지 않으면 해당 옵션이 표시되지 않습니다.
배포 작업
배포 작업은 환경으로 코드를 배포하는 특정 유형의 CI 작업입니다. 배포 작업은 environment 키워드 및 start environment action을 사용하는 모든 작업입니다. 배포 작업은 deploy 단계에 있을 필요가 없습니다. 다음은 배포 작업의 예입니다. action: start는 예시를 위해 정의되었지만 기본 동작이며 이를 생략할 수 있습니다.
deploy me:
script:
- deploy-to-cats.sh
environment:
name: production
url: https://cats.example.com
action: start
배포 작업의 동작은 배포 안전 설정으로 제어할 수 있습니다. 이 설정은 오래된 배포 작업 방지 및 한 번에 한 개의 배포 작업 실행 보장과 같은 것을 포함합니다.
문제 해결
작업 로그 업데이트가 느림
실행 중인 작업의 작업 로그 페이지를 방문할 때, 작업 로그 업데이트에 최대 60초의 지연이 발생할 수 있습니다.
get_sources 작업 섹션이 HTTP/2 문제로 실패함
URL에 따라 설정을 추가하십시오:
-
job_name: hooks: pre_get_sources_script: - git config --global http.version "HTTP/1.1" -
Git 설정 환경 변수로 구성자의
config.toml에서: with Git configuration environment variables in the runner’sconfig.toml:[[runners]] ... environment = [ "GIT_CONFIG_COUNT=1", "GIT_CONFIG_KEY_0=http.version", "GIT_CONFIG_VALUE_0=HTTP/1.1" ]
resource_group을 사용하는 작업이 멈춤 현상 발생
만약 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)
도움말