CI/CD 파이프라인은 GitLab CI/CD의 기본 구성 요소입니다. 파이프라인은 YAML 키워드를 사용하여 .gitlab-ci.yml 파일에 구성됩니다.

파이프라인은 브랜치에 푸시하거나, 머지 요청을 생성하거나, 일정에 따라 자동으로 실행될 수 있습니다. 필요한 경우 파이프라인을 수동으로 실행할 수도 있습니다.

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

• 프로젝트 파이프라인의 전반적인 동작을 제어하는 전역 YAML 키워드.
• 작업을 수행하기 위해 명령을 실행하는 잡. 예를 들어, 잡은 코드를 컴파일, 테스트 또는 배포할 수 있습니다. 잡은 서로 독립적으로 실행되며 러너에 의해 실행됩니다.
• 잡을 그룹화하는 방법을 정의하는 스테이지. 스테이지는 순서대로 실행되는 반면, 스테이지 내의 잡은 병렬로 실행됩니다. 예를 들어, 초기 스테이지에는 코드를 린트하고 컴파일하는 잡이 있고, 이후 스테이지에는 코드를 테스트하고 배포하는 잡이 있을 수 있습니다. 스테이지의 모든 잡이 성공하면 파이프라인은 다음 스테이지로 이동합니다. 스테이지의 어느 잡이라도 실패하면 다음 스테이지는 (일반적으로) 실행되지 않고 파이프라인이 일찍 종료됩니다.

소규모 파이프라인은 다음 순서로 실행되는 세 가지 스테이지로 구성될 수 있습니다:

• compile이라는 잡이 프로젝트 코드를 컴파일하는 build 스테이지.
• 코드에 대한 다양한 테스트를 실행하는 test1과 test2 두 잡이 있는 test 스테이지. 이 테스트는 compile 잡이 성공적으로 완료된 경우에만 실행됩니다.
• deploy-to-production 잡이 있는 deploy 스테이지. 이 잡은 test 스테이지의 두 잡이 모두 시작되고 성공적으로 완료된 경우에만 실행됩니다.

첫 번째 파이프라인 시작에 대해서는 첫 번째 GitLab CI/CD 파이프라인 만들기 및 실행을 참조하세요.

파이프라인 유형#

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

• 기본 파이프라인은 각 스테이지의 모든 것을 동시에 실행한 후 다음 스테이지를 실행합니다.
• needs 키워드를 사용하는 파이프라인은 잡 간의 의존성을 기반으로 실행되며 기본 파이프라인보다 더 빠르게 실행될 수 있습니다.
• 머지 요청 파이프라인은 머지 요청에 대해서만 실행됩니다(모든 커밋이 아닌).
• 병합된 결과 파이프라인은 소스 브랜치의 변경 사항이 이미 대상 브랜치에 병합된 것처럼 동작하는 머지 요청 파이프라인입니다.
• 머지 트레인은 병합된 결과 파이프라인을 사용하여 병합을 차례로 대기열에 넣습니다.
• 워크로드 파이프라인은 임시 브랜치를 생성하지 않고 온디맨드 파이프라인 실행을 위해 임시 Git 참조에서 실행됩니다.
• 부모-자식 파이프라인은 복잡한 파이프라인을 하나의 부모 파이프라인으로 분리하여 동일한 프로젝트와 동일한 SHA로 실행되는 여러 자식 하위 파이프라인을 트리거할 수 있습니다. 이 파이프라인 아키텍처는 모노레포에서 일반적으로 사용됩니다.
• 다중 프로젝트 파이프라인은 서로 다른 프로젝트의 파이프라인을 결합합니다.

파이프라인 구성#

파이프라인과 구성 요소인 잡 및 스테이지는 각 프로젝트의 CI/CD 파이프라인 구성 파일에서 YAML 키워드로 정의됩니다. GitLab에서 CI/CD 구성을 편집할 때는 파이프라인 편집기를 사용해야 합니다.

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

• 각 프로젝트의 파이프라인 설정.
• 파이프라인 스케줄.
• 사용자 정의 CI/CD 변수.

VS Code를 사용하여 GitLab CI/CD 구성을 편집하는 경우, GitLab for VS Code 확장을 사용하여 구성을 유효성 검사하고 파이프라인을 모니터링하고 관리할 수 있습니다.

파이프라인 수동 실행#

히스토리

• Run pipeline 이름이 GitLab 17.7에서 New pipeline으로 변경됨.
• GitLab 17.11에서 ci_inputs_for_pipelines라는 플래그와 함께 입력값 옵션이 도입됨. 기본적으로 활성화됨.
• GitLab 18.1에서 입력값 옵션이 일반 공개됨. 기능 플래그 ci_inputs_for_pipelines 제거됨.

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

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

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

1. 상단 바에서 검색하거나 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
3. 새 파이프라인을 선택합니다.
4. 브랜치 이름 또는 태그에 대해 실행 필드에서 파이프라인을 실행할 브랜치나 태그를 선택합니다.
5. 선택 사항. 다음을 입력합니다:
   • 파이프라인을 실행하는 데 필요한 입력값. 입력값의 기본값이 미리 채워지지만 수정할 수 있습니다. 입력값은 예상된 유형을 따라야 합니다.
   • CI/CD 변수. 양식에서 값을 미리 채우도록 변수를 구성할 수 있습니다. 파이프라인 동작을 제어하기 위해 입력값을 사용하면 CI/CD 변수보다 향상된 보안과 유연성을 제공합니다.
6. 새 파이프라인을 선택합니다.

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

수동 파이프라인 변수 보기#

히스토리

• GitLab 17.2에서 ci_show_manual_variables_in_pipeline이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 18.4에서 프로젝트 설정과 함께 일반 공개됨. 기능 플래그 ci_show_manual_variables_in_pipeline 제거됨.

파이프라인이 수동으로 실행될 때 지정된 모든 변수를 볼 수 있습니다.

사전 조건:

• 프로젝트에 대한 소유자 역할이 있어야 합니다.

필요한 역할은 수행할 작업에 따라 다릅니다:

수동 파이프라인 변수를 보려면:

1. 상단 바에서 검색하거나 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. 파이프라인 변수 표시를 선택합니다.
4. 빌드 > 파이프라인으로 이동하여 수동으로 실행된 파이프라인을 선택합니다.
5. 수동 변수 탭을 선택합니다.

변수 값은 기본적으로 마스킹됩니다. 개발자, 유지 관리자 또는 소유자 역할이 있으면 눈 아이콘을 선택하여 값을 표시할 수 있습니다.

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

히스토리

• GitLab 17.11에서 파이프라인 실행 페이지의 Markdown 렌더링이 도입됨.

description 및 value 키워드를 사용하여 파이프라인을 수동으로 실행할 때 미리 채워지는 파이프라인 수준(전역) 변수를 정의할 수 있습니다. 설명을 사용하여 변수의 용도와 허용 가능한 값 등의 정보를 설명합니다. 설명에서 Markdown을 사용할 수 있습니다.

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

수동으로 트리거된 파이프라인에서 새 파이프라인 페이지에는 .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를 기본값으로 미리 채워지며, 메시지에 다른 옵션이 설명됩니다.

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

히스토리

• GitLab 15.5에서 run_pipeline_graphql이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• options 키워드가 GitLab 15.7에서 도입됨.
• GitLab 15.7에서 일반 공개됨. 기능 플래그 run_pipeline_graphql 제거됨.
• GitLab 15.9에서 해결된 버그로 인해 변수 목록이 올바르게 채워지지 않는 경우가 있었습니다.

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

예를 들면:

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

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에 대해 키와 값이 필요합니다.

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

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

파이프라인 그래프에서 직접 이 작업을 수행할 수 있습니다. 실행([play])을 선택하여 특정 잡을 실행합니다.

예를 들어, 파이프라인을 자동으로 시작할 수 있지만 프로덕션에 배포하기 위해 수동 작업을 요구할 수 있습니다. 다음 예시에서 production 스테이지에는 수동 작업이 있는 잡이 있습니다:

스테이지의 모든 수동 잡 시작#

스테이지에 수동 잡만 포함되어 있는 경우, 스테이지 위에 있는 모든 수동 항목 실행([play])을 선택하여 모든 잡을 동시에 시작할 수 있습니다. 스테이지에 수동이 아닌 잡이 포함된 경우 이 옵션이 표시되지 않습니다.

파이프라인 건너뛰기#

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

또는 Git 2.10 이상에서 ci.skip Git 푸시 옵션을 사용합니다. ci.skip 푸시 옵션은 머지 요청 파이프라인을 건너뛰지 않습니다.

파이프라인을 건너뛰면:

• 잡이나 스테이지가 없는 빈 파이프라인이 GitLab에 생성됩니다. 파이프라인이 UI에 표시되고 API 응답에서 반환될 수 있습니다.
• 파이프라인 상태는 UI에서 건너뜀이고 API에서 skipped입니다.

파이프라인 삭제#

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

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

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

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

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

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

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

보호된 것으로 표시된 변수는 보호된 브랜치의 파이프라인에서 실행되는 잡에서 접근할 수 있습니다. 배포 자격 증명 및 토큰과 같은 민감한 정보에 접근 권한이 있는 사용자에게만 보호된 브랜치로 병합하는 권한을 부여하세요.

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

머지 요청 파이프라인의 맥락에서 보호된 변수 및 러너에 대한 접근 방식을 검토하세요.

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

업스트림 프로젝트가 재빌드될 때 파이프라인 트리거#

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

대안으로, 파이프라인 트리거 토큰이 있는 CI/CD 잡을 사용하여 다른 파이프라인이 실행될 때 파이프라인을 트리거할 수 있습니다. 이 방법은 파이프라인 구독보다 더 안정적이고 유연하며 권장되는 접근 방식입니다.

사전 조건:

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

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

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

업스트림 파이프라인 구독의 최대 수는 업스트림 및 다운스트림 프로젝트 모두에서 기본적으로 2개입니다. GitLab Self-Managed에서 관리자는 이 제한을 변경할 수 있습니다.

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

주어진 파이프라인의 총 실행 시간에서 다음이 제외됩니다:

• 재시도되거나 수동으로 재실행된 잡의 초기 실행 지속 시간.
• 대기(큐) 시간.

즉, 잡이 재시도되거나 수동으로 재실행되면 최신 실행의 지속 시간만 총 실행 시간에 포함됩니다.

각 잡은 다음으로 구성된 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 16.8에서 업데이트된 파이프라인 세부 보기가 GitLab.com에서 활성화됨.

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

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

표준 URL을 사용하여 특정 파이프라인의 세부 정보에 접근할 수 있습니다:

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

스테이지 또는 needs 구성별 잡 그룹화#

needs 키워드로 잡을 구성할 때, 파이프라인 세부 정보 페이지에서 잡을 그룹화하는 두 가지 옵션이 있습니다. 잡을 스테이지 구성별로 그룹화하려면 잡 그룹화 기준 섹션에서 스테이지를 선택합니다:

잡을 needs 구성별로 그룹화하려면 잡 의존성을 선택합니다. 선택적으로 의존성 표시를 선택하여 의존하는 잡 사이에 선을 렌더링할 수 있습니다.

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

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

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

파이프라인 미니 그래프#

파이프라인 미니 그래프는 공간을 덜 차지하며 모든 잡이 통과했는지 또는 실패한 항목이 있는지 한 눈에 확인할 수 있습니다. 단일 커밋의 모든 관련 잡과 파이프라인의 각 스테이지에 대한 순 결과를 표시합니다. 실패한 항목을 빠르게 확인하고 수정할 수 있습니다.

파이프라인 미니 그래프는 항상 잡을 스테이지별로 그룹화하며, 파이프라인이나 커밋 세부 정보를 표시할 때 GitLab 전체에 표시됩니다.

파이프라인 미니 그래프의 스테이지는 확장 가능합니다. 각 스테이지 위에 마우스를 올려 이름과 상태를 확인하고, 스테이지를 선택하여 잡 목록을 확장합니다.

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

파이프라인에 다운스트림 파이프라인을 트리거하는 잡이 포함된 경우, 파이프라인 세부 보기와 미니 그래프에서 다운스트림 파이프라인을 볼 수 있습니다.

파이프라인 세부 보기에서 파이프라인 그래프의 오른쪽에 트리거된 각 다운스트림 파이프라인에 대한 카드가 표시됩니다. 카드 위에 마우스를 올리면 다운스트림 파이프라인을 트리거한 잡을 확인할 수 있습니다. 카드를 선택하면 파이프라인 그래프 오른쪽에 다운스트림 파이프라인이 표시됩니다.

파이프라인 미니 그래프에서 트리거된 각 다운스트림 파이프라인의 상태가 미니 그래프 오른쪽에 추가 상태 아이콘으로 표시됩니다. 다운스트림 파이프라인 상태 아이콘을 선택하면 해당 다운스트림 파이프라인의 세부 정보 페이지로 이동합니다.

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

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

파이프라인 배지#

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

파이프라인 API#

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

• 기본 기능 수행. 자세한 내용은 파이프라인 API를 참조하세요.
• 파이프라인 스케줄 유지. 자세한 내용은 파이프라인 스케줄 API를 참조하세요.
• 파이프라인 실행 트리거. 자세한 내용은 다음을 참조하세요:
  • API를 통한 파이프라인 트리거.
  • 파이프라인 트리거 API.

러너를 위한 Ref 스펙#

러너가 파이프라인 잡을 가져올 때, GitLab은 해당 잡의 메타데이터를 제공합니다. 여기에는 프로젝트 저장소에서 어떤 ref(브랜치나 태그 등)와 커밋(SHA1)이 체크아웃되는지를 나타내는 Git ref 스펙이 포함됩니다.

이 표는 각 파이프라인 유형에 삽입되는 ref 스펙을 나열합니다:

refs refs/heads/<name>과 refs/tags/<name>은 프로젝트 저장소에 존재합니다. GitLab은 실행 중인 파이프라인 잡 중에 특수 ref refs/pipelines/<id>를 생성합니다. 이 ref는 연관된 브랜치나 태그가 삭제된 후에도 생성될 수 있습니다. 따라서 환경 자동 중지 및 브랜치 삭제 후 파이프라인을 실행할 수 있는 머지 트레인과 같은 일부 기능에서 유용합니다.

문제 해결#

사용자 삭제 후 파이프라인 구독이 계속됨#

사용자가 GitLab.com 계정을 삭제할 때 삭제는 7일 동안 이루어지지 않습니다. 이 기간 동안 해당 사용자가 만든 파이프라인 구독은 사용자의 원래 권한으로 계속 실행됩니다. 무단 파이프라인 실행을 방지하려면 삭제된 사용자의 파이프라인 구독 설정을 즉시 업데이트하세요.

미리 채워진 변수가 새 파이프라인 페이지에 표시되지 않음#

파이프라인의 미리 정의된 변수가 별도 파일에 정의된 경우, 새 파이프라인 페이지에 표시되지 않을 수 있습니다. 별도 파일에 접근 권한이 있어야 하며, 그렇지 않으면 미리 정의된 변수가 표시될 수 없습니다.