리포지터리 검사

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 문제를 참조하십시오.

둥글 커밋, 태그 또는 블롭 메시지

리포지터리 검사 출력에는 물방울 태그, 블롭 및 커밋 메시지가 포함될 수 있습니다: 

물방울 태그 5c6886c774b713a43158aae35c4effdb03a3ceca
물방울 블롭 3e268c23fcd736db92e89b31d9f267dd4a50ac4b
물방울 커밋 919ff61d8d78c2e3ea9a32701dff70ecbefdd1d7

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

리포지터리 검사 실패시 출력에 이러한 경고가 포함되어 있을 가능성이 높습니다.

이러한 메시지를 무시하고 다른 출력에서 검사 실패의 근본 원인을 식별합니다.

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