리포지터리 확인

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 pod 내의 /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 pod의 /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) 커밋, 태그 또는 블롭 메시지

리포지터리 체크 출력에는 종료해야 하는 태그, 블롭 및 커밋이 포함될 수 있습니다: 

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

이것은 Git 리포지터리에서 일반적입니다. 브랜치로 강제 푸싱하는 등의 작업으로 인해 리포지터리에 커밋이 참조되지 않는 커밋이 생성됩니다.

리포지터리 체크가 실패하면 해당 경고가 출력에 포함될 확률이 높습니다. 이러한 메시지를 무시하고 다른 출력에서 리포지터리 체크 실패의 원인을 식별하십시오.

GitLab 15.8 후 버전은 더 이상 이러한 메시지를 체크 출력에 포함시킵니다. 명령줄에서 실행할 때 --no-dangling 옵션을 사용하여 이러한 메시지를 억제합니다.