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

파이프라인은 브랜치에 푸시하거나 머지 리퀘스트를 생성하거나 일정에 따라 실행되는 등 특정 이벤트에 대해 자동으로 실행될 수 있습니다. 필요한 경우 파이프라인을 수동으로 실행할 수도 있습니다.

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

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

작은 파이프라인은 다음 순서로 실행되는 세 개의 stage로 구성될 수 있습니다:

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

첫 파이프라인을 시작하려면 첫 GitLab CI/CD 파이프라인 생성 및 실행을 참고합니다.

파이프라인 유형#

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

• 기본 파이프라인은 각 stage의 모든 항목을 동시에 실행한 뒤 다음 stage로 진행합니다.
• needs 키워드를 사용하는 파이프라인은 job 간의 의존성을 기반으로 실행되며 기본 파이프라인보다 더 빠르게 실행될 수 있습니다.
• 브랜치 파이프라인은 별도 설정 없이 브랜치에 커밋을 푸시할 때마다 실행됩니다.
• 머지 리퀘스트 파이프라인은 모든 커밋이 아니라 머지 리퀘스트에 대해서만 실행됩니다.
• 병합 결과 파이프라인은 소스 브랜치의 변경 사항이 대상 브랜치에 이미 병합된 것처럼 동작하는 머지 리퀘스트 파이프라인입니다.
• 머지 트레인은 병합 결과 파이프라인을 사용해 병합을 순서대로 대기열에 넣습니다.
• 워크로드 파이프라인은 임시 브랜치를 생성하지 않고 온디맨드로 파이프라인을 실행할 수 있도록 일시적인 Git 참조에서 실행됩니다.
• 부모-자식 파이프라인은 복잡한 파이프라인을, 여러 자식 서브 파이프라인을 트리거할 수 있는 하나의 부모 파이프라인으로 분할합니다. 이 서브 파이프라인들은 모두 같은 프로젝트에서 같은 SHA로 실행됩니다. 이 파이프라인 아키텍처는 모노레포에서 흔히 사용됩니다.
• 다중 프로젝트 파이프라인은 서로 다른 프로젝트의 파이프라인을 결합합니다.

파이프라인 구성#

파이프라인과 그 구성 요소인 job, stage는 각 프로젝트의 CI/CD 파이프라인 설정 파일에서 YAML 키워드로 정의합니다. GitLab에서 CI/CD 설정을 편집할 때는 파이프라인 에디터를 사용해야 합니다.

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

• 프로젝트별 파이프라인 설정.
• 파이프라인 일정.
• 사용자 지정 CI/CD 변수.

VS Code로 GitLab CI/CD 설정을 편집하는 경우 GitLab for VS Code 확장을 사용해 설정을 검증하고 파이프라인 상태를 조회할 수 있습니다.

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

히스토리

• GitLab 17.7에서 Run pipeline 이름이 New pipeline으로 변경되었습니다.
• GitLab 17.11에서 ci_inputs_for_pipelines라는 기능 플래그와 함께 Inputs 옵션이 도입되었습니다. 기본적으로 활성화되어 있습니다.
• GitLab 18.1에서 Inputs 옵션이 일반 공급(GA)되었습니다. ci_inputs_for_pipelines 기능 플래그는 제거되었습니다.

파이프라인은 미리 정의되었거나 수동으로 지정한 변수와 함께 수동으로 실행할 수 있습니다.

파이프라인의 표준 동작 범위를 벗어나 파이프라인 결과(예: 코드 빌드)가 필요한 경우 이렇게 할 수 있습니다.

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

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. New pipeline을 선택합니다.
4. Run for branch name or tag 필드에서 파이프라인을 실행할 브랜치 또는 태그를 선택합니다.
5. 선택 사항. 다음을 입력합니다:
   • 파이프라인 실행에 필요한 Inputs. 입력 항목의 기본값이 미리 채워지지만 수정할 수 있습니다. 입력 값은 예상되는 타입을 따라야 합니다.
   • CI/CD 변수. 변수의 값이 폼에 미리 채워지도록 구성할 수 있습니다. 파이프라인 동작을 제어할 때 CI/CD 변수보다 입력 항목을 사용하면 보안과 유연성이 더 향상됩니다.
6. New pipeline을 선택합니다.

이제 파이프라인이 설정된 대로 job을 실행합니다.

수동 파이프라인 변수 조회#

히스토리

• GitLab 17.2에서 ci_show_manual_variables_in_pipeline이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 18.4에서 프로젝트 설정과 함께 일반 공급(GA)되었습니다. ci_show_manual_variables_in_pipeline 기능 플래그는 제거되었습니다.

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

사전 요구 사항:

• 프로젝트에 대한 Owner 권한이 있어야 합니다.

필요한 권한은 수행하려는 작업에 따라 다릅니다:

수동 파이프라인 변수를 조회하려면:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Display pipeline variables를 선택합니다.
4. Build > Pipelines로 이동해 수동으로 실행된 파이프라인을 선택합니다.
5. Manual Variables 탭을 선택합니다.

변수 값은 기본적으로 마스킹되어 있습니다. Developer, Maintainer, Owner 권한이 있는 경우 눈 모양 아이콘을 선택해 값을 표시할 수 있습니다.

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

히스토리

• GitLab 17.11에서 Run pipeline 페이지의 Markdown 렌더링이 도입되었습니다.

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

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

수동으로 트리거된 파이프라인의 경우 New 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_CREDENTIALS는 New pipeline 페이지에 값이 설정되지 않은 채로 표시됩니다. 사용자는 파이프라인을 수동으로 실행할 때마다 값을 정의해야 합니다.
• DEPLOY_ENVIRONMENT는 New pipeline 페이지에 기본값 canary로 미리 채워지며, 메시지에는 다른 옵션이 설명되어 있습니다.

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

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

예를 들면 다음과 같습니다:

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

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

쿼리 문자열을 사용해 New pipeline 페이지를 미리 채울 수 있습니다. 예를 들어 쿼리 문자열 .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar는 다음과 같이 New 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에는 key와 value가 필요합니다.

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

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

파이프라인 그래프에서 바로 이 작업을 할 수 있습니다. 해당 job을 실행하려면 Run ([play])을 선택합니다.

예를 들어 파이프라인이 자동으로 시작되더라도 프로덕션에 배포하려면 수동 작업이 필요하도록 만들 수 있습니다. 다음 예시에서 production stage에는 수동 작업이 있는 job 이 있습니다:

stage의 모든 수동 job 한번에 시작하기#

stage에 수동 job만 있는 경우 stage 위의 Run all manual ([play])을 선택해 모든 job을 동시에 시작할 수 있습니다. stage에 수동이 아닌 job 이 있으면 이 옵션은 표시되지 않습니다.

파이프라인 건너뛰기#

푸시나 머지 리퀘스트에서 CI/CD를 실행하고 싶지 않을 때 파이프라인을 건너뛸 수 있습니다.

파이프라인을 건너뛰면:

• job 이나 stage가 없는 빈 파이프라인이 GitLab에 생성됩니다. 이 파이프라인은 UI에 표시되며 API 응답으로 반환될 수 있습니다.
• 파이프라인 상태는 UI에서는 Skipped, API에서는 skipped로 표시됩니다.

푸시에서 건너뛰기#

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

또는 Git 2.10 이상에서는 ci.skip Git push 옵션을 사용할 수 있습니다.

머지 리퀘스트에서 건너뛰기#

히스토리

• GitLab 19.5에서 ci_skip_pipeline_from_mr_title이라는

머지 리퀘스트 파이프라인을 건너뛰려면 머지 리퀘스트 제목에 대소문자와 관계없이 [ci skip] 또는 [skip ci]를 추가합니다. 이렇게 하면 기본 머지 리퀘스트 파이프라인, 병합 결과 파이프라인, 머지 트레인 파이프라인이 건너뛰어집니다. 이 지시어는 머지 리퀘스트에 충돌이 있는 경우에도 적용됩니다.

머지 리퀘스트가 머지 트레인에 있는 동안 이 지시어를 추가하면, 건너뛴 파이프라인은 성공한 것이 아니므로 GitLab이 머지 리퀘스트를 트레인에서 제거합니다.

머지 리퀘스트 파이프라인은 제목에서 지시어를 제거할 때까지 건너뛴 상태로 유지됩니다. 병합 결과 파이프라인에서는 지시어를 제거한 뒤에도 다음 푸시가 가상 커밋을 다시 생성할 때까지 파이프라인이 건너뛴 상태로 남아 있을 수 있습니다.

파이프라인 삭제하기#

사전 요구 사항:

• 프로젝트에 대한 Owner 권한 또는 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.
• 인스턴스에 Admin Mode가 활성화되어 있는 경우 관리자는 자신의 세션에서 Admin Mode를 켜야 합니다.

파이프라인을 삭제하려면:

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

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

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

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

다음 작업은 사용자가 해당 특정 브랜치에 병합 또는 푸시가 허용된 경우 보호된 브랜치에서 허용됩니다:

• 수동 파이프라인 실행(Web UI 또는 pipelines API 사용).
• 예약된 파이프라인 실행.
• 트리거 토큰을 사용한 파이프라인 실행.
• 온디맨드 DAST 스캔 실행.
• 기존 파이프라인에서 수동 job 실행.
• 기존 job 재시도 또는 취소(Web UI 또는 pipelines API 사용).

protected로 표시된 변수는 보호된 브랜치의 파이프라인에서 실행되는 job에서 액세스할 수 있습니다. 배포 자격 증명이나 토큰 같은 민감한 정보에 액세스할 권한이 있는 사용자에게만 보호된 브랜치로 병합할 권한을 부여합니다.

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

머지 리퀘스트 파이프라인의 맥락에서 보호된 변수와 러너에 대한 액세스가 어떻게 동작하는지 확인합니다.

파이프라인 보안을 강화하기 위한 추가 보안 권장 사항은 배포 안전성 페이지를 참고합니다.

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

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

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

사전 요구 사항:

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

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

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Pipeline subscriptions를 펼칩니다.
4. Add project를 선택합니다.
5. 구독할 프로젝트를 <namespace>/<project> 형식으로 입력합니다. 예를 들어 프로젝트가 https://gitlab.com/gitlab-org/gitlab 이라면 gitlab-org/gitlab을 사용합니다.
6. Subscribe를 선택합니다.

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

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

특정 파이프라인의 총 실행 시간에는 다음이 포함되지 않습니다:

• 재시도되거나 수동으로 다시 실행된 job의 최초 실행 시간.
• 대기(큐) 시간.

즉, job 이 재시도되거나 수동으로 다시 실행된 경우 총 실행 시간에는 가장 최근 실행 시간만 포함됩니다.

각 job은 다음으로 구성된 Period로 표현됩니다:

• Period#first (job 이 시작된 시점).
• Period#last (job 이 종료된 시점).

예를 들면 다음과 같습니다:

• A (0, 2)
• A' (2, 4)
  • A' 는 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는 재시도되었으므로 무시되고 job A' 만 계산됩니다. B, A', C의 합집합은 (1, 4)와 (6, 7) 입니다. 따라서 총 실행 시간은 다음과 같습니다:

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

파이프라인 조회#

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

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.

Pipelines 페이지는 다음 기준으로 필터링할 수 있습니다:

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

오른쪽 상단 드롭다운 목록에서 Pipeline ID를 선택하면 파이프라인 ID(인스턴스 전체에서 고유한 ID)가 표시됩니다. pipeline IID를 선택하면 파이프라인 IID(내부 ID, 프로젝트 내에서만 고유)가 표시됩니다.

특정 머지 리퀘스트와 관련된 파이프라인을 조회하려면 머지 리퀘스트의 Pipelines 탭으로 이동합니다.

파이프라인 세부 정보#

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

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

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

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

stage 또는 needs 설정별로 job 그룹화하기#

needs 키워드로 job을 구성하면 파이프라인 세부 정보 페이지에서 job을 그룹화하는 방법을 두 가지 중에서 선택할 수 있습니다. stage 설정별로 job을 그룹화하려면 Group jobs by 섹션에서 stage를 선택합니다:

needs 설정별로 job을 그룹화하려면 Job dependencies를 선택합니다. 필요하다면 Show dependencies를 선택해 의존하는 job 사이에 선을 표시할 수 있습니다.

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

• lint-job은 needs: []로 구성되어 어떤 job에도 의존하지 않으므로 test stage에 속하지만 첫 번째 열에 표시됩니다.
• test-job1은 build-job1에 의존하고, test-job2는 build-job1과 build-job2 모두에 의존하므로 두 test job 모두 두 번째 열에 표시됩니다.
• 두 deploy job 모두 두 번째 열의 job(이 job 들 자체도 이전의 다른 job에 의존)에 의존하므로 deploy job은 세 번째 열에 표시됩니다.

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

파이프라인 미니 그래프#

파이프라인 미니 그래프는 공간을 덜 차지하면서도 모든 job 이 통과했는지 아니면 무언가 실패했는지 한눈에 알려줍니다. 단일 커밋에 대한 모든 관련 job과 파이프라인의 각 stage의 최종 결과를 보여줍니다. 무엇이 실패했는지 빠르게 확인하고 수정할 수 있습니다.

파이프라인 미니 그래프는 항상 stage 별로 job을 그룹화하며, 파이프라인 또는 커밋 세부 정보를 표시할 때 GitLab 전반에서 나타납니다.

파이프라인 미니 그래프의 stage는 펼칠 수 있습니다. 각 stage 위에 마우스를 올리면 이름과 상태를 확인할 수 있고, stage를 선택하면 해당 job 목록이 펼쳐집니다.

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

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

파이프라인 세부 정보 보기에서는 트리거된 모든 다운스트림 파이프라인에 대해 파이프라인 그래프 오른쪽에 카드가 표시됩니다. 카드 위에 마우스를 올리면 어떤 job 이 다운스트림 파이프라인을 트리거했는지 확인할 수 있습니다. 카드를 선택하면 파이프라인 그래프 오른쪽에 다운스트림 파이프라인이 표시됩니다.

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

파이프라인 성공 및 소요 시간 차트#

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

파이프라인 배지#

파이프라인 상태 및 테스트 커버리지 리포트 배지는 프로젝트별로 사용 및 구성할 수 있습니다. 프로젝트에 파이프라인 배지를 추가하는 방법은 파이프라인 배지를 참고합니다.

파이프라인 API#

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

• 기본 기능 수행. 자세한 내용은 Pipelines API를 참고합니다.
• 파이프라인 일정 유지 관리. 자세한 내용은 Pipeline schedules API를 참고합니다.
• 파이프라인 실행 트리거. 자세한 내용은 다음을 참고합니다:
  • API를 통한 파이프라인 트리거.
  • Pipeline trigger tokens API.

러너용 Ref spec#

러너가 파이프라인 job을 가져오면 GitLab은 해당 job의 메타데이터를 제공합니다. 여기에는 프로젝트 리포지터리에서 어떤 ref(브랜치나 태그 등)와 커밋(SHA1)을 체크아웃할지 나타내는 Git refspec이 포함됩니다.

이 표는 파이프라인 유형별로 주입되는 refspec을 나열합니다:

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

문제 해결#

사용자 삭제 후에도 파이프라인 구독이 계속되는 문제#

사용자가 GitLab.com 계정을 삭제하면 삭제는 7일 동안 이뤄지지 않습니다. 이 기간 동안 해당 사용자가 생성한 파이프라인 구독은 사용자의 원래 권한으로 계속 실행됩니다. 승인되지 않은 파이프라인 실행을 방지하려면 삭제된 사용자의 파이프라인 구독 설정을 즉시 업데이트합니다.

New Pipeline 페이지에 미리 채워진 변수가 표시되지 않는 문제#

파이프라인에 대해 미리 정의된 변수가 별도의 파일에 정의되어 있으면 New Pipeline 페이지에 표시되지 않을 수 있습니다. 별도 파일에 액세스할 권한이 있어야 하며, 그렇지 않으면 미리 정의된 변수가 표시될 수 없습니다.