CI/CD 파이프라인

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

파이프라인은 지속적 통합, 전달 및 배포의 최상위 컴포넌트입니다.

파이프라인에는 다음이 포함됩니다:

무엇을 할 지를 정의하는 잡(Job)들입니다. 예를 들어, 코드를 컴파일하거나 테스트하는 잡들입니다.
언제 잡을 실행할 지를 정의하는 스테이지(Stage)들입니다. 예를 들어, 코드를 컴파일한 후 테스트를 실행하는 스테이지들입니다.

잡들은 러너에 의해 실행됩니다. 동시 러너가 충분하다면 동일한 스테이지의 여러 잡이 병렬로 실행됩니다.

한 스테이지의 모든 잡이 성공하면 파이프라인은 다음 스테이지로 진행합니다.

한 스테이지의 어떤 잡이라도 실패하면 다음 스테이지는 (일반적으로) 실행되지 않고 파이프라인이 일찍 끝납니다.

일반적으로 파이프라인은 자동으로 실행되며, 생성된 후에는 개입이 필요하지 않습니다. 그러나 때로는 파이프라인과 매뉴얼으로 상호작용해야 하는 경우도 있습니다.

전형적인 파이프라인은 다음 순서로 실행될 수 있는 네 가지 스테이지로 구성될 수 있습니다:

build 스테이지, 하나의 compile이라는 잡이 있는 스테이지입니다.
test 스테이지, test1 및 test2라고 불리는 두 개의 잡이 있는 스테이지입니다.
staging 스테이지, deploy-to-stage라는 잡이 있는 스테이지입니다.
production 스테이지, deploy-to-prod라는 잡이 있는 스테이지입니다.

GitLab이 가져온 반사 리포지터리가 있는 경우 프로젝트의 설정 > 리포지터리 > 미러링 리포지터리 > 미러 업데이트에 대해 파이프라인 트리거 설정을 활성화해야 할 수 있습니다.

파이프라인 유형

파이프라인은 다양한 방식으로 구성할 수 있습니다:

기본 파이프라인은 각 스테이지에서 모든 것을 동시에 실행한 후 다음 스테이지로 넘어갑니다.
유향 비순환 그래프(DAG) 파이프라인은 잡들 간의 관계에 기반하여 기본 파이프라인보다 더 빠르게 실행될 수 있습니다.
Merge Request 파이프라인(merge request pipelines)은 커밋마다가 아닌 Merge Request에 대해서만 실행됩니다.
Merge된 결과 파이프라인(merged results pipelines)은 변경 사항이 소스 브랜치에서 대상 브랜치로 이미 Merge된 것으로 간주합니다.
Merge Train(merge trains)은 Merge된 결과 파이프라인을 사용하여 차례로 Merge을 대기열에 넣습니다.
상위-하위 파이프라인(parent-child pipelines)은 여러 하위 서브 파이프라인을 트리거할 수 있는 하나의 상위 파이프라인으로 복잡한 파이프라인을 분해합니다. 이러한 파이프라인 아키텍처는 주로 단일 리포지터리에 사용됩니다.
다중 프로젝트 파이프라인(multi-project pipelines)은 서로 다른 프로젝트의 파이프라인을 결합합니다.

파이프라인 구성

각 프로젝트의 CI/CD 파이프라인 구성 파일에 파이프라인 및 해당 컴포넌트인 잡과 스테이지가 정의됩니다.

Jobs은 기본 구성 컴포넌트입니다.
스테이지는 스테이지 키워드를 사용하여 정의됩니다.

CI/CD 구성 파일에 대한 구성 옵션 디렉터리을 보려면 CI/CD YAML 구문 참조를 참조하세요.

또한 GitLab UI를 통해 파이프라인의 특정 측면을 구성할 수도 있습니다. 예를 들어:

CI/CD 구성을 편집하는 권장 도구는 파이프라인 편집기입니다.

GitLab CI/CD 구성을 편집하는 데 VS Code를 사용하는 경우 GitLab Workflow VS Code 익스텐션을 사용하여 구성을 유효성 검사하고 파이프라인 상태를 확인할 수 있습니다.

파이프라인 매뉴얼 실행

파이프라인은 미리 정의된 또는 매뉴얼으로 지정된 변수로 매뉴얼으로 실행할 수 있습니다.

예를 들어, 파이프라인 결과(예: 코드 작성)가 파이프라인의 표준 작동 범위 외에 필요한 경우에 이를 수행할 수 있습니다.

파이프라인을 매뉴얼으로 실행하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
빌드 > 파이프라인을 선택합니다.
파이프라인 실행을 선택합니다.
브랜치 이름 또는 태그에 대해 실행할 필드에서 파이프라인을 실행할 브랜치 또는 태그를 선택합니다.
파이프라인 실행에 필요한 CI/CD 변수를 입력합니다. 특정 변수를 양식에 미리 입력된 값을 설정할 수 있습니다.
파이프라인 실행을 선택합니다.

이제 파이프라인은 구성된 대로 작업을 실행합니다.

양식에 미리 입력된 변수 입력

пример from the original document is missing in the query.

선택 가능한 미리 설정된 변수 값 디렉터리 구성

GitLab 15.5부터 run_pipeline_graphql이라는 플래그로 도입되었습니다. 기본값은 비활성화되어 있습니다.
GitLab 15.7에서 옵션 키워드가 도입되었습니다.
GitLab 15.7에서 일반 사용됩니다. 피처 플래그 run_pipeline_graphql이 제거되었습니다.
GitLab 15.9에서 해결된 버그로 인해 변수 디렉터리이 때로는 올바르게 채워지지 않을 수 있습니다.

매뉴얼으로 파이프라인을 실행할 때 사용자가 선택할 수 있는 배열의 CI/CD 변수 값을 정의할 수 있습니다. 이러한 값은 파이프라인 실행 페이지의 드롭다운 디렉터리에 표시됩니다. 옵션에 값을 입력하고 값에 기본값을 설정합니다. 값의 문자열은 옵션 디렉터리에도 포함되어 있어야 합니다.

예를 들어:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "배포 대상입니다. 기본값은 'staging'으로 설정됩니다."

URL 쿼리 문자열을 사용하여 파이프라인 실행

Run Pipeline 페이지를 미리 채우려면 쿼리 문자열을 사용할 수 있습니다. 예를 들어, 쿼리 문자열 .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar은 다음과 같이 Run Pipeline 페이지를 미리 채웁니다:

실행 대상: my_branch.
변수 섹션:
- 변수:
  - 키: foo
  - 값: bar
- 파일:
  - 키: file_foo
  - 값: file_bar

pipelines/new URL의 형식은 다음과 같습니다.

.../pipelines/new?ref=<브랜치>&var[<변수_키>]=<값>&file_var[<파일_키>]=<값>

다음 매개변수가 지원됩니다:

ref: 실행 대상 필드를 채울 브랜치를 지정합니다.
var: 변수 변수를 지정합니다.
file_var: 파일 변수를 지정합니다.

각 var 또는 file_var에는 키와 값이 필요합니다.

파이프라인에 매뉴얼 상호 작용 추가

매뉴얼 작업을 통해 파이프라인에서 전진하기 전에 매뉴얼 상호 작용을 요청할 수 있습니다.

파이프라인 그래프에서 직접 수행할 수 있습니다. 특정 작업을 실행하려면 파이프라인 그래프에서 실행 ()을 선택하세요.

예를 들어, 파이프라인은 자동으로 시작할 수 있지만 프로덕션으로 배포하기 전에 매뉴얼 작업이 필요할 수 있습니다. 아래 예에서 production 스테이지에는 매뉴얼 작업이 포함된 작업이 있습니다:

스테이지의 모든 매뉴얼 작업 시작

스테이지에 매뉴얼 작업만 포함되어 있다면, 해당 스테이지 위에 있는 모두 매뉴얼 실행 ()을 선택하여 모든 작업을 동시에 시작할 수 있습니다. 스테이지에 매뉴얼 작업이 아닌 작업이 포함되어 있다면, 해당 옵션이 표시되지 않습니다.

파이프라인 건너뛰기

파이프라인을 트리거하지 않고 커밋을 푸시하려면 커밋 메시지에 [ci skip] 또는 [skip ci] 중 하나를 추가하시기 바랍니다.

또는 Git 2.10 이상에서는 ci.skip Git 푸시 옵션을 사용하시기 바랍니다. ci.skip 푸시 옵션은 Merge Request 파이프라인을 건너뛰지 않습니다.

파이프라인 삭제

프로젝트의 소유자 역할을 가진 사용자는 파이프라인을 삭제할 수 있습니다:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
빌드 > 파이프라인을 선택합니다.
파이프라인 ID(예: #123456789) 또는 파이프라인 상태 아이콘(예: Passed)을 선택합니다.
파이프라인 세부 정보 페이지 오른쪽 상단에서 삭제를 선택합니다.

파이프라인을 삭제하면 하위 파이프라인이 자동으로 삭제되지 않습니다. 자세한 내용은 이슈 39503을 참조하세요.

파이프라인을 삭제하면 모든 파이프라인 캐시가 만료되며, 작업, 로그, 아티팩트 및 트리거와 같은 모든 관련 객체가 삭제됩니다. 이 작업은 되돌릴 수 없습니다.

보호된 브랜치의 파이프라인 보안

보호된 브랜치에서 파이프라인을 실행할 때 엄격한 보안 모델이 적용됩니다.

특정 브랜치에 Merge 또는 푸시할 권한이 있는 사용자는 보호된 브랜치에서 다음 작업을 수행할 수 있습니다:

매뉴얼으로 파이프라인 실행 (웹 UI 또는 파이프라인 API).
예약된 파이프라인 실행.
트리거를 사용하여 파이프라인 실행.
요청에 따른 DAST 스캔 실행.
기존 파이프라인에서 매뉴얼 작업 트리거.
기존 작업을 다시 시도하거나 취소 (웹 UI 또는 파이프라인 API).

보호된 변수는 보호된 브랜치용 파이프라인에서 실행되는 작업에서 접근할 수 있습니다. 민감한 정보(배포 자격 증명 및 토큰 등)에 액세스할 수 있는 사용자에게만 보호된 브랜치에 Merge할 권한을 부여하세요.

보호된 러너(runner)는 보호된 브랜치에서만 작업을 실행할 수 있으며, 신뢰할 수 없는 코드가 보호된 러너(runner)에서 실행되는 것을 방지하여 배포 키 및 기타 자격 증명이 무심코 액세스되는 것을 방지합니다. 보호된 러너(runner)에서 실행되어야 하는 작업이 일반 러너(runner)를 사용하지 않도록 하기 위해 해당 작업은 태그로 표시되어야 합니다.

파이프라인의 보안을 보호하기 위한 추가 보안 권장 사항을 위해 배포 안전 페이지를 검토하세요.

상류 프로젝트가 다시 빌드될 때 파이프라인 트리거

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

다른 프로젝트에서 새 태그의 파이프라인이 완료될 때마다 해당 프로젝트에서 파이프라인을 트리거할 수 있습니다.

사전 요구 사항:

상류 프로젝트는 공개되어 있어야 합니다.
사용자는 상류 프로젝트에서 개발자 역할을 가져야 합니다.

상류 프로젝트가 다시 빌드될 때 파이프라인을 트리거하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > CI/CD를 선택합니다.
파이프라인 구독을 확장합니다.
프로젝트 추가를 선택합니다.
구독하려는 프로젝트를 <namespace>/<project> 형식으로 입력합니다. 예: 프로젝트가 https://gitlab.com/gitlab-org/gitlab인 경우 gitlab-org/gitlab을 사용합니다.
구독을 선택합니다.

구독 프로젝트에서 새 태그로 성공적으로 완료된 모든 파이프라인은 현재 프로젝트의 기본 브랜치에 파이프라인을 트리거하게 됩니다. 상류 및 하류 프로젝트의 최대 파이프라인 구독 수는 기본적으로 각각 2개입니다. Self-Managed 인스턴스에서는 관리자가 이 제한을 변경할 수 있습니다.

파이프라인 지속 시간 계산 방법

특정 파이프라인의 총 실행 시간은 다음을 제외합니다:

작업의 최초 실행 시간.
대기(대기열) 시간.

즉, 작업이 다시 시도되거나 매뉴얼으로 다시 실행된 경우에는 가장 최근 실행에 대한 실행 시간만 포함됩니다.

각 작업은 기간으로 표시되며, 다음과 같은 구성요소로 이루어져 있습니다.

기간#최초 (작업이 시작된 시간).
기간#마지막 (작업이 완료된 시간).

간단한 예시는 다음과 같습니다:

A (0, 2)
A’ (2, 4)
- 이것은 A를 다시 시도하는 것입니다.
B (1, 3)
C (6, 7)

위 예에서:

A는 0에서 시작하여 2에 끝납니다.
A’는 2에서 시작하여 4에 끝납니다.
B는 1에서 시작하여 3에 끝납니다.
C는 6에서 시작하여 7에 끝납니다.

시각적으로 표현하면:

0  1  2  3  4  5  6  7
AAAAAAA
   BBBBBBB
      A'A'A'A
                  CCCC

A가 다시 시도되었기 때문에 이를 무시하고 A’만 계산합니다. B, A’, C의 합집합은 (1, 4) 및 (6, 7)입니다. 따라서 총 실행 시간은 다음과 같습니다.

(4 - 1) + (7 - 6) => 4

파이프라인 보기

프로젝트에서 실행된 모든 파이프라인을 보려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
빌드 > 파이프라인 페이지를 선택합니다.

파이프라인 디렉터리을 다음으로 필터링할 수 있습니다:

트리거 작성자
브랜치 이름
상태
태그
소스

오른쪽 상단의 드롭다운 디렉터리에서 파이프라인 ID를 선택하여 파이프라인 ID(인스턴스 전체에서 고유한 ID)를 표시합니다. 파이프라인 IIDs(프로젝트 전용으로 고유한 내부 ID)를 표시하려면 파이프라인 IID를 선택하세요.

예시:

특정 Merge Request과 관련된 파이프라인을 보려면 해당 Merge Request의 파이프라인 탭으로 이동하시기 바랍니다.

파이프라인 세부 정보

GitLab 16.6에서 파이프라인 세부 정보 뷰가 업데이트되었습니다. new_pipeline_graph라는 플래그로 기능이 가능하며, 기본적으로 비활성화됩니다.
GitLab 16.8에 파이프라인 세부 정보 뷰가 GitLab.com에서 활성화되었습니다.

파이프라인을 선택하여 파이프라인 세부 정보 페이지를 열면 파이프라인의 모든 작업이 표시됩니다. 이 페이지에서 실행 중인 파이프라인을 취소하거나 실패한 작업을 다시 시도하거나, 파이프라인을 삭제할 수 있습니다.

파이프라인 세부 정보 페이지에는 파이프라인의 모든 작업을 표시하는 그래프가 표시됩니다:

특정 파이프라인의 세부 정보에 액세스하기 위해 표준 URL을 사용할 수 있습니다:

gitlab.example.com/my-group/my-project/-/pipelines/pipelines/latest: 프로젝트의 기본 브랜치에 대한 가장 최근 커밋에 대한 최신 파이프라인의 세부 정보 페이지
gitlab.example.com/my-group/my-project/-/pipelines/<branch>/latest: 프로젝트의 브랜치 <branch>에 대한 가장 최근 커밋에 대한 최신 파이프라인의 세부 정보 페이지

stage 또는 `needs` 구성별 작업 그룹화

작업을 needs 키워드로 구성할 때, 파이프라인 세부 정보 페이지에서 작업을 그룹화하는 데 두 가지 옵션이 있습니다. 작업을 stage 구성별로 그룹화하려면 작업을 그룹화 섹션에서 stage를 선택하십시오:

작업을 needs 구성별로 그룹화하려면 작업 의존성을 선택하십시오. 선택적으로 의존성 표시를 선택하여 의존하는 작업 간에 라인을 렌더링할 수 있습니다. 파이프라인 편집기의 needs 시각화와 유사합니다:

가장 왼쪽 열의 작업이 먼저 실행되며, 해당 작업에 의존하는 작업은 다음 열에 그룹화됩니다. 이 예에서:

lint-job은 needs: []로 구성되어 있고 어떤 작업에도 의존하지 않으므로, test 단계에 있음에도 불구하고 첫 번째 열에 표시됩니다.
test-job1은 build-job1에 의존하고, test-job2는 build-job1과 build-job2 둘 다에 의존하므로 두 테스트 작업이 두 번째 열에 표시됩니다.
모든 deploy 작업은 두 번째 열의 작업에 의존하며(해당 작업들 자체도 이전 작업에 의존함), 세 번째 열에 배포 작업이 표시됩니다.

작업 의존성 보기에서 작업 위로 마우스를 가져가면 선택한 작업 이전에 실행되어야 하는 모든 작업이 강조 표시됩니다:

파이프라인 미니 그래프

GitLab 14.5에서 파이프라인 편집기의 파이프라인 미니 그래프가 도입되었습니다.

파이프라인 미니 그래프는 적은 공간을 차지하며 한눈에 모든 작업이 통과되었는지 또는 실패한 것이 있는지 알 수 있습니다. 단일 커밋에 대한 모든 관련 작업을 보여주며 파이프라인의 각 단계의 최종 결과를 보여줍니다. 실패한 항목을 빠르게 확인하고 수정할 수 있습니다.

파이프라인 미니 그래프는 항상 stage별로 작업을 그룹화하며, 파이프라인 또는 커밋 세부 정보를 표시하는 경우에는 항상 표시됩니다.

파이프라인 미니 그래프의 스테이지는 확장할 수 있습니다. 각 스테이지 위로 마우스를 가져가면 이름과 상태가 표시되며, 스테이지를 선택하여 해당 작업 디렉터리을 확장할 수 있습니다.

하향식 파이프라인 그래프

파이프라인에 하향식 파이프라인을 트리거하는 작업이 포함된 경우, 파이프라인 세부 정보 뷰 및 미니 그래프에서 해당 하향식 파이프라인을 볼 수 있습니다.

파이프라인 세부 정보 뷰에서는 파이프라인 그래프 오른쪽에 트리거된 각 하향식 파이프라인에 대한 카드가 표시됩니다. 카드 위로 마우스를 가져가면 어떤 작업이 하향식 파이프라인을 트리거했는지 볼 수 있습니다. 카드를 선택하여 파이프라인 그래프 오른쪽에 하향식 파이프라인을 표시할 수 있습니다.

파이프라인 미니 그래프에서는 트리거된 각 하향식 파이프라인의 상태가 미니 그래프 오른쪽에 추가 상태 아이콘으로 표시됩니다. 하향식 파이프라인의 상태 아이콘을 선택하여 해당 하향식 파이프라인의 세부 페이지로 이동할 수 있습니다.

파이프라인 성공 및 기간 차트

파이프라인 분석은 CI/CD Analytics 페이지에서 사용할 수 있습니다.

파이프라인 배지

각 프로젝트에는 파이프라인 상태 및 테스트 커버리지 보고서 배지가 사용 가능하며 구성 가능합니다. 프로젝트에 파이프라인 배지를 추가하는 방법에 대한 자세한 내용은 파이프라인 배지를 참조하십시오.

파이프라인 API

GitLab은 다음을 수행하기 위한 API 엔드포인트를 제공합니다:

기본 기능 수행. 자세한 정보는 파이프라인 API를 참조하십시오.
파이프라인 스케줄 유지관리. 자세한 내용은 파이프라인 스케줄 API를 참조하십시오.
파이프라인 실행 트리거. 자세한 내용은 다음을 참조하십시오:
- API를 통한 파이프라인 트리거.
- 파이프라인 트리거 API.

러너용 Ref 스펙

러너가 파이프라인 작업을 선택하면 GitLab은 해당 작업의 메타데이터를 제공합니다. 이에는 당신의 프로젝트 리포지터리에서 체크아웃되는 ref(브랜치 또는 태그와 같은)와 커밋(SHA1)을 나타내는 Git refspecs가 포함됩니다.

다음 표는 각 파이프라인 유형에 대해 주입된 refspecs를 나열합니다:

파이프라인 유형	Refspecs
브랜치용 파이프라인	`+<sha>:refs/pipelines/<id>` 및 `+refs/heads/<name>:refs/remotes/origin/<name>`
태그용 파이프라인	`+<sha>:refs/pipelines/<id>` 및 `+refs/tags/<name>:refs/tags/<name>`
Merge Request 파이프라인	`+refs/pipelines/<id>:refs/pipelines/<id>`

refs/heads/<name> 및 refs/tags/<name>은 프로젝트 리포지터리에 존재합니다. GitLab은 실행 중인 파이프라인 작업에서 refs/pipelines/<id>라는 특수 ref를 생성합니다. 이 ref는 관련 브랜치 또는 태그가 삭제된 후에도 생성될 수 있습니다. 따라서 환경 자동 중지 및 Merge Train과 같은 일부 기능에서 유용합니다.

CI/CD 파이프라인

파이프라인 유형

파이프라인 구성

파이프라인 매뉴얼 실행

양식에 미리 입력된 변수 입력

선택 가능한 미리 설정된 변수 값 디렉터리 구성

URL 쿼리 문자열을 사용하여 파이프라인 실행

파이프라인에 매뉴얼 상호 작용 추가

스테이지의 모든 매뉴얼 작업 시작

파이프라인 건너뛰기

파이프라인 삭제

보호된 브랜치의 파이프라인 보안

상류 프로젝트가 다시 빌드될 때 파이프라인 트리거

파이프라인 지속 시간 계산 방법

파이프라인 보기

파이프라인 세부 정보

stage 또는 `needs` 구성별 작업 그룹화

파이프라인 미니 그래프

하향식 파이프라인 그래프

파이프라인 성공 및 기간 차트

파이프라인 배지

파이프라인 API

러너용 Ref 스펙

도움말

기능 사용 가능성과 제품 평가판

도움받기

CI/CD 파이프라인

파이프라인 유형

파이프라인 구성

파이프라인 매뉴얼 실행

양식에 미리 입력된 변수 입력

선택 가능한 미리 설정된 변수 값 디렉터리 구성

URL 쿼리 문자열을 사용하여 파이프라인 실행

파이프라인에 매뉴얼 상호 작용 추가

스테이지의 모든 매뉴얼 작업 시작

파이프라인 건너뛰기

파이프라인 삭제

보호된 브랜치의 파이프라인 보안

상류 프로젝트가 다시 빌드될 때 파이프라인 트리거

파이프라인 지속 시간 계산 방법

파이프라인 보기

파이프라인 세부 정보

stage 또는 needs 구성별 작업 그룹화

파이프라인 미니 그래프

하향식 파이프라인 그래프

파이프라인 성공 및 기간 차트

파이프라인 배지

파이프라인 API

러너용 Ref 스펙

도움말

기능 사용 가능성과 제품 평가판

도움받기

stage 또는 `needs` 구성별 작업 그룹화