- 파이프라인에서 작업 보기
- 작업 실패 이유 보기
- 파이프라인에서 작업 순서
- 작업 이름 제한
- 파이프라인에서 작업 그룹화
- 작업 숨기기
- 기본 키워드 및 전역 변수의 상속 제어
- 수동 작업 실행 시 변수 지정
- 작업 지연
- 전체 화면 모드에서 작업 로그 보기
- 배포 작업
- 문제 해결
작업
작업은 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 17.3의 GitLab.com 및 자체 관리에서
populate_and_use_build_names_table이라는 플래그와 함께. GitLab.com에서는 이 기능이 기본적으로 활성화되어 있습니다. 자체 관리에서는 이 기능이 기본적으로 비활성화되어 있습니다.
이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다. 자세한 내용은 기록을 참조하십시오.
프로젝트에서 실행된 작업의 전체 목록을 보려면:
- 왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
- Build > Jobs를 선택합니다.
작업 목록을 작업 상태 및 작업 이름으로 필터링할 수 있습니다.
작업 실패 이유 보기
파이프라인이 실패하거나 실패를 허용할 경우 여러 곳에서 이유를 찾을 수 있습니다:
- 파이프라인 그래프에서, 파이프라인 세부 정보 보기.
- 병합 요청 및 커밋 페이지의 파이프라인 위젯에서.
- 작업 보기, 작업의 전체 및 세부 보기에서.
각 장소에서 실패한 작업 위에 마우스를 가져가면 실패한 이유를 확인할 수 있습니다.
작업 세부정보 페이지에서도 실패한 이유를 확인할 수 있습니다.
루트 원인 분석을 통한 실패한 작업 문제 해결
GitLab Duo 루트 원인 분석을 사용하여 GitLab Duo 채팅에서 실패한 CI/CD 작업을 문제 해결할 수 있습니다.
파이프라인에서 작업 순서
파이프라인에서 작업의 순서는 파이프라인 그래프의 유형에 따라 다릅니다.
- 전체 파이프라인 그래프의 경우, 작업은 이름별로 정렬됩니다.
- 파이프라인 미니 그래프의 경우, 작업은 상태별로 정렬된 후 이름별로 정렬됩니다.
작업 상태 순서는 다음과 같습니다:
- 실패
- 경고
- 대기 중
- 실행 중
- 수동
- 예약됨
- 취소됨
- 성공
- 건너뛰기
- 생성됨
작업 이름 제한
이 키워드를 작업 이름으로 사용할 수 없습니다:
imageservicesstagesbefore_scriptafter_scriptvariablescacheinclude-
pages:deploy가deploy단계에 대해 구성된 경우
또한, 이러한 이름은 인용할 경우 유효하지만 파이프라인 구성이 명확하지 않게 만들 수 있으므로 권장하지 않습니다:
"true":"false":"nil":
작업 이름은 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 시퀀스는 작업 이름의 끝에서만 제거됩니다. 작업 이름의 시작 부분이나 중간에서 발견된 일치하는 부분 문자열은 제거되지 않습니다.
작업 숨기기
구성 파일에서 작업을 삭제하지 않고 일시적으로 비활성화하려면:
-
작업의 구성을 주석처리합니다:
# 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변수를 상속받지 않음.
- 기본
수동 작업 실행 시 변수 지정
수동 작업을 실행할 때 추가적인 작업 특정 변수를 제공할 수 있습니다.
이 작업을 실행하려는 수동 작업의 작업 페이지에서 추가 변수를 사용하여 수행할 수 있습니다. 이 페이지에 접근하려면 파이프라인 보기에서 수동 작업의 이름을 선택하십시오, Run ( 아님).
여기에서 CI/CD 변수를 정의하면 CI/CD 변수를 사용하는 작업의 실행을 변경할 수 있습니다.
CI/CD 설정이나 .gitlab-ci.yml 파일에서 이미 정의된 변수를 추가하면, 변수가 새 값으로 재정의됩니다.
이 과정을 통해 재정의된 변수는 확장되고 마스킹되지 않습니다.
작업 지연
작업을 즉시 실행하고 싶지 않다면, when:delayed 키워드를 사용하여 작업 실행을 특정 기간 동안 지연시킬 수 있습니다.
이 방법은 새로운 코드가 점진적으로 배포되는 타이밍 점진적 배포에 특히 유용합니다.
예를 들어, 새로운 코드 배포를 시작할 때:
- 사용자가 어려움을 겪지 않는다면, GitLab은 배포를 0%에서 100%로 자동으로 완료할 수 있습니다.
- 사용자가 새로운 코드에서 문제를 경험하면, 파이프라인을 취소하여 타이밍 점진적 배포를 중단하고 롤백하여 마지막 안정적인 버전으로 돌아갈 수 있습니다.
전체 화면 모드에서 작업 로그 보기
- 소개됨 in GitLab 16.7.
전체 화면 표시를 클릭하여 작업 로그의 내용을 전체 화면 모드에서 볼 수 있습니다.
전체 화면 모드를 사용하려면 웹 브라우저가 이를 지원해야 합니다. 만약 웹 브라우저가 전체 화면 모드를 지원하지 않으면 해당 옵션을 사용할 수 없습니다.
배포 작업
배포 작업은 코드를 환경에 배포하는 특정 유형의 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 사용으로 구성할 수 있습니다. 구성은 다음의 위치에 추가할 수 있습니다:
-
job_name: hooks: pre_get_sources_script: - git config --global http.version "HTTP/1.1" -
runner의
config.toml에서 Git 구성 환경 변수:[[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 = 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)
도움말