CI/CD Pipelines

파이프라인은 지속적 통합, 제공 및 배포의 최상위 구성 요소입니다.

파이프라인은 다음으로 구성됩니다.

수행할 Job을 정의하는 jobs. 예를 들어, 코드를 컴파일하거나 테스트하는 작업.
Job을 실행할 시기를 정의하는 Stages. 예를 들어, 코드를 컴파일하는 단계 후에 테스트를 실행하는 단계.

Job은 러너(Runner)에 의해 실행됩니다. 동시(concurrent) 러너가 충분하면, 동일한 단계의 여러 job이 병렬로 실행됩니다.

한 단계의 모든 job이 성공하면, 파이프라인은 다음 단계로 넘어갑니다.

한 단계의 어떤 job이 실패하면, 다음 단계는 (일반적으로) 실행되지 않고 파이프라인이 일찍 종료됩니다.

일반적으로 파이프라인은 자동으로 실행되며 생성된 후에는 개입이 필요하지 않습니다. 그러나 수동으로 파이프라인과 상호 작용할 수 있는 예도 있습니다.

일반적인 파이프라인은 다음 순서로 실행되는 네 개의 단계로 구성될 수 있습니다.

compile이라는 job이 있는 build 단계
test1 및 test2라는 두 개의 job이 있는 test 단계
deploy-to-stage라는 job이 있는 staging 단계
deploy-to-prod라는 job이 있는 production 단계

참고

GitLab이 가져오는 미러 리포지터리가 있다면, 프로젝트의 Settings > Repository > Mirroring repositories > Trigger pipelines for mirror updates 에서 파이프라인 트리거를 활성화해야 합니다.

파이프라인 유형

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

기본 파이프라인은 각 스테이지의 모든 job을 동시에 실행하고, 다음 스테이지로 넘어갑니다.
Directed Acyclic Graph(DAG) 파이프라인은 job 간의 관계에 기반하며, 기본 파이프라인보다 더 빨리 실행될 수 있습니다.
Merge Request 파이프라인은 Merge Request에만 실행됩니다(모든 커밋이 아닌).
Merge 결과 파이프라인은 소스 브랜치의 변경 사항이 타깃 브랜치로 이미 merge 된 것처럼 동작하는 Merge Request 파이프라인입니다.
Merge Train은 merge 결과 파이프라인을 사용해 merge를 차례로 대기열에 넣습니다.
상하위 파이프라인은 복잡한 파이프라인을 하나의 상위 파이프라인으로 분류해 여러 하위 서브 파이프라인을 트리거할 수 있습니다. 이는 동일한 프로젝트에서, 동일한 SHA로 모두 실행됩니다. 파이프라인 아키텍처는 보통 모노레포(mono-repos)에 사용됩니다.
멀티 프로젝트 파이프라인은 다양한 프로젝트의 파이프라인을 함께 결합합니다.

파이프라인 구성하기

파이프라인과 그 구성 요소인 job, 스테이지는 각 프로젝트의 CI/CD 파이프라인 구성 파일에 정의됩니다.

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

CI 파이프라인 파일의 구성 옵션 목록을 보려면 GitLab CI/CD 파이프라인 구성 레퍼런스를 확인하세요.

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

러너 위한 ref 사양

러너가 파이프라인 job을 선택할 때, GitLab은 해당 job의 메타데이터를 제공합니다. 이는 프로젝트 리포지터리에서 체크아웃한 ref(예: 브랜치 또는 태그)와 커밋(SHA1)을 나타내는 Git refspec을 포함합니다.

이 표는 각 파이프라인 유형에 적용한 refspec을 정리했습니다.

파이프라인 유형	Refspec
브랜치의 파이프라인	`+<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>`

ref refs/heads/<name>과 refs/tags/<name>은 프로젝트 리포지터리에 있습니다. GitLab은 파이프라인 job을 실행하는 동안 특수 ref refs/pipelines/<id>를 생성합니다. 이 ref는 관련 브랜치 또는 태그가 지워진 뒤에도 생성될 수 있습니다. 따라서 이는 자동으로 환경을 중지하기, 브랜치 삭제 후 파이프라인을 실행할 수 있는 merge train과 같은 일부 기능에 유용할 수 있습니다.

파이프라인 보기

프로젝트의 Build > Pipelines 페이지에서 현재 및 이전 파이프라인 실행을 찾을 수 있습니다. 또한, Merge Request의 Pipelines 탭으로 이동하여 파이프라인에 액세스할 수도 있습니다.

파이프라인을 클릭하여 Pipeline Details 페이지를 열고 해당 파이프라인에 대해 실행된 job을 표시합니다. 여기에서 실행 중인 파이프라인을 취소하거나 실패한 파이프라인에서 job을 다시 시도하거나 파이프라인을 삭제할 수 있습니다.

특정 브랜치의 마지막 커밋에 대한 최신 파이프라인의 링크는 /project/-/pipelines/[branch]/latest에서 사용할 수 있습니다. 또한 /project/-/pipelines/latest는 프로젝트의 기본 브랜치에 대한 마지막 커밋의 최신 파이프라인으로 리디렉션합니다.

GitLab 13.0부터 다음을 기준으로 파이프라인 목록을 필터링할 수 있습니다.

트리거 작성자
브랜치 이름
상태 (GitLab 13.1 이상)
태그 (GitLab 13.1 이상)
소스 (GitLab 14.3 이상)

GitLab 14.2부터 파이프라인 칼럼을 변경해 파이프라인 ID 또는 파이프라인 IID를 표시할 수 있습니다.

VS Code를 사용해 GitLab CI/CD 구성을 편집하면, GitLab Workflow VS Code extension으로 구성을 승인하고, 파이프라인 상태를 볼 수 있습니다.

수동으로 파이프라인 실행

파이프라인은 사전 정의되거나 수동으로 지정된 변수를 사용하여 수동으로 실행할 수 있습니다.

파이프라인의 정상적인 작동 범위 외부에서 파이프라인의 결과(예 : 코드 빌드)가 필요한 경우 이 작업을 수행할 수 있습니다.

파이프라인을 수동으로 실행하려면 :

왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
Build > Pipelines 버튼을 클릭합니다.
Run Pipeline 버튼을 클릭합니다.
Run for branch name or tag 필드에서 파이프라인을 실행할 브랜치나 태그를 선택합니다.
파이프라인 실행에 필요한 CI/CD 변수를 입력합니다. 특정 변수를 설정해 해당 값이 양식에 미리 채워지도록 할 수 있습니다.
Run Pipeline 버튼을 클릭합니다.

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

수동 파이프라인에서 변수 미리 채우기

이 기능은 GitLab 13.7부터 도입됐습니다.

description과 value를 사용해 파이프라인을 수동으로 실행할 때 미리 채워지는 파이프라인 수준(전역) 변수를 정의할 수 있습니다. description을 사용해 변수를 사용하는 용도, 허용되는 값과 같은 정보를 설명합니다.

Job 수준 변수는 미리 채울 수 없습니다.

수동으로 트리거한 파이프라인에서, Run pipeline 페이지는 .gitlab-ci.yml 파일에 정의된 description이 있는 파이프라인 수준 변수를 모두 표시합니다. description은 변수 아래에 표시됩니다.

미리 채워진 값을 변경해 해당 단일 파이프라인 실행의 값을 재정의합니다. 이 프로세스를 사용해 재정의된 모든 변수는 확장되며, 마스킹 되지 않습니다. 구성 파일에서 변수의 value를 정의하지 않으면, 변수 이름은 여전히 나열되지만 값 필드는 비어 있습니다.

예를 들어,

variables:
  DEPLOY_CREDENTIALS:
    description: 'The deployment credentials.'
  DEPLOY_ENVIRONMENT:
    description: "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice."
    value: 'canary'

이 예에서

DEPLOY_CREDENTIAL은 Run pipeline 페이지에 나열되지만 값은 설정되지 않습니다. 사용자는 파이프라인을 수동으로 실행할 때마다 값을 정의합니다.
DEPLOY_ENVIRONMENT는 Run pipeline 페이지에 기본값인 canary로 미리 채워지고, 메시지는 다른 옵션을 설명합니다.

참고

알려진 문제 때문에, 컴플라이언스 파이프라인을 사용하는 프로젝트에 파이프라인을 수동으로 실행할 때 미리 채워진 변수가 나타나지 않을 수 있습니다. 이 문제를 해결하려면, 컴플라이언스 파이프라인 구성을 변경하세요.

선택할 수 있는 미리 채워진 변숫값 목록 구성하기

이 기능은 run_pipeline_graphql이라는 플래그와 함께 GitLab 15.5부터 도입됐습니다. 이는 기본으로 비활성화됐습니다.
option 키워드는 GitLab 15.7부터 도입됐습니다.
이 기능은 GitLab 15.7부터 일반적으로 이용할 수 있습니다. 피처 플래그 run_pipeline_graphql은 제거됐습니다.
변수 목록은 버그 때문에 제대로 채워지지 않았지만 이 문제는 GitLab 15.9부터 해결됐습니다.

파이프라인을 수동으로 실행할 때, 사용자가 선택하는 CI/CD 변숫값 배열을 정의할 수 있습니다. 이러한 값은 Run pipeline 페이지의 드롭다운 목록에 있습니다. 값 옵션 목록을 option에 추가하고, value로 기본값을 설정합니다. value의 문자열은 option 목록에 포함돼야 합니다.

예를 들면 아래와 같습니다.

variables:
  DEPLOY_ENVIRONMENT:
    value: 'staging'
    options:
      - 'production'
      - 'staging'
      - 'canary'
    description: "The deployment target. Set to 'staging' by default."

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

이 기능은 GitLab 12.5부터 도입됐습니다.

쿼리 문자열을 사용하여 Run Pipeline 페이지를 미리 채울 수 있습니다. 예를 들어, 쿼리 문자열 .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar은 다음으로 Run Pipeline 페이지를 미리 채웁니다.

Run for 필드 : my_branch
Variables 섹션 :
- Variable :
  - Key : foo
  - Value : bar
- File :
  - Key : file_foo
  - Value : file_bar

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

.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>

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

ref : Run for 필드를 채울 브랜치 지정
var : Variable 변수 지정
file_var : File 변수 지정

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

파이프라인에 수동 상호작용 추가

수동 job(Manual jobs)을 사용하면 파이프라인에서 진행하기 전에 수동 상호작용을 요구할 수 있습니다.

파이프라인 그래프에서 바로 이 작업을 수행할 수 있습니다. 특정 job을 실행하려면 재생 버튼을 클릭하기만 하면 됩니다.

예를 들어, 파이프라인이 자동으로 시작될 수 있지만, 프로덕션에 배포하려면 수동 작업이 필요합니다. 아래 예에서, production 스테이지에는 수동 작업이 있는 job이 있습니다.

한 스테이지에서 여러 수동 작업 시작

이 기능은 GitLab 11.11부터 도입됐습니다.

"Play all manual" 버튼을 사용하여 단일 스테이지에서 여러 수동 작업을 동시에 시작할 수 있습니다. 이 버튼을 클릭하면 개별 수동 작업이 트리거 되고 업데이트된 상태로 새로 고쳐집니다.

이 기능은 다음에서만 사용할 수 있습니다.

최소한 Developer 권한이 있는 사용자의 경우
스테이지에 수동 작업이 포함된 경우

파이프라인 건너뛰기

파이프라인을 트리거하지 않고 커밋을 푸시하려면, 대문자를 사용하여 [ci skip] 또는 [skip ci]를 커밋 메시지에 추가합니다.

Git 2.10 이상을 사용하고 있다면, ci.skip Git 푸시 옵션을 사용합니다. ci.skip 푸시 옵션은 Merge Request 파이프라인을 건너뛰지 않습니다.

파이프라인 삭제

이 기능은 GitLab 12.7부터 도입됐습니다.

프로젝트에서 Owner 권한이 있는 사용자는 Build > Pipelines에서 파이프라인을 클릭하여 Pipeline Details 페이지로 이동한 다음, Delete 버튼을 사용하여 파이프라인을 삭제할 수 있습니다.

파이프라인을 삭제해도 하위 파이프라인은 자동 삭제되지 않습니다. 관련 이슈에서 세부 사항을 확인하세요.

주의

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

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

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

사용자가 해당 특정 브랜치에 merge 또는 푸시할 수 있을 때만 보호된 브랜치에서 다음 작업이 허용됩니다.

수동 파이프라인 실행 (웹 UI 또는 파이프라인 API 사용)
예약된 파이프라인 실행
트리거를 사용하여 파이프라인 실행
On-demand DAST 스캔 실행
기존 파이프라인에서 수동 작업 트리거
기존 job 재시도 또는 취소 (웹 UI 또는 파이프라인 API 사용)

**보호됨(protected)**으로 표시된 변수는 보호된 브랜치의 파이프라인에서 실행되는 job에 액세스할 수 있습니다. 배포 자격 증명과 토큰 같은 중요한 정보에 액세스할 권한이 있을 때만 사용자에게 보호된 브랜치에 merge 할 권한을 할당합니다.

**보호됨(protected)**으로 표시된 러너는 보호된 브랜치에서만 job을 실행할 수 있으므로, 신뢰할 수 없는 코드가 보호된 러너에서 실행되는 것을 방지하고 배포 키와 다른 자격 증명이 실수로 액세스 되지 않도록 보호할 수 있습니다. 보호된 러너에서 실행되도록 의도된 job이 일반 러너를 사용하지 않도록 하려면 그에 따라 태그를 지정해야 합니다.

배포 안전 페이지에서 파이프라인 보안을 위한 추가 보안 권장 사항을 검토하세요.

업스트림 프로젝트를 다시 빌드할 때 파이프라인 트리거하기

이 기능은 GitLab 12.8부터 도입됐습니다.

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

전제 조건:

업스트림 프로젝트는 공개돼야 합니다.
사용자는 업스트림 프로젝트에서 Developer 권한이 있어야 합니다.

업스트림 프로젝트를 다시 빌드할 때, 파이프라인을 트리거하려면

왼쪽 사이드바에서, Search or go to를 클릭하고, 프로젝트를 찾습니다.
Settings > CI/CD 버튼을 클릭합니다.
Pipeline subscriptions에서 Expand 버튼을 클릭합니다.
Add project 버튼을 클릭합니다.
구독하려는 프로젝트를 <namespace>/<project> 형식으로 입력합니다. 예를 들어, 프로젝트가 https://gitlab.com/gitlab-org/gitlab이면, gitlab-org/gitlab을 사용합니다.
Subscribe 버튼을 클릭합니다.

구독한 프로젝트에서 새로운 태그에 대해 성공적으로 완료한 모든 파이프라인은 이제 현재 프로젝트의 기본 브랜치에서 파이프라인을 트리거합니다. 업스트림 파이프라인 구독의 최대 개수는 업스트림과 다운스트림 프로젝트 모두에 대해 기본 2개입니다. 자체 관리형 인스턴스에서 관리자는 이 제한을 변경할 수 있습니다.

파이프라인 기간 계산 방법

주어진 파이프라인의 총 실행 시간은 재시도 및 보류(대기) 시간을 제외합니다.

각 job은 Period로 표시되며 다음으로 구성됩니다.

Period#first (Job이 시작되었을 때)
Period#last (Job이 끝났을 때)

간단한 예는 다음과 같습니다.

A (1, 3)
B (2, 4)
C (6, 7)

예에서 :

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

시각적으로 다음과 같이 볼 수 있습니다.

0     1      2     3     4      5      6      7
       AAAAAAA
               BBBBBBB
                                               CCCC

A, B, C의 합집합은 (1, 4)와 (6, 7)입니다. 따라서 총 실행 시간은 다음과 같습니다.

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

파이프라인 시각화하기

파이프라인은 많은 순차적 job과 병렬 job으로 복잡한 구조일 수 있습니다. 파이프라인 흐름을 더 쉽게 이해하도록, GitLab에는 파이프라인과 그 상태를 볼 수 있는 파이프라인 그래프가 있습니다. 파이프라인 그래프는 사용자가 그래프에 액세스하는 페이지에 따라 큰 그래프 또는 작은 그래프로 표시됩니다. GitLab은 파이프라인 그래프에서 스테이지 이름을 대문자로 표시합니다.

전체 파이프라인 그래프 보기

시각화 개선은 GitLab 13.11부터 도입됐습니다.

파이프라인 상세 페이지는 파이프라인에서 모든 job의 전체 파이프라인 그래프를 표시합니다. job을 다음과 같이 분류할 수 있습니다.

Stage: 같은 스테이지에 있는 job을 같은 칼럼에 함께 정렬합니다.

Job dependencies(Job 의존성): needs 의존성에 기반해 job을 정렬합니다.

멀티 프로젝트 파이프라인 그래프는 모든 프로젝트 간 상호의존성을 포함해 전체 파이프라인을 시각화하도록 지원합니다.

스테이지가 100개 이상 job을 포함하면, 처음 100개 job만 파이프라인 그래프에 나타납니다. 나머지 job은 평소처럼 계속 실행됩니다. Job을 보려면 이렇게 하세요.

파이프라인을 선택하면 job이 파이프라인 상세 페이지의 오른편에 나타납니다.
왼쪽 사이드바에서, Build > Jobs 버튼을 클릭합니다.

파이프라인 그래프에서 job 의존성 보기

이 기능은 GitLab 13.12부터 도입됐습니다.
이 기능은 GitLab 14.0부터 기본으로 활성화됐습니다.
피처 플래그는 GitLab 14.2부터 제거됐습니다.

needs 의존성에 기반해 파이프라인 그래프에서 job을 정렬하려면, Group jobs by 섹션에서 Job dependencies를 선택합니다. 이 옵션은 needs job 의존성이 있는 3개 이상의 job이 있는 파이프라인에서 사용할 수 있습니다.

가장 왼쪽 칼럼에 있는 job이 먼저 실행되고, 이 job에 의존하는 job은 다음 칼럼에 분류됩니다.

예를 들어, test-job1은 첫번째 칼럼의 job에만 의존합니다. 따라서 이는 왼쪽에서 두번째 칼럼에 표시됩니다. deploy-job1은 첫번째 칼럼과 두번째 칼럼 모두의 job에 의존하며, 세번째 칼럼에 표시됩니다.

Job 간에 needs 관계를 보여주는 선을 추가하려면, Show dependencies 토글을 활성화합니다. 이러한 선은 needs 시각화와 비슷합니다.

Job의 전체 needs 의존성 트리를 보려면, job 위로 마우스를 가져갑니다.

파이프라인 미니 그래프

파이프라인 미니 그래프는 공간을 덜 차지하고, 모든 job이 통과했는지 또는 어떤 job이 실패했는지 한 눈에 확인할 수 있습니다. 파이프라인 미니 그래프는 다음 페이지로 이동하면 볼 수 있습니다.

파이프라인 인덱스 페이지
싱글 커밋 페이지
Merge Request 페이지
GitLab 14.5 이상의 파이프라인 에디터

파이프라인 미니 그래프는 단일 커밋의 모든 관련 job과 파이프라인의 각 스테이지 최종 결과를 보도록 지원합니다. 이는 무엇이 실패했는지 빠르게 확인하고, 이를 고치도록 돕습니다.

파이프라인 미니 그래프는 스테이지별로 job을 표시합니다.

파이프라인 미니 그래프의 스테이지는 펼쳐 볼 수 있습니다. 각 스테이지에 마우스를 가져가면 이름과 상태를 볼 수 있고, 스테이지를 선택하면 job 목록이 펼쳐집니다.

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

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

파이프라인 배지

파이프라인 상태와 테스트 커버리지 보고서 배지를 사용할 수 있고, 각 프로젝트에 구성할 수 있습니다. 프로젝트에 파이프라인 배지를 추가하는 방법은 파이프라인 배지에서 확인하세요.

파이프라인 API

GitLab은 다음을 위한 API 엔드포인트를 제공합니다.

기본 기능 수행. 자세한 정보는 파이프라인 API를 확인하세요.
파이프라인 일정 유지 관리. 자세한 정보는 파이프라인 일정 API를 확인하세요.
파이프라인 실행 트리거. 자세한 정보는 아래에서 확인할 수 있습니다.
- API를 통해 파이프라인 트리거
- 파이프라인 트리거 API

GitLab 원문 보기

파이프라인 유형​

파이프라인 구성하기​

러너 위한 ref 사양​

파이프라인 보기​

수동으로 파이프라인 실행​

수동 파이프라인에서 변수 미리 채우기​

선택할 수 있는 미리 채워진 변숫값 목록 구성하기​

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

파이프라인에 수동 상호작용 추가​

한 스테이지에서 여러 수동 작업 시작​

파이프라인 건너뛰기​

파이프라인 삭제​

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

업스트림 프로젝트를 다시 빌드할 때 파이프라인 트리거하기​

파이프라인 기간 계산 방법​

파이프라인 시각화하기​

전체 파이프라인 그래프 보기​

파이프라인 그래프에서 job 의존성 보기​

파이프라인 미니 그래프​

파이프라인 성공과 기간 차트​

파이프라인 배지​

파이프라인 API​