병합 결과 파이프라인

머지 전에 소스 브랜치와 대상 브랜치의 코드를 결합하여 테스트하는 병합 결과 파이프라인을 설명합니다.

병합 결과 파이프라인은 소스 브랜치와 대상 브랜치의 코드를 결합한 임시 병합 커밋을 테스트합니다. 이 커밋은 두 브랜치 중 어디에도 존재하지 않지만 파이프라인 세부 정보에서 확인할 수 있습니다. 이 접근 방식은 변경 사항이 최신 대상 브랜치의 코드와 함께 작동하는지 확인하고, 머지 전에 통합 문제를 찾아내며, 다른 파일의 변경 사항이 함께 작동하는지 확인하는 데 도움이 됩니다. 대상 브랜치에 소스 브랜치의 변경 사항과 충돌하는 변경 사항이 있을 때 병합 결과 파이프라인을 실행할 수 없습니다. 이 경우 GitLab은 표준 머지 리퀘스트 파이프라인을 실행합니다. 병합 결과 파이프라인 활성화 # 전제 조건: 프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다. .gitlab-ci.yml 파일이 머지 리퀘스트 파이프라인 에 대해 구성되어 있어야 합니다. 프로젝트가 GitLab에 호스팅되어 있어야 합니다(GitHub 또는 Bitbucket과 같은 외부 저장소가 아닌). 프로젝트에서 병합 결과 파이프라인을 활성화하려면: 상단 바에서 검색 또는 이동 을 선택하고 프로젝트를 찾습니다. 설정 > 머지 리퀘스트 를 선택합니다. 머지 옵션 아래에서 병합 결과 파이프라인 활성화 를 선택합니다. 변경 사항 저장 을 선택합니다. Warning .gitlab-ci.yml 파일에서 머지 리퀘스트 파이프라인을 구성하지 않고 이 설정을 활성화하면 머지 리퀘스트가 해결되지 않은 상태로 멈추거나 파이프라인이 삭제될 수 있습니다. 문제 해결 # 병합 결과 파이프라인을 사용할 때 다음과 같은 문제가 발생할 수 있습니다. rules:changes:compare_to 를 사용할 때 job 또는 파이프라인이 예상치 않게 실행됨 # 머지 리퀘스트 파이프라인과 함께 rules:changes:compare_to 를 사용할 때 job 또는 파이프라인이 예상치 않게 실행될 수 있습니다. 이 문제는 병합 결과 파이프라인이 비교의 기반으로 임시 병합 커밋을 사용하기 때문에 발생합니다. 이 커밋에는 머지 리퀘스트 브랜치와 대상 브랜치 모두의 변경 사항이 포함되어 있어 규칙이 예상치 않게 트리거될 수 있습니다. 예를 들어 머지 리퀘스트가 src/feature.js 를 추가하고 대상 브랜치에 src/utils.js 가 포함되어 있으면 임시 병합 커밋에 두 파일이 모두 포함됩니다. rules:changes:compare_to: main 이 있는 규칙은 기능 파일만이 아닌 두 변경 사항을 모두 감지하여 변경 사항에만 실행되어야 하는 job을 트리거할 수 있습니다. 이 문제를 해결하려면: 기본 비교 동작을 사용하려면 compare_to 매개변수를 제거합니다. 변경 규칙에서 더 구체적인 파일 경로 패턴을 사용합니다. compare_to 없이 rules:changes 를 사용하는 것을 고려합니다. 성공한 병합 결과 파이프라인이 실패한 브랜치 파이프라인을 재정의함 # 파이프라인이 성공해야 함 설정 이 활성화된 경우 실패한 브랜치 파이프라인이 무시되는 상황이 발생할 수 있습니다. 이 문제는