CI/CD 파이프라인

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

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

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

  • 무엇을 할 지 정의하는 작업(job). 예를 들어 코드를 컴파일하거나 테스트하는 작업들.
  • 언제 작업을 실행할 지를 정의하는 단계(stage). 예를 들어 코드를 컴파일하는 단계 다음에 테스트를 실행하는 단계들.

작업은 runners에 의해 실행됩니다. 동시에 실행 가능한 runner가 충분하다면 동일 단계에 있는 여러 작업이 병렬로 실행됩니다.

한 단계의 모든 작업이 성공하면 파이프라인은 다음 단계로 이동합니다.

한 단계의 어떠한 작업이라도 실패하면 다음 단계가 (보통) 실행되지 않고 파이프라인이 일찍 종료됩니다.

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

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

  • 작업이 compile인 build 단계
  • test1과 test2라는 두 작업이 있는 test 단계
  • 작업이 deploy-to-stage인 staging 단계
  • 작업이 deploy-to-prod인 production 단계
note
만약 GitLab에서 풀(pull)한 대상 리포지토리가 있다면 프로젝트의 Settings > Repository > Mirroring repositories > Trigger pipelines for mirror updates에서 파이프라인 트리거를 활성화해야 할 수도 있습니다.

파이프라인 유형

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

파이프라인 구성

파이프라인 및 구성된 작업 및 단계는 각 프로젝트의 CI/CD 파이프라인 구성 파일에 정의됩니다.

  • 작업들은 기본 구성 구성 요소입니다.
  • 단계는 stages 키워드를 사용하여 정의됩니다.

CI/CD 구성 파일의 구성 옵션 목록은 CI/CD YAML 구문 참조를 참조하십시오.

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

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

GitLab CI/CD 구성을 편집할 때 VS Code를 사용하는 경우 GitLab Workflow extension for VS Code를 사용하면 구성을 유효성 검사하고 파이프라인 상태를 확인할 수 있습니다.

파이프라인 수동 실행

파이프라인은 사전 정의된 또는 수동으로 지정된 변수와 함께 수동으로 실행할 수 있습니다.

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

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

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

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

양식에 미리 채워진 변수

description 및 value 키워드를 사용하여 수동으로 실행된 파이프라인에서 미리 입력된(글로벌) 변수를 정의할 수 있습니다. description을 사용하여 변수의 용도 및 허용 가능한 값 등을 설명할 수 있습니다.

작업 수준 변수는 미리 입력할 수 없습니다.

수동으로 트리거된 파이프라인에서는 새 파이프라인 페이지에서 .gitlab-ci.yml 파일에 정의된 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_CREDENTIALS은 새 파이프라인 페이지에 표시되지만 값이 설정되지 않습니다. 사용자는 파이프라인 실행 시마다 값을 정의해야 합니다.
  • DEPLOY_ENVIRONMENT은 새 파이프라인 페이지에 canary로 미리 입력되며, 다른 옵션에 대한 설명이 표시됩니다.

참고: 알려진 문제로 컴플라이언스 파이프라인을 사용하는 프로젝트는 수동으로 파이프라인을 실행할 때 미리 입력된 변수가 나타나지 않을 수 있습니다. 이 문제를 해결하기 위해 컴플라이언스 파이프라인 구성을 변경해야 할 수 있습니다.

선택 가능한 미리 입력된 변수 값 목록 구성

수동으로 파이프라인을 실행할 때 사용자가 선택할 수 있는 CI/CD 변수 값 배열을 정의할 수 있습니다. 이 값은 새 파이프라인 페이지에서 드롭다운 목록으로 제공됩니다. options에 값을 추가하고 value로 기본값을 설정합니다. value의 문자열은 options 목록에도 포함되어야 합니다.

예시: 

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

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

쿼리 문자열을 사용하여 새 파이프라인 페이지를 미리 채울 수 있습니다. 예를 들어, 쿼리 문자열 .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar 는 다음과 같이 새 파이프라인 페이지를 미리 채웁니다.

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

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

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

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

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

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

파이프라인에 수동 작업 추가

수동 작업을 사용하면 파이프라인에서 진행하기 전에 수동 상호 작용을 요청할 수 있습니다.

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

예를 들어, 파이프라인은 자동으로 시작할 수 있지만 수동 작업이 필요합니다. 아래 예시에서 production 단계에는 수동 작업이 있는 작업이 있습니다:

파이프라인 예시

단계 내 모든 수동 작업 시작

단계에 수동 작업만 포함되어 있다면 해당 단계 위에 있는 모두 수동 실행 ()을 선택하여 모든 작업을 동시에 실행할 수 있습니다. 단계에 수동 작업 이외의 작업이 포함되어 있다면 이 옵션이 표시되지 않습니다.

파이프라인 건너뛰기

파이프라인을 트리거하지 않고 커밋을 푸시하려면 [ci skip] 또는 [skip ci]를 커밋 메시지에 추가하세요. 대소문자를 구분하지 않습니다.

또는 Git 2.10 이상 버전을 사용하면 ci.skip Git push 옵션을 사용하세요. ci.skip 푸시 옵션은 병합 요청 파이프라인을 건너뛰지 않습니다.

파이프라인 삭제

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

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

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

경고: 파이프라인 삭제는 모든 파이프라인 캐시를 만료시키고, 작업, 로그, 아티팩트, 및 트리거와 같은 즉시 관련된 객체를 모두 삭제합니다. 이 동작은 되돌릴 수 없습니다.

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

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

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

  • 수동 파이프라인 실행(웹 UI 및 파이프라인 API).
  • 예약된 파이프라인 실행.
  • 트리거 사용하여 파이프라인 실행.
  • 온디맨드 DAST 스캔 실행.
  • 기존 파이프라인에 대해 수동 작업 트리거.
  • 기존 작업 다시 시도 또는 취소(웹 UI 또는 파이프라인 API 사용).

보호된 변수는 보호된 브랜치의 파이프라인에서 실행되는 작업에서 접근할 수 있습니다. 보호된 브랜치에 병합 권한을 부여한 사용자는 배포 자격 증명 및 토큰과 같은 민감한 정보에 액세스할 수 있는 권한이 있으므로 주의해야 합니다.

보호된 Runner는 보호된 브랜치에서만 작업을 실행할 수 있으며, 신뢰할 수 없는 코드가 보호된 Runner에서 실행되거나 배포 키와 같은 자격 증명이 무심코 액세스되는 것을 방지합니다. 보호된 Runner에서 실행할 작업이 일반 Runner를 사용하지 않도록하려면 태그를 지정해야 합니다.

파이프라인 보안을 확보하는 추가 권장사항은 배포 안전성 페이지를 참조하세요.

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

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

다른 프로젝트의 태그를 기반으로 파이프라인을 자동으로 트리거할 수 있도록 프로젝트를 설정할 수 있습니다. 구독된 프로젝트에서 새 태그 파이프라인이 완료되면 해당 태그 파이프라인이 성공, 실패 또는 취소되었든지 상관없이 프로젝트의 기본 브랜치에 파이프라인을 트리거합니다.

사전 준비 조건:

  • 상위 프로젝트는 public해야 합니다.
  • 사용자는 상위 프로젝트에서 Developer 역할을 가져야 합니다.

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

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

상위 및 하위 프로젝트의 최대 파이프라인 구독 수는 기본적으로 2개입니다. 자체 관리되는 인스턴스에서는 관리자가 이 제한을 변경할 수 있습니다.

파이프라인 소요 시간 계산 방법

주어진 파이프라인의 총 실행 시간에는 다음이 포함되지 않습니다.

  • 재시도되거나 수동으로 다시 실행된 작업의 초기 실행 소요 시간.
  • 보류 중인 (대기열) 시간.

이는 작업이 재시도되거나 수동으로 다시 실행되면 최신 실행의 소요 시간만이 총 실행 시간에 포함된다는 것을 의미합니다.

각 작업은 Period로 표현되며 다음으로 구성됩니다.

  • Period#first (작업이 시작된 시간).
  • Period#last (작업이 완료된 시간).

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

  • 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

파이프라인 보기

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

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

파이프라인 페이지를 다음으로 필터링할 수 있습니다:

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

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

예를들어:

파이프라인 목록 페이지

특정 병합 요청과 관련된 파이프라인을 보려면 병합 요청의 파이프라인 탭으로 이동하세요.

파이프라인 세부 정보

  • 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를 선택하세요:

stage에 따라 그룹화된 작업

needs 구성에 따라 작업을 그룹화하려면 작업 종속성을 선택하세요. 작업 간의 의존성을 보려면 의존성 표시를 선택할 수 있습니다.

작업 종속성에 따라 그룹화된 작업

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

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

작업 종속성 보기에서 작업 위로 마우스를 올리면 선택한 작업 앞에 실행되어야 하는 모든 작업이 강조 표시됩니다:

hover시 파이프라인 종속성 보기

파이프라인 미니 그래프

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

파이프라인 미니 그래프는 항상 작업을 단계별로 그룹화하고 파이프라인 또는 커밋 세부 정보를 표시할 때 GitLab 전체에서 표시됩니다.

파이프라인 미니 그래프

파이프라인 미니 그래프에서 단계는 확장 가능합니다. 각 단계 위에 마우스를 올려 이름과 상태를 보고 해당 단계를 선택하여 작업 목록을 확장할 수 있습니다.

하류 파이프라인 그래프

파이프라인에 하류 파이프라인을 트리거하는 작업이 포함되어 있는 경우 파이프라인 세부 정보 보기와 미니 그래프에서 하류 파이프라인을 볼 수 있습니다.

파이프라인 세부 정보 보기에서 파이프라인 그래프 오른쪽에 각각 트리거된 하류 파이프라인에 대한 카드가 표시됩니다. 하류 파이프라인을 호버하면 어떤 작업이 해당 하류 파이프라인을 트리거했는지 볼 수 있습니다. 하류 파이프라인을 선택하면 파이프라인 그래프 오른쪽에 하류 파이프라인이 표시됩니다.

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

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

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

파이프라인 뱃지

파이프라인 상태 및 테스트 커버리지 보고서 뱃지는 각 프로젝트에 대해 사용 가능하며 구성할 수 있습니다. 프로젝트에 파이프라인 뱃지를 추가하는 방법에 대한 정보는 파이프라인 뱃지를 참조하십시오.

파이프라인 API

GitLab은 다음을 위한 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>
병합 요청 파이프라인 +refs/pipelines/<id>:refs/pipelines/<id>

참조 refs/heads/<name> 및 refs/tags/<name>은 프로젝트 저장소에 존재합니다. GitLab은 실행 중인 파이프라인 작업 중에 특별한 참조 refs/pipelines/<id>을 생성합니다. 이 참조는 해당 브랜치 또는 태그가 삭제된 후에도 생성될 수 있습니다. 따라서 환경 자동 중지와 병합 트레인과 같은 기능에서 유용합니다.