InfoGrab Docs

자동 머지

요약

머지 리퀘스트의 내용이 병합 준비가 된 경우 Set to auto-merge를 선택할 수 있습니다. 머지 검사를 통해 머지 리퀘스트의 내용 검토에 집중하고, 프로젝트 설정을 사용하여 병합 가능 여부를 결정할 수 있습니다.

히스토리
  • Merge when pipeline succeedsAdd to merge train when pipeline succeeds가 GitLab 16.0에서 auto_merge_labels_mr_widget이라는 플래그와 함께 Auto-merge이름 변경됨. 기본적으로 활성화됨.
  • GitLab 16.0에서 이름이 변경된 자동 머지 기능이 일반 공개됨. 기능 플래그 auto_merge_labels_mr_widget 제거됨.
  • 향상된 자동 머지:
  • GitLab 16.5에서 merge_when_checks_passadditional_merge_when_checks_ready라는 두 가지 플래그와 함께 도입됨. 기본적으로 비활성화됨.
  • GitLab 17.1에서 플래그 additional_merge_when_checks_ready가 플래그 merge_when_checks_pass병합됨.
  • GitLab 17.7에서 일반 공개됨. 기능 플래그 merge_when_checks_pass 제거됨.
  • 머지 트레인을 위한 자동 머지:
  • GitLab 17.2에서 merge_when_checks_pass_merge_train이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
  • GitLab 17.7에서 일반 공개됨. 기능 플래그 merge_when_checks_pass_merge_train 제거됨.

머지 리퀘스트의 내용이 병합 준비가 된 경우 Set to auto-merge를 선택할 수 있습니다. 머지 리퀘스트는 모든 필수 검사가 성공적으로 완료되면 자동으로 병합되며, 수동으로 병합해야 함을 기억할 필요가 없습니다.

머지 검사를 통해 머지 리퀘스트의 내용 검토에 집중하고, 프로젝트 설정을 사용하여 병합 가능 여부를 결정할 수 있습니다. 머지 리퀘스트를 검토할 때 변경 사항이 승인되면 자동 머지로 설정하세요. GitLab은 프로젝트 설정을 적용하며, 머지 리퀘스트가 모든 머지 검사(필수 코드 소유자 및 승인 규칙 등)를 충족할 때까지 병합할 수 없습니다. 모든 필수 머지 검사를 충족한 후에는 별도의 작업 없이 머지 리퀘스트가 병합됩니다.

머지 검사에는 CI/CD 파이프라인 통과 등 다양한 항목이 포함됩니다:

  • 모든 필수 승인이 완료되어야 합니다.
  • 이 머지 리퀘스트를 차단하는 다른 머지 리퀘스트가 없어야 합니다.
  • 머지 충돌이 없어야 합니다.
  • 프로젝트 설정에 관계없이 CI/CD 파이프라인이 성공적으로 완료되어야 합니다.
  • 모든 토론이 해결되어야 합니다.
  • 머지 리퀘스트가 Draft 상태가 아니어야 합니다.
  • 모든 외부 상태 검사가 통과되어야 합니다.
  • 머지 리퀘스트가 열려 있어야 합니다.
  • 거부된 정책이 없어야 합니다.
  • 스캔 실행 정책 또는 파이프라인 실행 정책이 구성된 경우, 최신 커밋에 대한 모든 파이프라인이 머지 리퀘스트 병합 전에 성공해야 합니다.
  • 프로젝트가 병합을 위해 Jira 이슈를 참조하는 머지 리퀘스트를 요구하는 경우, 머지 리퀘스트 제목 또는 설명에 Jira 이슈 링크가 포함되어야 합니다.
  • 제목 유효성 검사 패턴이 구성된 경우, 머지 리퀘스트 제목이 해당 패턴과 일치해야 합니다.
  • 머지 리퀘스트에 Merge after 날짜가 설정된 경우, 현재 시간이 구성된 날짜 이후여야 합니다.

검사 목록 및 해당 API 동등 항목의 전체 목록은 머지 상태를 참조하세요.

자동 머지 준비됨

자동 머지를 설정한 후에는 머지 리퀘스트가 병합될 때 자동으로 닫히는 이슈를 변경할 수 없습니다.

머지 리퀘스트 자동 머지#

전제 조건:

  • 프로젝트에 대한 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  • 프로젝트 구성에서 요구하는 경우, 머지 리퀘스트의 모든 스레드가 해결되어야 합니다.
  • 머지 리퀘스트는 모든 필수 승인을 받아야 합니다.

명령줄에서 푸시할 때 이 작업을 수행하려면 merge_request.merge_when_pipeline_succeeds 푸시 옵션을 사용합니다.

GitLab 사용자 인터페이스에서 이 작업을 수행하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.

  3. 편집할 머지 리퀘스트를 선택합니다.

  4. 머지 리퀘스트 보고서 섹션으로 스크롤합니다.

  5. 선택 사항. Delete source branch, Squash commits 또는 Edit commit message와 같은 원하는 머지 옵션을 선택합니다.

  6. 머지 리퀘스트 보고서 섹션의 내용을 검토합니다. 이슈 종료 패턴이 포함된 경우, 머지 리퀘스트가 병합될 때 이슈가 닫혀야 하는지 확인합니다:

    이 머지 리퀘스트가 이슈 #2754를 닫습니다.

  7. Set to auto-merge를 선택합니다.

자동 머지로 설정한 후 파이프라인이 완료되기 전에 머지 리퀘스트에 댓글을 남기면, 모든 기존 스레드가 해결될 때까지 병합이 차단됩니다.

자동 머지 취소#

머지 리퀘스트에서 자동 머지를 취소할 수 있습니다.

전제 조건:

  • 머지 리퀘스트의 작성자이거나 Developer, Maintainer 또는 Owner 역할을 가진 프로젝트 구성원이어야 합니다.
  • 머지 리퀘스트의 파이프라인이 아직 진행 중이어야 합니다.

방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
  3. 원하는 머지 리퀘스트를 선택합니다.
  4. 머지 리퀘스트 보고서 섹션으로 스크롤합니다.
  5. Cancel auto-merge를 선택합니다.

파이프라인 성공 시 머지 취소 옵션

자동 머지를 위한 파이프라인 성공#

파이프라인이 성공하면 머지 리퀘스트가 병합됩니다. 파이프라인이 실패하면 작성자는 실패한 작업을 재시도하거나 새 커밋을 푸시하여 실패를 수정할 수 있습니다:

  • 재시도한 작업이 두 번째 시도에서 성공하면 머지 리퀘스트가 병합됩니다.
  • 머지 리퀘스트에 새 커밋을 추가하면 GitLab이 병합 전에 새 변경 사항이 검토를 받도록 요청을 취소합니다.
  • 머지 리퀘스트의 대상 브랜치에 새 커밋을 추가하고 프로젝트가 fast-forward 머지 리퀘스트만 허용하는 경우, GitLab이 머지 충돌을 방지하기 위해 요청을 취소합니다.

파이프라인 상태를 더 엄격하게 제어하려면 병합 전에 성공적인 파이프라인 필요를 설정할 수도 있습니다.

병합을 위한 성공적인 파이프라인 필요#

병합 전에 완료되고 성공적인 파이프라인이 필요하도록 프로젝트를 구성할 수 있습니다. 이 구성은 다음 모두에 작동합니다:

  • GitLab CI/CD 파이프라인.
  • 외부 CI 통합에서 실행되는 파이프라인.

따라서 GitLab CI/CD 파이프라인 비활성화는 이 기능을 비활성화하지 않지만, 외부 CI 프로바이더의 파이프라인과 함께 사용할 수 있습니다.

전제 조건:

  • 모든 머지 리퀘스트에 대해 파이프라인을 실행하도록 프로젝트의 CI/CD 구성이 되어 있어야 합니다.
  • 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.

이 설정을 활성화하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. Settings > Merge requests를 선택합니다.
  3. Merge checks로 스크롤하고 Pipelines must succeed를 선택합니다. 이 설정은 파이프라인이 없을 때 머지 리퀘스트 병합도 방지하며, 일부 규칙과 충돌할 수 있습니다.
  4. Save를 선택합니다.

동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 실행되는 경우, 머지 리퀘스트 파이프라인이 다른 파이프라인 유형보다 우선합니다. 예를 들어, 더 오래되었지만 성공한 머지 리퀘스트 파이프라인은 더 최신이지만 실패한 브랜치 파이프라인에도 불구하고 머지 리퀘스트를 병합할 수 있습니다.

스킵된 파이프라인 후 병합 허용#

프로젝트에 Pipelines must succeed를 설정하면 스킵된 파이프라인이 머지 리퀘스트 병합을 방지합니다.

전제 조건:

  • 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.

이 동작을 변경하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. Settings > Merge requests를 선택합니다.
  3. Merge checks 아래:
    • Pipelines must succeed를 선택합니다.
    • Skipped pipelines are considered successful을 선택합니다.
  4. Save를 선택합니다.

특정 날짜 이전 병합 방지#

히스토리

머지 리퀘스트가 특정 날짜 및 시간 이전에 병합되지 않아야 하는 경우 Merge can start 날짜를 설정합니다. 이 값은 병합(또는 머지 트레인)이 시작될 수 있는 시기를 설정합니다. 그러나 다른 머지 검사의 충족 또는 머지 트레인의 길이에 따라 병합의 정확한 시간은 달라질 수 있습니다.

전제 조건:

  • 프로젝트에 대한 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.

방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
  3. 편집할 머지 리퀘스트를 선택합니다.
  4. Edit을 선택합니다.
  5. Merge can start 드롭다운 목록에서 After scheduled date를 선택한 후 날짜와 시간을 선택합니다.
  6. Save changes를 선택합니다.

문제 해결#

실패한 파이프라인이 없는데도 머지 리퀘스트 병합 불가#

경우에 따라 병합을 위한 성공적인 파이프라인을 필요로 설정했는데도 실패한 파이프라인 없이 머지 리퀘스트를 병합할 수 없는 경우가 있습니다. 이 설정은 성공적인 파이프라인의 존재를 요구하며, 실패한 파이프라인의 부재를 요구하는 것이 아닙니다. 파이프라인이 전혀 없는 머지 리퀘스트는 성공적인 파이프라인이 있는 것으로 간주되지 않으며, 병합할 수 없습니다.

이 설정을 활성화할 때 모든 머지 리퀘스트에 대해 파이프라인이 실행되도록 rules 또는 workflow:rules를 사용하세요.

실패한 파이프라인에도 불구하고 머지 리퀘스트 병합 가능#

경우에 따라 병합을 위한 성공적인 파이프라인을 필요로 설정했는데도 실패한 파이프라인이 있는 머지 리퀘스트를 여전히 병합할 수 있는 경우가 있습니다.

머지 리퀘스트 파이프라인은 Pipelines must succeed 설정에서 가장 높은 우선순위를 가집니다. 동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 실행되는 경우 GitLab은 성공 여부를 위해 머지 리퀘스트 파이프라인만 확인합니다.

다음과 같은 경우 머지 리퀘스트에 여러 파이프라인이 있을 수 있습니다:

  • 중복 파이프라인을 유발하는 rules 구성: 하나의 머지 리퀘스트 파이프라인과 하나의 브랜치 파이프라인. 이 경우 머지 리퀘스트를 병합할 수 있는지 여부는 브랜치 파이프라인이 아닌 최신 머지 리퀘스트 파이프라인의 상태에 따라 결정됩니다.
  • 머지 리퀘스트와 동일한 브랜치를 대상으로 하는 외부 도구에 의해 트리거된 파이프라인.

모든 경우에서 CI/CD 구성을 업데이트하여 동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 발생하지 않도록 하세요.

자동 머지

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

머지 리퀘스트의 내용이 병합 준비가 된 경우 Set to auto-merge를 선택할 수 있습니다. 머지 검사를 통해 머지 리퀘스트의 내용 검토에 집중하고, 프로젝트 설정을 사용하여 병합 가능 여부를 결정할 수 있습니다.

히스토리
  • Merge when pipeline succeedsAdd to merge train when pipeline succeeds가 GitLab 16.0에서 auto_merge_labels_mr_widget이라는 플래그와 함께 Auto-merge이름 변경됨. 기본적으로 활성화됨.
  • GitLab 16.0에서 이름이 변경된 자동 머지 기능이 일반 공개됨. 기능 플래그 auto_merge_labels_mr_widget 제거됨.
  • 향상된 자동 머지:
  • GitLab 16.5에서 merge_when_checks_passadditional_merge_when_checks_ready라는 두 가지 플래그와 함께 도입됨. 기본적으로 비활성화됨.
  • GitLab 17.1에서 플래그 additional_merge_when_checks_ready가 플래그 merge_when_checks_pass병합됨.
  • GitLab 17.7에서 일반 공개됨. 기능 플래그 merge_when_checks_pass 제거됨.
  • 머지 트레인을 위한 자동 머지:
  • GitLab 17.2에서 merge_when_checks_pass_merge_train이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
  • GitLab 17.7에서 일반 공개됨. 기능 플래그 merge_when_checks_pass_merge_train 제거됨.

머지 리퀘스트의 내용이 병합 준비가 된 경우 Set to auto-merge를 선택할 수 있습니다. 머지 리퀘스트는 모든 필수 검사가 성공적으로 완료되면 자동으로 병합되며, 수동으로 병합해야 함을 기억할 필요가 없습니다.

머지 검사를 통해 머지 리퀘스트의 내용 검토에 집중하고, 프로젝트 설정을 사용하여 병합 가능 여부를 결정할 수 있습니다. 머지 리퀘스트를 검토할 때 변경 사항이 승인되면 자동 머지로 설정하세요. GitLab은 프로젝트 설정을 적용하며, 머지 리퀘스트가 모든 머지 검사(필수 코드 소유자 및 승인 규칙 등)를 충족할 때까지 병합할 수 없습니다. 모든 필수 머지 검사를 충족한 후에는 별도의 작업 없이 머지 리퀘스트가 병합됩니다.

머지 검사에는 CI/CD 파이프라인 통과 등 다양한 항목이 포함됩니다:

  • 모든 필수 승인이 완료되어야 합니다.
  • 이 머지 리퀘스트를 차단하는 다른 머지 리퀘스트가 없어야 합니다.
  • 머지 충돌이 없어야 합니다.
  • 프로젝트 설정에 관계없이 CI/CD 파이프라인이 성공적으로 완료되어야 합니다.
  • 모든 토론이 해결되어야 합니다.
  • 머지 리퀘스트가 Draft 상태가 아니어야 합니다.
  • 모든 외부 상태 검사가 통과되어야 합니다.
  • 머지 리퀘스트가 열려 있어야 합니다.
  • 거부된 정책이 없어야 합니다.
  • 스캔 실행 정책 또는 파이프라인 실행 정책이 구성된 경우, 최신 커밋에 대한 모든 파이프라인이 머지 리퀘스트 병합 전에 성공해야 합니다.
  • 프로젝트가 병합을 위해 Jira 이슈를 참조하는 머지 리퀘스트를 요구하는 경우, 머지 리퀘스트 제목 또는 설명에 Jira 이슈 링크가 포함되어야 합니다.
  • 제목 유효성 검사 패턴이 구성된 경우, 머지 리퀘스트 제목이 해당 패턴과 일치해야 합니다.
  • 머지 리퀘스트에 Merge after 날짜가 설정된 경우, 현재 시간이 구성된 날짜 이후여야 합니다.

검사 목록 및 해당 API 동등 항목의 전체 목록은 머지 상태를 참조하세요.

자동 머지 준비됨

자동 머지를 설정한 후에는 머지 리퀘스트가 병합될 때 자동으로 닫히는 이슈를 변경할 수 없습니다.

머지 리퀘스트 자동 머지#

전제 조건:

  • 프로젝트에 대한 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  • 프로젝트 구성에서 요구하는 경우, 머지 리퀘스트의 모든 스레드가 해결되어야 합니다.
  • 머지 리퀘스트는 모든 필수 승인을 받아야 합니다.

명령줄에서 푸시할 때 이 작업을 수행하려면 merge_request.merge_when_pipeline_succeeds 푸시 옵션을 사용합니다.

GitLab 사용자 인터페이스에서 이 작업을 수행하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.

  3. 편집할 머지 리퀘스트를 선택합니다.

  4. 머지 리퀘스트 보고서 섹션으로 스크롤합니다.

  5. 선택 사항. Delete source branch, Squash commits 또는 Edit commit message와 같은 원하는 머지 옵션을 선택합니다.

  6. 머지 리퀘스트 보고서 섹션의 내용을 검토합니다. 이슈 종료 패턴이 포함된 경우, 머지 리퀘스트가 병합될 때 이슈가 닫혀야 하는지 확인합니다:

    이 머지 리퀘스트가 이슈 #2754를 닫습니다.

  7. Set to auto-merge를 선택합니다.

자동 머지로 설정한 후 파이프라인이 완료되기 전에 머지 리퀘스트에 댓글을 남기면, 모든 기존 스레드가 해결될 때까지 병합이 차단됩니다.

자동 머지 취소#

머지 리퀘스트에서 자동 머지를 취소할 수 있습니다.

전제 조건:

  • 머지 리퀘스트의 작성자이거나 Developer, Maintainer 또는 Owner 역할을 가진 프로젝트 구성원이어야 합니다.
  • 머지 리퀘스트의 파이프라인이 아직 진행 중이어야 합니다.

방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
  3. 원하는 머지 리퀘스트를 선택합니다.
  4. 머지 리퀘스트 보고서 섹션으로 스크롤합니다.
  5. Cancel auto-merge를 선택합니다.

파이프라인 성공 시 머지 취소 옵션

자동 머지를 위한 파이프라인 성공#

파이프라인이 성공하면 머지 리퀘스트가 병합됩니다. 파이프라인이 실패하면 작성자는 실패한 작업을 재시도하거나 새 커밋을 푸시하여 실패를 수정할 수 있습니다:

  • 재시도한 작업이 두 번째 시도에서 성공하면 머지 리퀘스트가 병합됩니다.
  • 머지 리퀘스트에 새 커밋을 추가하면 GitLab이 병합 전에 새 변경 사항이 검토를 받도록 요청을 취소합니다.
  • 머지 리퀘스트의 대상 브랜치에 새 커밋을 추가하고 프로젝트가 fast-forward 머지 리퀘스트만 허용하는 경우, GitLab이 머지 충돌을 방지하기 위해 요청을 취소합니다.

파이프라인 상태를 더 엄격하게 제어하려면 병합 전에 성공적인 파이프라인 필요를 설정할 수도 있습니다.

병합을 위한 성공적인 파이프라인 필요#

병합 전에 완료되고 성공적인 파이프라인이 필요하도록 프로젝트를 구성할 수 있습니다. 이 구성은 다음 모두에 작동합니다:

  • GitLab CI/CD 파이프라인.
  • 외부 CI 통합에서 실행되는 파이프라인.

따라서 GitLab CI/CD 파이프라인 비활성화는 이 기능을 비활성화하지 않지만, 외부 CI 프로바이더의 파이프라인과 함께 사용할 수 있습니다.

전제 조건:

  • 모든 머지 리퀘스트에 대해 파이프라인을 실행하도록 프로젝트의 CI/CD 구성이 되어 있어야 합니다.
  • 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.

이 설정을 활성화하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. Settings > Merge requests를 선택합니다.
  3. Merge checks로 스크롤하고 Pipelines must succeed를 선택합니다. 이 설정은 파이프라인이 없을 때 머지 리퀘스트 병합도 방지하며, 일부 규칙과 충돌할 수 있습니다.
  4. Save를 선택합니다.

동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 실행되는 경우, 머지 리퀘스트 파이프라인이 다른 파이프라인 유형보다 우선합니다. 예를 들어, 더 오래되었지만 성공한 머지 리퀘스트 파이프라인은 더 최신이지만 실패한 브랜치 파이프라인에도 불구하고 머지 리퀘스트를 병합할 수 있습니다.

스킵된 파이프라인 후 병합 허용#

프로젝트에 Pipelines must succeed를 설정하면 스킵된 파이프라인이 머지 리퀘스트 병합을 방지합니다.

전제 조건:

  • 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.

이 동작을 변경하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. Settings > Merge requests를 선택합니다.
  3. Merge checks 아래:
    • Pipelines must succeed를 선택합니다.
    • Skipped pipelines are considered successful을 선택합니다.
  4. Save를 선택합니다.

특정 날짜 이전 병합 방지#

히스토리

머지 리퀘스트가 특정 날짜 및 시간 이전에 병합되지 않아야 하는 경우 Merge can start 날짜를 설정합니다. 이 값은 병합(또는 머지 트레인)이 시작될 수 있는 시기를 설정합니다. 그러나 다른 머지 검사의 충족 또는 머지 트레인의 길이에 따라 병합의 정확한 시간은 달라질 수 있습니다.

전제 조건:

  • 프로젝트에 대한 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.

방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
  2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
  3. 편집할 머지 리퀘스트를 선택합니다.
  4. Edit을 선택합니다.
  5. Merge can start 드롭다운 목록에서 After scheduled date를 선택한 후 날짜와 시간을 선택합니다.
  6. Save changes를 선택합니다.

문제 해결#

실패한 파이프라인이 없는데도 머지 리퀘스트 병합 불가#

경우에 따라 병합을 위한 성공적인 파이프라인을 필요로 설정했는데도 실패한 파이프라인 없이 머지 리퀘스트를 병합할 수 없는 경우가 있습니다. 이 설정은 성공적인 파이프라인의 존재를 요구하며, 실패한 파이프라인의 부재를 요구하는 것이 아닙니다. 파이프라인이 전혀 없는 머지 리퀘스트는 성공적인 파이프라인이 있는 것으로 간주되지 않으며, 병합할 수 없습니다.

이 설정을 활성화할 때 모든 머지 리퀘스트에 대해 파이프라인이 실행되도록 rules 또는 workflow:rules를 사용하세요.

실패한 파이프라인에도 불구하고 머지 리퀘스트 병합 가능#

경우에 따라 병합을 위한 성공적인 파이프라인을 필요로 설정했는데도 실패한 파이프라인이 있는 머지 리퀘스트를 여전히 병합할 수 있는 경우가 있습니다.

머지 리퀘스트 파이프라인은 Pipelines must succeed 설정에서 가장 높은 우선순위를 가집니다. 동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 실행되는 경우 GitLab은 성공 여부를 위해 머지 리퀘스트 파이프라인만 확인합니다.

다음과 같은 경우 머지 리퀘스트에 여러 파이프라인이 있을 수 있습니다:

  • 중복 파이프라인을 유발하는 rules 구성: 하나의 머지 리퀘스트 파이프라인과 하나의 브랜치 파이프라인. 이 경우 머지 리퀘스트를 병합할 수 있는지 여부는 브랜치 파이프라인이 아닌 최신 머지 리퀘스트 파이프라인의 상태에 따라 결정됩니다.
  • 머지 리퀘스트와 동일한 브랜치를 대상으로 하는 외부 도구에 의해 트리거된 파이프라인.

모든 경우에서 CI/CD 구성을 업데이트하여 동일한 머지 리퀘스트에 대해 여러 파이프라인 유형이 발생하지 않도록 하세요.