• 파이프라인의 종류
• 파이프라인 구성
  • 파이프라인을 수동으로 실행하기
    • 수동 파이프라인에서 변수 미리 채우기
    • 선택 가능한 미리 채워진 변수 값 목록 구성하기
  • URL 쿼리 문자열을 사용하여 파이프라인 실행
  • 파이프라인에 수동 상호작용 추가
    • 단계 내 모든 수동 작업 시작
  • 파이프라인 건너뛰기
  • 파이프라인 삭제
  • 보호된 브랜치에서의 파이프라인 보안
• 파이프라인을 트리거하여 업스트림 프로젝트를 재구축할 때
• 파이프라인 소요 시간 계산 방법
• 파이프라인 보기
  • 파이프라인 세부정보
    • 단계 또는 needs 구성으로 작업 그룹화
  • 파이프라인 미니 그래프
  • 다운스트림 파이프라인 그래프
• 파이프라인 성공 및 지속 시간 차트
• 파이프라인 배지
• 파이프라인 API
• 러너를 위한 ref 사양

CI/CD 파이프라인

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

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

• 작업(Job), 즉 무엇을 할 것인지 정의합니다. 예를 들어, 코드를 컴파일하거나 테스트하는 작업입니다.
• 단계(Stage), 즉 작업을 언제 실행할 것인지 정의합니다. 예를 들어, 코드를 컴파일한 후 테스트를 실행하는 단계입니다.

작업은 러너에 의해 실행됩니다. 동일한 단계에서 여러 작업이 있을 경우, 충분한 동시 러너가 있다면 병렬로 실행됩니다.

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

단계 내의 어떤 작업이라도 실패하면, 다음 단계는 (일반적으로) 실행되지 않으며 파이프라인은 조기에 종료됩니다.

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

전형적인 파이프라인은 다음과 같은 네 가지 단계로 구성될 수 있으며, 다음 순서로 실행됩니다:

• build 단계, compile이라는 작업을 포함합니다.
• test 단계, test1과 test2라는 두 개의 작업을 포함합니다.
• staging 단계, deploy-to-stage라는 작업을 포함합니다.
• production 단계, deploy-to-prod라는 작업을 포함합니다.

파이프라인의 종류

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

• 기본 파이프라인은 각 단계를 동시에 실행한 후 다음 단계로 이동합니다.
• 필요 키워드를 사용하는 파이프라인은 작업 간의 의존성에 따라 실행되며, 기본 파이프라인보다 빠르게 실행될 수 있습니다.
• 병합 요청 파이프라인은 병합 요청에 대해서만 실행됩니다 (모든 커밋에 대해 실행되지 않음).
• 병합 결과 파이프라인은 소스 브랜치의 변경 사항이 대상 브랜치에 이미 병합된 것처럼 작동하는 병합 요청 파이프라인입니다.
• 병합 트레인은 병합된 결과 파이프라인을 사용하여 병합을 하나씩 대기열에 넣습니다.
• 부모-자식 파이프라인은 복잡한 파이프라인을 여러 개의 자식 서브 파이프라인을 트리거할 수 있는 하나의 부모 파이프라인으로 분해합니다. 이들은 모두 동일한 프로젝트에서 동일한 SHA로 실행됩니다. 이 파이프라인 아키텍처는 모노 리포지토리에 일반적으로 사용됩니다.
• 다중 프로젝트 파이프라인은 서로 다른 프로젝트의 파이프라인을 결합합니다.

파이프라인 구성

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

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

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

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

• 각 프로젝트에 대한 파이프라인 설정.
• 파이프라인 일정.
• 사용자 정의 CI/CD 변수.

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

VS Code를 사용하여 GitLab CI/CD 구성을 편집하는 경우, VS Code용 GitLab Workflow 확장은 구성을 검증하는 데 도움이 됩니다 및 파이프라인 상태를 확인합니다.

파이프라인을 수동으로 실행하기

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

파이프라인의 결과(예: 코드 빌드)가 표준 파이프라인 작업 이외에서 필요할 때 이렇게 할 수 있습니다.

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

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

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

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

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

작업 수준 변수를 미리 채울 수 없습니다.

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

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

예를 들어:

variables:
  DEPLOY_CREDENTIALS:
    description: "배포 자격 증명입니다."
  DEPLOY_ENVIRONMENT:
    description: "'canary', 'staging', 'production' 또는 사용자가 선택한 안정적인 브랜치와 같은 유효한 옵션으로 배포 대상을 선택합니다."
    value: "canary"

이 예에서:

• DEPLOY_CREDENTIALS는 새 파이프라인 페이지에 나열되지만 값이 설정되어 있지 않습니다.
  사용자는 파이프라인을 수동으로 실행할 때마다 값을 정의해야 합니다.

• DEPLOY_ENVIRONMENT는 새 파이프라인 페이지에서 canary를 기본 값으로 미리 채워지며, 다른 옵션을 설명하는 메시지가 표시됩니다.

참고:
알려진 문제로 인해, 준수 파이프라인을 사용하는 프로젝트는 수동으로 파이프라인을 실행할 때 미리 채워진 변수가 표시되지 않을 수 있습니다.
이 문제를 해결하려면,
준수 파이프라인 구성 변경을 참조하세요.

선택 가능한 미리 채워진 변수 값 목록 구성하기

• GitLab 15.5에 도입됨 및 run_pipeline_graphql라는 플래그가 추가됨. 기본적으로 비활성화되어 있음.
• options 키워드가 GitLab 15.7에 도입됨.
• 일반적으로 사용 가능해짐. Feature flag run_pipeline_graphql가 제거됨.
• 변수 목록이 때때로 제대로 채워지지 않은 문제는 버그로 인해 발생했으며, GitLab 15.9에서 해결됨.

사용자가 파이프라인을 수동으로 실행할 때 선택할 수 있는 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 푸시 옵션을 사용할 수 있습니다. ci.skip 푸시 옵션은 병합 요청 파이프라인을 건너뛰지 않습니다.

파이프라인 삭제

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

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

파이프라인을 삭제해도 자식 파이프라인은 자동으로 삭제되지 않으니, 문제 39503에서 더 자세한 정보를 확인하세요.

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

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

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

사용자가 특정 브랜치에 병합하거나 푸시할 수 있는 권한이 있는 경우 보호된 브랜치에서 다음 작업이 허용됩니다:

• 수동 파이프라인 실행( 웹 UI 또는 파이프라인 API 사용).
• 예약된 파이프라인 실행.
• 트리거를 사용한 파이프라인 실행.
• 필요에 따라 DAST 스캔 실행.
• 기존 파이프라인에서 수동 작업 트리거.
• 기존 작업 재시도 또는 취소(웹 UI 또는 파이프라인 API 사용).

보호된으로 표시된 변수는 보호된 브랜치에서 실행되는 작업에 액세스할 수 있습니다. 배포 자격 증명 및 토큰과 같은 민감한 정보에 액세스할 수 있는 권한이 있는 경우에만 사용자가 보호된 브랜치에 병합할 권한을 부여하세요.

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

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

파이프라인을 트리거하여 업스트림 프로젝트를 재구축할 때

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

전제 조건:

• 업스트림 프로젝트는 공개여야 합니다.
• 사용자는 업스트림 프로젝트에서 개발자 역할을 가져야 합니다.

업스트림 프로젝트가 재구축될 때 파이프라인을 트리거하려면:

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)를 표시합니다.
파이프라인 IID를 선택하여 파이프라인 IID(내부 ID, 오직 프로젝트 내에서만 고유)를 표시합니다.

예를 들어:

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

파이프라인 세부정보

• 파이프라인 세부정보 뷰가 업데이트됨 GitLab 16.6에서 new_pipeline_graph라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.
• 업데이트된 파이프라인 세부정보 뷰가 GitLab.com에서 활성화됨 GitLab 16.8에서.

파이프라인을 선택하여 파이프라인 세부정보 페이지를 열면 파이프라인의 모든 작업을 보여줍니다.

이 페이지에서 실행 중인 파이프라인을 취소하거나 실패한 작업을 재시도하거나 파이프라인 삭제를 할 수 있습니다.

파이프라인 세부정보 페이지는 파이프라인의 모든 작업 그래프를 표시합니다:

특정 파이프라인에 대한 세부정보에 액세스하려면 표준 URL을 사용할 수 있습니다:

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

단계 또는 needs 구성으로 작업 그룹화

needs 키워드를 사용하여 작업을 구성하면 파이프라인 세부정보 페이지에서 작업을 그룹화하는 두 가지 옵션이 있습니다. 작업을 단계 구성으로 그룹화하려면 Group jobs by 섹션에서 stage를 선택하세요:

작업을 needs 구성으로 그룹화하려면 Job dependencies를 선택하세요. 의존 작업 사이에 선을 렌더링하려면 선택적으로 Show dependencies를 선택할 수 있습니다.

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

• lint-job은 needs: []로 구성되어 있어 의존하는 작업이 없으므로 test 단계에 있지만 첫 번째 열에 표시됩니다.
• test-job1은 build-job1에 의존하고, test-job2는 build-job1과 build-job2 모두에 의존하므로 두 테스트 작업은 두 번째 열에 표시됩니다.
• 두 deploy 작업은 두 번째 열의 작업(자체적으로 다른 이전 작업에 의존)에 의존하므로 배포 작업은 세 번째 열에 표시됩니다.

Job dependencies 뷰에서 작업 위에 마우스를 올리면 선택한 작업이 실행되기 전에 실행해야 하는 모든 작업이 강조 표시됩니다:

파이프라인 미니 그래프

파이프라인 미니 그래프는 적은 공간을 차지하며 모든 작업이 통과했는지 아니면 실패했는지 한 눈에 알 수 있습니다. 특정 커밋에 대한 모든 관련 작업과 파이프라인의 각 단계의 순 결과를 보여줍니다. 무엇이 실패했는지 빠르게 확인하고 수정할 수 있습니다.

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

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

다운스트림 파이프라인 그래프

파이프라인에 다운스트림 파이프라인을 트리거하는 작업이 포함된 경우,

파이프라인 세부 정보 보기 및 미니 그래프에서 다운스트림 파이프라인을 볼 수 있습니다.

파이프라인 세부 정보 보기에서는,

트리거된 모든 다운스트림 파이프라인에 대해 카드가 파이프라인 그래프 오른쪽에 표시됩니다.

카드를 호버하면 어떤 작업이 다운스트림 파이프라인을 트리거했는지 확인할 수 있습니다.

카드를 선택하면 파이프라인 그래프 오른쪽에 다운스트림 파이프라인이 표시됩니다.

파이프라인 미니 그래프에서는

트리거된 모든 다운스트림 파이프라인의 상태가 미니 그래프 오른쪽에 추가 상태 아이콘으로 표시됩니다.

다운스트림 파이프라인 상태 아이콘을 선택하면 해당 다운스트림 파이프라인의 세부 정보 페이지로 이동합니다.

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

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

파이프라인 배지

파이프라인 상태와 테스트 커버리지 보고서 배지는 각 프로젝트에 대해 사용 가능하며 구성할 수 있습니다.

프로젝트에 파이프라인 배지를 추가하는 방법에 대한 정보는 파이프라인 배지를 참조하십시오.

파이프라인 API

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

• 기본 기능 수행. 자세한 내용은 파이프라인 API를 참조하십시오.
• 파이프라인 일정 관리. 자세한 내용은 파이프라인 일정 API를 참조하십시오.
• 파이프라인 실행 트리거. 자세한 내용은 다음을 참조하십시오:
  • API를 통한 파이프라인 트리거.
  • 파이프라인 트리거 API.

러너를 위한 ref 사양

러너가 파이프라인 작업을 선택할 때, GitLab은 해당 작업의 메타데이터를 제공합니다.

여기에는 Git refspecs가 포함되며,

어떤 ref(예: 브랜치 또는 태그)와 커밋(SHA1)이 프로젝트 리포지토리에서 체크 아웃되는지를 나타냅니다.

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

refs refs/heads/<name> 및 refs/tags/<name>는

귀하의 프로젝트 리포지토리에 존재합니다. GitLab은 실행 중인 파이프라인 작업 동안 특별한 ref refs/pipelines/<id>를 생성합니다.

이 ref는 관련 브랜치 또는 태그가 삭제된 후에도 생성될 수 있습니다.

따라서 이 ref는 환경 자동 중지 및

브랜치 삭제 후 파이프라인을 실행할 수 있는 병합 트레인과 같은 일부 기능에서 유용합니다.