저장소 확인

세부 정보: Tier: Free, Premium, Ultimate Offering: Self-managed

이 저장소에 커밋된 모든 데이터의 무결성을 확인하려면 git fsck를 사용할 수 있습니다. GitLab 관리자는 다음을 수행할 수 있습니다:

명령줄에서 수동으로 실행되지 않는 확인은 Gitaly 노드를 통해 실행됩니다. Gitaly 저장소 일관성 확인, 일부 비활성화된 확인 및 일관성 확인을 구성하는 방법에 대한 정보는 저장소 일관성 확인을 참조하십시오.

GitLab UI를 사용하여 프로젝트 저장소 확인

GitLab UI를 사용하여 프로젝트 저장소를 확인하려면 다음 단계를 따릅니다:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택합니다.
  2. 개요 > 프로젝트를 선택합니다.
  3. 확인할 프로젝트를 선택합니다.
  4. 저장소 확인 섹션에서 저장소 확인 트리거를 선택합니다.

확인은 비동기적으로 실행되므로 관리 영역의 프로젝트 페이지에서 확인 결과가 표시되기까지 몇 분이 걸릴 수 있습니다. 확인이 실패하면 해야 할 일을 참조하십시오.

모든 프로젝트에 대해 저장소 확인 설정

수동으로 저장소를 확인하는 대신 GitLab을 구성하여 주기적으로 확인을 실행할 수 있습니다:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택합니다.
  2. 설정 > 저장소를 선택합니다.
  3. 저장소 유지 관리를 확장합니다.
  4. 저장소 확인 사용을 활성화합니다.

활성화되면 GitLab은 모든 프로젝트 저장소와 위키 저장소에 대해 가능한 데이터 손상을 감지하기 위해 주기적으로 저장소 확인을 실행합니다. 프로젝트는 한 달에 한 번 이상 확인됩니다. 관리자는 저장소 확인의 빈도를 구성할 수 있습니다. 빈도를 편집하려면:

  • Linux 패키지 설치의 경우 /etc/gitlab/gitlab.rb에서 gitlab_rails['repository_check_worker_cron']을 편집합니다.
  • 소스 기반 설치의 경우 /home/git/gitlab/config/gitlab.yml의 [gitlab.cron_jobs.repository_check_worker]을 편집합니다.

만일 어떤 프로젝트의 저장소 확인이 실패하면, 기본적으로 GitLab 관리자는 매주 일요일 시작의 자정에 상황에 대한 이메일 통지를 받게 됩니다.

알려진 확인 실패가 발생한 저장소는 /admin/projects?last_repository_check_failed=1에서 확인할 수 있습니다.

명령줄을 사용하여 확인 실행

명령줄에서 Gitaly 서버에 있는 저장소에서 git fsck를 실행할 수 있습니다. 저장소를 찾으려면:

  1. 저장소 저장 위치로 이동합니다.
    • Linux 패키지 설치의 경우 기본적으로 저장소가 /var/opt/gitlab/git-data/repositories 디렉터리에 저장됩니다.
    • GitLab Helm 차트 설치의 경우 기본적으로 Gitaly 팟 내의 /home/git/repositories 디렉터리에 저장됩니다.
  2. 확인해야 할 저장소를 포함하는 하위 디렉터리를 찾습니다.

  3. 확인을 실행합니다. 예를 들면: 

    sudo -u git /opt/gitlab/embedded/bin/git \
   -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck --no-dangling

    에러 fatal: detected dubious ownership in repository가 발생하면 커맨드를 잘못된 계정으로 실행하고 있는 상황입니다. 예를 들어, root 계정으로 실행 중인 경우입니다.

확인 실패 시 대처 방법

만일 저장소 확인이 실패하면, 디스크의 repocheck.log 파일에서 오류의 위치를 찾아야 합니다:

  • Linux 패키지 설치의 경우 /var/log/gitlab/gitlab-rails에 저장됩니다.
  • 소스 기반으로 설치한 경우 /home/git/gitlab/log에 저장됩니다.
  • GitLab Helm 차트 설치의 경우 Sidekiq 팟 내의 /var/log/gitlab에 저장됩니다.

주기적인 저장소 확인이 잘못된 경보를 유발하는 경우, 모든 저장소 확인 상태를 지울 수 있습니다:

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역을 선택합니다.
  2. 설정 > 저장소를 선택합니다.
  3. 저장소 유지 관리를 확장합니다.
  4. 모든 저장소 확인 지우기를 선택합니다.

문제 해결

저장소 확인 작업 시 다음과 같은 문제가 발생할 수 있습니다.

오류: failed to parse commit <commit SHA> from object database for commit-graph

저장소 확인 로그에서 failed to parse commit <commit SHA> from object database for commit-graph 오류를 볼 수 있습니다. 이 오류는 commit-graph 캐시가 오래된 경우 발생합니다. commit-graph 캐시는 보조 캐시로 정기적인 Git 작업에 필요하지 않습니다.

이 메시지는 무시해도 되지만 자세한 내용은 error: Could not read from object database for commit-graph 문제를 참조하십시오.

떨어진 커밋, 태그 또는 블롭 메시지

리포지토리 검사 결과에는 종종 가비지 컬렉션할 필요가 있는 태그, 블롭, 및 커밋이 포함됩니다. 

dangling tag 5c6886c774b713a43158aae35c4effdb03a3ceca
dangling blob 3e268c23fcd736db92e89b31d9f267dd4a50ac4b
dangling commit 919ff61d8d78c2e3ea9a32701dff70ecbefdd1d7

Git 리포지토리에서 이런 현상은 흔합니다. 이는 브랜치에 강제 푸시 등의 작업으로 생성됩니다. 이로 인해 리포지토리에 커밋이 생성되지만 다른 참조나 커밋에 의해 더 이상 참조되지 않는 경우입니다.

리포지토리 검사에 실패하면, 결과에 이런 경고가 포함될 수 있습니다.

이러한 메시지를 무시하고, 리포지토리 검사 실패의 원인을 찾을 수 있는 다른 결과를 확인하세요.

GitLab 15.8 및 이후에서 이러한 메시지가 더 이상 검사 결과에 포함되지 않습니다. 명령줄에서 실행할 때 --no-dangling 옵션을 사용하여 이를 억제할 수 있습니다.