자동 병합
등급: Free, Premium, Ultimate 제공: GitLab.com, Self-managed, GitLab Dedicated
- 파이프라인이 성공하면 병합 및 파이프라인이 성공하면 병합 트레인에 추가은 GitLab 16.0에서 Auto-merge로 이름이 변경되었으며,
auto_merge_labels_mr_widget
이라는 플래그로 기본적으로 활성화됩니다.- GitLab 16.0에서 일반 사용 가능합니다. 기능 플래그
auto_merge_labels_mr_widget
이 제거되었습니다.- GitLab 16.5에서 소개되었습니다. 기본으로 비활성화된
merge_when_checks_pass
및additional_merge_when_checks_ready
라는 두 가지 플래그가 있습니다.- GitLab.com에서 GitLab 17.0에서
merge_when_checks_pass
및additional_merge_when_checks_ready
플래그가 활성화되었습니다.- GitLab 17.4에서 기본으로
merge_when_checks_pass
플래그가 활성화되었습니다.
merge_when_checks_pass
기능 플래그를 활성화하면, 병합 요청의 내용이 병합할 준비가 되면 자동 병합으로 설정할 수 있습니다. 모든 필수 확인 항목이 성공적으로 완료되면 병합 요청이 자동으로 병합되며, 수동으로 요청을 수동으로 병합할 필요가 없습니다.
자동 병합을 설정한 후에는 병합 요청이 병합되기 전에 다음 확인 항목이 모두 통과해야 합니다:
- 모든 필수 승인이 있어야 합니다.
- 다른 병합 요청이 이 병합 요청을 차단하면 안됩니다.
- 병합 충돌이 없어야 합니다.
- CI/CD 파이프라인은 성공적으로 완료되어야 합니다. 프로젝트 설정에 관계없이.
- 모든 토론이 해결되어야 합니다.
- 병합 요청이 임시(Draft) 상태가 아니어야 합니다.
- 모든 외부 상태 확인이 통과되어야 합니다.
- 병합 요청이 열려 있어야 합니다.
- 거부된 정책이 존재하면 안 됩니다.
- 만약 당신의 프로젝트가 Jira 문제를 참조해야 하는 경우, 병합 요청 제목이나 설명에 Jira 문제 링크가 있어야 합니다.
모든 확인 항목 및 그에 상응하는 API에 대한 전체 목록은 병합 상태를 참조하세요.
병합 요청 자동 병합
전제 조건:
- 해당 프로젝트에 적어도 개발자 역할이 있어야 합니다.
- 프로젝트 구성이 필요한 경우, 병합 요청의 모든 쓰레드가 해결되어야 합니다.
- 모든 필수 승인을 받은 병합 요청이어야 합니다.
- 병합 트레인은 지원되지 않습니다. 자세한 내용은 이슈 443395을 참조하세요.
명령줄에서 푸시할 때, merge_request.merge_when_pipeline_succeeds
푸시 옵션을 사용합니다.
GitLab 사용자 인터페이스에서 진행하는 방법:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
- 코드 > 병합 요청을 선택합니다.
- 편집할 병합 요청을 선택합니다.
- 병합 요청 보고서 섹션으로 스크롤합니다.
- 소스 브랜치 삭제, 커밋 통합, 또는 커밋 메시지 편집과 같은 원하는 병합 옵션을 선택합니다.
- 병합 요청 위젯의 내용을 검토합니다. 이슈 닫기 패턴이 포함되어 있는지 확인하여 이 작업을 병합할 때 이슈가 닫힐지 확인하세요:
- 자동 병합을 선택합니다.
자동 병합을 선택한 후에 병합 요청에 자동 병합이라고 의견을 달면 파이프라인이 완료될 때까지 병합이 차단됩니다.
병합 트레인을 사용하는 자동 병합
플래그: 이 기능의 사용 가능성은 기능 플래그로 제어됩니다. 자세한 내용은 이력을 참조하세요.
당신의 프로젝트가 병합 트레인을 사용하는 경우, 두 개의 기능 플래그를 활성화한 후에 자동 병합 기능을 사용할 수 있습니다:
merge_when_checks_pass
merge_when_checks_pass_merge_train
양쪽 기능 플래그를 활성화한 후에 병합 요청에 자동 병합을 선택하면 모든 확인이 완료된 후에 병합 트레인에 추가됩니다.
자동 병합을 위한 파이프라인 성공
파이프라인이 성공하면 병합 요청이 병합됩니다. 파이프라인이 실패하면 작성자는 다음과 같은 옵션을 선택할 수 있습니다:
- 두 번째 시도에서 다시 실행된 작업이 성공하면 병합 요청이 병합됩니다.
- 병합 요청에 새로운 커밋을 추가하면, 새로운 변경 사항이 병합 전에 리뷰를 받도록 GitLab이 요청을 취소합니다.
- 병합 요청의 대상 브랜치에 새로운 커밋을 추가하고, 프로젝트가 오직 빠른 전진 병합 요청만 허용하는 경우, GitLab이 요청을 취소하여 병합 충돌을 방지합니다.
더 엄격한 파이프라인 상태 제어를 위해 병합 전에 성공적인 파이프라인을 요구할 수도 있습니다.
자동 병합 취소
병합 요청의 자동 병합을 취소할 수 있습니다.
전제 조건:
- 병합 요청의 작성자이거나 적어도 개발자 역할을 가진 프로젝트 구성원이어야 합니다.
- 병합 요청의 파이프라인이 여전히 진행 중이어야 합니다.
다음 단계를 수행하세요:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
- 코드 > 병합 요청을 선택합니다.
- 병합 요청을 선택합니다.
- 병합 요청 보고서 섹션으로 스크롤합니다.
- 자동 병합 취소를 선택합니다.
합병을 위한 성공적인 파이프라인이 필요합니다
합병 전 완료된 성공적인 파이프라인을 요구하도록 프로젝트를 구성할 수 있습니다. 이 설정은 다음 두 가지 방법으로 작동합니다:
- GitLab CI/CD 파이프라인
- 외부 CI 통합에서 실행된 파이프라인
결과적으로 GitLab CI/CD 파이프라인을 비활성화 해도 이 기능은 비활성화되지 않지만 외부 CI 제공업체의 파이프라인을 사용할 수 있습니다.
요구 사항:
- 프로젝트의 CI/CD 구성이 모든 합병 요청에 대해 파이프라인을 실행하도록 보장합니다.
- 프로젝트에 대한 최소한 Maintainer 역할이 있어야 합니다.
이 설정을 활성화하려면:
- 좌측 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
- 설정 > 합병 요청을 선택합니다.
- 합병 검사로 스크롤하고 파이프라인은 반드시 성공해야 함을 선택합니다. 이 설정은 또한 파이프라인이 없는 경우 합병 요청을 막아주며, 이는 일부 규칙과 충돌할 수 있습니다.
- 저장을 선택합니다.
동일한 합병 요청에 대해 여러 파이프라인 유형이 실행되는 경우, 합병 요청 파이프라인은 다른 파이프라인 유형보다 우선합니다. 예를 들어, 이전에는 성공했지만 성공하지 않은 브랜치 파이프라인에 비해 새로운 합병 요청 파이프라인이 합병 요청을 허용합니다.
건너뛴 파이프라인 후에 합병 허용
프로젝트에 파이프라인은 반드시 성공해야 함을 설정하면, 건너뛴 파이프라인으로 인해 합병 요청을 막을 수 있습니다.
요구 사항:
- 프로젝트에 대한 최소한 Maintainer 역할이 있어야 합니다.
이 동작을 변경하려면:
- 좌측 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
- 설정 > 합병 요청을 선택합니다.
-
합병 검사 아래:
- 파이프라인은 반드시 성공해야 함을 선택합니다.
- 건너뛴 파이프라인은 성공적으로 간주됩니다를 선택합니다.
- 저장을 선택합니다.
문제 해결
실패한 파이프라인 없이도 합병 요청을 할 수 없음
일부 경우에는 합병을 위한 성공적인 파이프라인이 필요합니다 요구를 하지만 실패한 파이프라인이 없는 합병 요청을 병합할 수 없을 수 있습니다. 이 설정은 성공적인 파이프라인의 존재를 요구하며, 실패한 파이프라인의 부재를 요구하는 것이 아닙니다. 전혀 파이프라인이 없는 합병 요청은 성공적인 파이프라인으로 간주되지 않으며 병합할 수 없습니다.
이 설정을 활성화하면 rules
또는
workflow:rules
를 사용하여
모든 합병 요청에 대해 파이프라인이 실행되도록 보장해야 합니다.
실패한 파이프라인이 있더라도 합병 요청을 병합할 수 있는 경우
일부 경우에는 합병을 위한 성공적인 파이프라인이 필요합니다 요구를 하지만 실패한 파이프라인이 있는 합병 요청을 병합할 수 있습니다.
합병 요청 파이프라인은 파이프라인은 반드시 성공해야 함 설정에 대해 가장 높은 우선순위를 갖습니다. 동일한 합병 요청에 대해 여러 파이프라인 유형이 실행될 수 있으며, GitLab은 합병 요청 파이프라인만 확인합니다.
합병 요청에는 여러 파이프라인이 있을 수 있습니다:
-
rules
구성으로 인해 중복 파이프라인이 발생하는 경우: 하나는 합병 요청 파이프라인이고 다른 하나는 브랜치 파이프라인입니다. 이 경우, 가장 최신의 합병 요청 파이프라인의 상태가 합병 요청을 병합할 수 있는지를 결정하며, 브랜치 파이프라인은 고려되지 않습니다. - 합병 요청과 같은 브랜치를 타겟으로 하는 외부 도구에 의해 트리거된 파이프라인.
모든 경우에 대해 CI/CD 구성을 업데이트하여 동일한 합병 요청에 대해 여러 파이프라인 유형이 실행되지 않도록 해야 합니다.