리포지토리 검사

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

모든 데이터의 무결성을 확인하기 위해 git fsck를 사용할 수 있습니다. GitLab 관리자는:

명령줄에서 수동으로 실행되지 않은 검사는 Gitaly 노드를 통해 실행됩니다. Gitaly 리포지토리 일관성 검사에 대한 정보, 일부 비활성화된 검사 및 일관성 검사 구성 방법에 대한 내용은 리포지토리 일관성 검사를 참조하세요.

GitLab UI를 사용하여 프로젝트의 리포지토리 검사

GitLab UI를 사용하여 프로젝트의 리포지토리를 검사하려면:

  1. 왼쪽 사이드바에서 하단으로 이동하여 Admin을 선택합니다.
  2. 개요 > 프로젝트를 선택합니다.
  3. 검사할 프로젝트를 선택합니다.
  4. 리포지토리 검사 섹션에서 리포지토리 검사 트리거를 선택합니다.

검사는 비동기적으로 실행되므로 검사 결과가 Admin 영역의 프로젝트 페이지에 표시되기까지 몇 분이 걸릴 수 있습니다. 검사가 실패하면 해야 할 일을 참조하세요.

모든 프로젝트에 대한 리포지토리 검사 활성화

리포지토리를 수동으로 검사하는 대신, GitLab을 구성하여 주기적으로 검사를 실행할 수 있습니다:

  1. 왼쪽 사이드바에서 하단으로 이동하여 Admin을 선택합니다.
  2. 설정 > 리포지토리를 선택합니다.
  3. 리포지토리 유지 관리를 확장합니다.
  4. 리포지토리 검사 활성화를 선택합니다.

활성화되면 GitLab은 모든 프로젝트 리포지토리 및 위키 리포지토리에 대해 주기적으로 리포지토리 검사를 실행하여 데이터 손상을 감지합니다. 프로젝트는 한 달에 한 번 이상 확인되지 않으며, 새로운 프로젝트는 최소 24시간 동안 검사를 받지 않습니다.

관리자는 리포지토리 검사의 빈도를 구성할 수 있습니다. 빈도를 편집하려면:

  • 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 pod의 /var/log/gitlab.

주기적인 리포지토리 체크로 인해 잘못된 경고가 발생하는 경우 모든 리포지토리 체크 상태를 지울 수 있습니다:

  1. 왼쪽 사이드바에서 맨 아래의 Admin를 선택합니다.
  2. Settings > Repository를 선택합니다.
  3. Repository maintenance를 확장합니다.
  4. Clear all repository checks를 선택합니다.

문제 해결

리포지토리 체크를 작업할 때 다음과 같은 문제를 만날 수 있습니다.

오류: 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 리포지토리에서 일반적입니다. 이는 브랜치에 강제 푸시와 같은 작업에서 생성되며, 이로 인해 참조(ref)나 다른 커밋으로 더 이상 참조되지 않는 커밋이 리포지토리에 생성됩니다.

리포지토리 체크가 실패하면, 출력에 이러한 경고가 포함될 가능성이 높습니다.

이 메시지를 무시하고 다른 출력에서 리포지토리 체크 실패의 근본 원인을 확인하세요.

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