Merge Request 문제 해결

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

Merge Request 작업 시 다음과 같은 문제가 발생할 수 있습니다.

Merge Request에서 파이프라인 상태를 검색할 수 없음

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

Sidekiq

Sidekiq가 CI 상태 변경을 충분히 빨리 처리하지 않았습니다. 잠시 기다린 후 상태가 자동으로 업데이트됩니다.

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

Merge Request 파이프라인 상태는 다음과 같은 경우에 검색되지 않을 수 있습니다:

  1. Merge Request이 생성됨
  2. Merge Request이 닫힘
  3. 프로젝트에서 변경 사항이 발생함
  4. Merge Request이 다시 열림

파이프라인 상태를 올바르게 검색하려면 Merge Request을 다시 닫고 열어야 합니다.

Rails 콘솔에서 Merge Request을 리베이스

Tier: Free, Premium, Ultimate

/rebase 빠른 작용 외에도 Rails 콘솔에 액세스할 수 있는 사용자는 Rails 콘솔에서 Merge Request을 리베이스할 수 있습니다. <username>, <namespace/project>, <iid>를 적절한 값으로 대체하세요:

caution
데이터를 직접 변경하는 모든 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우에 치명적일 수 있습니다. 이러한 경우를 대비하여 테스트 환경에서 실행하고 복원할 수 있는 인스턴스 백업이 준비되어 있는 것을 강력히 권장합니다.
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)

잘못된 Merge Request 상태 수정

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

Merge Request이 변경 사항이 Merge된 후에도 열림 상태로 유지된 경우, Rails 콘솔에 액세스할 수 있는 사용자는 Merge Request의 상태를 수정할 수 있습니다. <username>, <namespace/project>, <iid>를 적절한 값으로 대체하세요:

caution
데이터를 직접 변경하는 모든 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우에 치명적일 수 있습니다. 이러한 경우를 대비하여 테스트 환경에서 실행하고 복원할 수 있는 인스턴스 백업이 준비되어 있는 것을 강력히 권장합니다.
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)

Merge되지 않은 변경 사항이 있는 Merge Request에 대해 이 명령을 실행하면 Merge Request에 잘못된 메시지가 표시됩니다: merged into <branch-name>.

Rails 콘솔에서 Merge Request을 닫음

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

Merge Request을 UI나 API를 통해 닫을 수 없는 경우 Rails 콘솔 세션에서 닫기를 시도할 수 있습니다:

caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우에 치명적일 수 있습니다. 항상 명령을 먼저 테스트 환경에서 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.
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)

Rails 콘솔에서 Merge Request 삭제

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

Merge Request을 UI나 API를 통해 삭제할 수 없는 경우 Rails 콘솔 세션에서 삭제를 시도할 수 있습니다:

caution
데이터를 직접 변경하는 모든 명령은 올바르게 실행되지 않거나 올바른 조건에서 실행되지 않을 경우에 치명적일 수 있습니다. 이러한 경우를 대비하여 테스트 환경에서 실행하고 복원할 수 있는 인스턴스 백업이 준비되어 있는 것을 강력히 권장합니다.
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)

Merge Request pre-receive 후크 실패

Merge Request이 시간 초과되면 Puma 워커 시간 초과 문제가 발생할 수 있습니다:

  • GitLab UI에서: 

    Merge pre-receive 후크 중에 문제가 발생했습니다.
500 Internal Server Error. 다시 시도하세요.

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

    Rack::Timeout::RequestTimeoutException
요청이 60000ms 이상 실행되었습니다

이 오류는 Merge Request이 다음과 같은 경우에 발생할 수 있습니다:

  • 많은 차이가 있는 경우
  • 대상 브랜치보다 많은 커밋이 있는 경우
  • 잠긴 Git LFS 파일을 참조하는 경우

Self-Managed형 설치 사용자는 오류의 원인을 확인하기 위해 관리자 검토 서버 로그를 요청할 수 있습니다. GitLab SaaS 사용자는 도움이 필요한 경우 지원팀에 문의할 수 있습니다.

캐시된 Merge Request 카운트

그룹에서 측면 표시줄에 열린 Merge Request의 총 수를 표시합니다. 이 값이 1000보다 크면 캐시됩니다. 캐시된 값은 천 단위(또는 백만 단위)로 반올림되어 24시간마다 업데이트됩니다.

head ref를 통해 로컬로 Merge Request 확인

-Merge Request이 닫힌 후 14일이 지난 head ref를 삭제합니다. (Self-Managed 및 GitLab.com에서 활성화) - GitLab 16.4에 추가되었습니다. -Merge Request이 닫힌 후 14일이 지난 head ref를 삭제합니다 일반적으로 사용 가능 - GitLab 16.6에 추가되었습니다. 피처 플래그 merge_request_refs_cleanup가 제거되었습니다.

Merge Request은 리포지터리의 모든 이력과 Merge Request과 관련된 브랜치에 추가된 추가 커밋을 포함합니다. 여기에는 로컬에서 Merge Request을 확인하는 몇 가지 방법이 나와 있습니다.

원본 프로젝트가 대상 프로젝트의 포크(비공개 포크일지라도)인 경우에도 Merge Request head ref(refs/merge-requests/:iid/head)에 의존합니다. 이를 통해 브랜치 대신 ID를 사용하여 Merge Request을 확인할 수 있습니다.

GitLab 16.6 이상에서는 Merge Request head ref가 닫힌 후 14일 후에 삭제됩니다. Merge Request은 더 이상 Merge Request head ref로부터 로컬로 확인할 수 없게 됩니다. Merge Request을 다시 열 수 있습니다. Merge Request의 브랜치가 여전히 존재하는 경우 영향을 받지 않으므로 여전히 브랜치를 확인할 수 있습니다.

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

다음 별칭을 ~/.gitconfig에 추가합니다: 

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

이제 원하는 리포지터리와 원격에서 특정 Merge Request을 확인할 수 있습니다. 예를 들어, GitLab에서 ID 5의 Merge Request을 확인하려면 다음을 실행하세요: 

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/*

이제 다음 명령으로 모든 Merge Request을 가져올 수 있습니다: 

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
...

원하는 Merge Request을 확인하려면: 

git checkout origin/merge-requests/1

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