병합 요청 문제 해결

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

병합 요청 작업 중 다음과 같은 문제가 발생할 수 있습니다.

병합 요청이 파이프라인 상태를 검색할 수 없음

이는 Sidekiq가 변경 사항을 빠르게 인지하지 못할 때 발생할 수 있습니다.

Sidekiq

Sidekiq가 CI 상태 변경을 빠르게 처리하지 못했습니다. 잠시 기다린 후 상태가 자동으로 업데이트됩니다.

파이프라인 상태를 검색할 수 없음

다음 사항이 발생할 때 병합 요청 파이프라인 상태를 검색할 수 없습니다:

  1. 병합 요청이 생성됨
  2. 병합 요청이 닫힘
  3. 프로젝트에서 변경이 이루어짐
  4. 병합 요청이 다시 열림

파이프라인 상태를 제대로 검색하려면 병합 요청을 다시 닫고 다시 열어야 합니다.

레일스 콘솔에서 병합 요청 다시베이스

Tier: Free, Premium, Ultimate

/rebase 빠른 조치 외에도 레일스 콘솔에 액세스할 수 있는 사용자는 레일스 콘솔에서 병합 요청을 다시베이스할 수 있습니다. <username>, <namespace/project>, <iid>를 적절한 값으로 바꿉니다:

경고: 직접 데이터를 변경하는 모든 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않는다면 피해를 줄 수 있습니다. 가능한 경우 테스트 환경에서 실행하고 백업된 인스턴스를 대비해 준비하는 것이 매우 권장됩니다. 

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)

잘못된 병합 요청 상태 수정

Tier: Free, Premium, Ultimate Offering: Self-managed, GitLab Dedicated

병합 요청의 변경 사항이 병합된 후에도 열림 유지될 경우 레일스 콘솔에 액세스할 수 있는 사용자는 병합 요청의 상태를 수정할 수 있습니다. <username>, <namespace/project>, <iid>를 적절한 값으로 바꿉니다:

경고: 직접 데이터를 변경하는 모든 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않는다면 피해를 줄 수 있습니다. 가능한 경우 테스트 환경에서 실행하고 백업된 인스턴스를 대비해 준비하는 것이 매우 권장됩니다. 

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)

이 명령은 아직 병합되지 않은 변경 사항이 있는 병합 요청에 대해 잘못된 메시지를 표시하게 합니다: 브랜치 이름으로 병합됨.

레일스 콘솔에서 병합 요청 닫음

Tier: Free, Premium, Ultimate Offering: Self-managed, GitLab Dedicated

UI 또는 API를 통해 병합 요청을 닫는 것이 작동하지 않는 경우, 레일스 콘솔 세션에서 닫으려고 시도할 수 있습니다:

경고: 데이터를 변경하는 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않는다면 피해를 줄 수 있습니다. 명령을 테스트 환경에서 실행하고 복원할 수 있는 백업 인스턴스를 대비해 항상 실행하십시오. 

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::CloseService.new(project: p, current_user: u).execute(m)

레일스 콘솔에서 병합 요청 삭제

Tier: Free, Premium, Ultimate Offering: Self-managed, GitLab Dedicated

UI 또는 API를 통해 병합 요청을 삭제하는 것이 작동하지 않는 경우, 레일스 콘솔 세션에서 삭제해 보세요:

경고: 직접 데이터를 변경하는 모든 명령은 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않는다면 피해를 줄 수 있습니다. 가능한 경우 테스트 환경에서 실행하고 백업된 인스턴스를 대비해 준비하는 것이 매우 권장됩니다. 

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
Issuable::DestroyService.new(container: m.project, current_user: u).execute(m)

병합 요청 프리-리시브 훅 실패

병합 요청이 시간 초과되면 Puma 워커 시간 초과 문제를 나타내는 메시지가 표시될 수 있습니다:

  • GitLab UI에서: 

    병합 전 리시브 후크 중에 문제가 발생했습니다.
500 Internal Server Error. 다시 시도하세요.

  • gitlab-rails/api_json.log 로그 파일에서: 

    Rack::Timeout::RequestTimeoutException
요청이 60000ms보다 긴 시간 동안 실행되었습니다

이 오류는 병합 요청이 다음과 같은 경우에 발생할 수 있습니다:

  • 많은 차이점을 포함합니다.
  • 대상 브랜치보다 많은 커밋이 있습니다.
  • 잠겨 있는 Git LFS 파일을 참조합니다.

Self-managed 설치에서는 관리자가 서버 로그를 검토하여 오류의 원인을 결정할 수 있습니다. GitLab SaaS 사용자는 도움이 필요한 경우 지원팀에 문의할 수 있습니다.

캐시된 병합 요청 수

그룹 내에서 사이드바에는 열려있는 병합 요청의 총 수가 표시됩니다. 이 값은 1000보다 큰 경우에는 캐시되며, 캐시된 값은 천 단위(또는 백만 단위)로 반올림되어 매일 업데이트됩니다.

head ref를 통해 로컬에서 병합 요청 확인

  • 병합 요청이 닫히거나 병합된 후 14일 후 head ref를 삭제함 (Self-Managed 및 GitLab.com에서 활성화됨) - GitLab 16.4.
  • 병합 요청이 닫히거나 병합된 후 14일 후 head ref를 삭제함 일반적으로 이용 가능 - GitLab 16.6. 기능 플래그 merge_request_refs_cleanup가 제거됨.

병합 요청에는 저장소의 모든 기록과 병합 요청과 관련된 브랜치에 추가된 추가 커밋이 포함됩니다. 로컬에서 병합 요청을 확인하는 몇 가지 방법을 살펴보겠습니다.

소스 프로젝트가 대상 프로젝트의 포크(비공개 포크도 가능)인 경우에도 로컬에서 병합 요청을 확인할 수 있습니다.

이 작업은 각 병합 요청에 대해 사용 가능한 병합 요청 head ref(refs/merge-requests/:iid/head)에 의존합니다. 이를 통해 브랜치 대신 ID를 사용하여 병합 요청을 확인할 수 있습니다.

GitLab 16.6 이상에서는 병합 요청 head ref가 닫히거나 병합된 후 14일 후 삭제됩니다. 그 후로는 더 이상 해당 병합 요청을 병합 요청 head ref를 통해 로컬로 확인할 수 없습니다. 병합 요청은 다시 열 수 있습니다. 병합 요청의 브랜치가 존재하는 경우에는 여전히 해당 브랜치를 확인할 수 있으며, 이는 영향을 받지 않습니다.

Git 별칭을 추가하여 로컬로 확인

다음 별칭을 ~/.gitconfig에 추가하십시오: 

[alias]
    mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -

이제 모든 저장소 및 모든 원격에서 특정 병합 요청을 확인할 수 있습니다. 예를 들어, GitLab에 표시된 ID가 5인 병합 요청을 origin 원격에서 확인하려면 다음을 실행하면 됩니다: 

git mr origin 5

이렇게 하면 병합 요청이 로컬 mr-origin-5 브랜치로 가져와져 확인됩니다.

.git/config 수정으로 로컬로 확인

.git/config 파일에서 GitLab 원격에 대한 섹션을 찾으십시오. 다음과 같이 보입니다: 

[remote "origin"]
  url = https://gitlab.com/gitlab-org/gitlab-foss.git
  fetch = +refs/heads/*:refs/remotes/origin/*

다음 명령으로 파일을 열 수 있습니다: 

git config -e

그런 다음 위 섹션에 다음 라인을 추가하십시오: 

fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

최종적으로 아래와 같이 보여야 합니다: 

[remote "origin"]
  url = https://gitlab.com/gitlab-org/gitlab-foss.git
  fetch = +refs/heads/*:refs/remotes/origin/*
  fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

이제 모든 병합 요청을 가져올 수 있습니다: 

git fetch origin

...
From https://gitlab.com/gitlab-org/gitlab-foss.git
 * [new ref]         refs/merge-requests/1/head -> origin/merge-requests/1
 * [new ref]         refs/merge-requests/2/head -> origin/merge-requests/2
...

그리고 특정 병합 요청을 확인하려면: 

git checkout origin/merge-requests/1

위 작업은 모두 git-mr 스크립트로 수행할 수 있습니다.