병합 결과 파이프라인

병합 결과 파이프라인 (Merged results pipelines)

병합 결과 파이프라인은 소스 브랜치와 대상 브랜치의 코드를 결합한 임시 병합 커밋을 테스트해요. 이 커밋은 어느 브랜치에도 존재하지 않지만, 파이프라인 상세 정보에서 볼 수 있어요.

이 방식은 변경 사항이 최신 대상 브랜치의 코드와 잘 동작하는지 확인하고, 병합 전에 통합 문제를 잡아내며, 서로 다른 파일의 변경 사항이 함께 잘 동작하는지 보장하는 데 도움이 돼요.

병합 결과 파이프라인은 대상 브랜치에 소스 브랜치의 변경 사항과 충돌하는 변경이 있을 때는 실행될 수 없어요. 이런 경우 GitLab은 대신 표준 머지 리퀘스트 파이프라인을 실행해요.

출처: 문서

본문

병합 결과 파이프라인 활성화하기

전제 조건:

프로젝트의 Maintainer 또는 Owner 역할이 있어야 해요.
.gitlab-ci.yml 파일이 머지 리퀘스트 파이프라인용으로 구성되어 있어야 해요.
프로젝트가 GitLab에 호스팅되어 있어야 해요(GitHub나 Bitbucket 같은 외부 저장소가 아니어야 함).

프로젝트에서 병합 결과 파이프라인을 활성화하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾으세요.
왼쪽 사이드바에서 Settings > Merge requests를 선택하세요.
Merge options 아래에서 Enable merged results pipelines를 선택하세요.
Save changes를 선택하세요.

.gitlab-ci.yml 파일에서 머지 리퀘스트 파이프라인을 구성하지 않고 이 설정을 활성화하면, 머지 리퀘스트가 해결되지 않은 상태로 멈추거나 파이프라인이 드롭될 수 있어요.

문제 해결

병합 결과 파이프라인을 사용할 때 다음 문제가 발생할 수 있어요.

`rules:changes:compare_to`로 잡이나 파이프라인이 예기치 않게 실행될 때

머지 리퀘스트 파이프라인에서 rules:changes:compare_to를 사용하면 잡이나 파이프라인이 예기치 않게 실행될 수 있어요.

이 문제는 병합 결과 파이프라인이 비교의 기본으로 임시 병합 커밋을 사용하기 때문에 발생해요. 이 커밋에는 머지 리퀘스트 브랜치와 대상 브랜치 양쪽의 변경 사항이 포함되어 있어 규칙이 예기치 않게 트리거될 수 있어요.

예를 들어 머지 리퀘스트가 src/feature.js를 추가하고 대상 브랜치에 src/utils.js가 있다면, 임시 병합 커밋에는 두 파일이 모두 포함돼요. rules:changes:compare_to: main 규칙은 내 기능 파일뿐 아니라 두 변경 사항을 모두 감지해서, 내 변경 사항에 대해서만 실행되어야 할 잡을 트리거할 수 있어요.

이 문제를 해결하려면:

기본 비교 동작을 사용하려면 compare_to 파라미터를 제거하세요.
changes 규칙에서 더 구체적인 파일 경로 패턴을 사용하세요.
compare_to 없이 rules:changes를 사용하는 것을 고려하세요.

성공한 병합 결과 파이프라인이 실패한 브랜치 파이프라인을 덮어쓸 때

Pipelines must succeed 설정이 활성화되면 실패한 브랜치 파이프라인이 무시되는 상황이 발생할 수 있어요.

이 문제는 파이프라인 로직 우선순위 때문에 발생해요. 개선 지원은 issue 385841에서 제안되어 있어요.

더 알아보기

다음으로는 머지 리퀘스트 파이프라인 문서와 머지 자동 완료 설정을 함께 보면, 병합 전 검증을 더 엄격하게 구성하는 방법을 익힐 수 있어요.