git fsck를 사용하여 리포지터리에 커밋된 모든 데이터의 무결성을 확인할 수 있습니다. GitLab 관리자는:

• 프로젝트에 대해 이 검사를 수동으로 트리거할 수 있습니다.
• 모든 프로젝트에 대해 자동으로 실행되도록 이 검사를 예약할 수 있습니다.
• 명령줄에서 이 검사를 실행할 수 있습니다.
• git fsck를 모든 리포지터리에 대해 실행하고 리포지터리 체크섬을 생성하는 Rake 작업을 실행할 수 있으며, 이는 서로 다른 서버의 리포지터리를 비교하는 방법으로 사용할 수 있습니다.

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

GitLab UI를 사용하여 프로젝트의 리포지터리 검사 {#check-a-projects-repository-using-gitlab-ui}#

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

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
2. Overview > Projects를 선택합니다.
3. 검사할 프로젝트를 선택합니다.
4. Repository check 섹션에서 Trigger repository check를 선택합니다.

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

모든 프로젝트에 대한 리포지터리 검사 활성화 {#enable-repository-checks-for-all-projects}#

리포지터리를 수동으로 검사하는 대신 GitLab이 주기적으로 검사를 실행하도록 구성할 수 있습니다:

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
2. Settings > Repository를 선택합니다.
3. Repository maintenance를 펼칩니다.
4. Enable repository checks를 활성화합니다.

활성화되면 GitLab은 모든 프로젝트 리포지터리와 위키 리포지터리에서 가능한 데이터 손상을 감지하기 위해 주기적으로 리포지터리 검사를 실행합니다. 프로젝트는 한 달에 한 번 이상 검사되지 않으며 새 프로젝트는 24시간 이상 검사되지 않습니다.

GitLab Self-Managed 관리자는 리포지터리 검사 빈도를 구성할 수 있습니다. 빈도를 편집하려면:

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

프로젝트가 리포지터리 검사에 실패하면 모든 GitLab 관리자가 상황에 대한 이메일 알림을 받습니다. 기본적으로 이 알림은 일요일 자정에 주 1회 전송됩니다.

알려진 검사 실패가 있는 리포지터리는 /admin/projects?last_repository_check_failed=true에서 찾을 수 있습니다.

명령줄을 사용하여 검사 실행 {#run-a-check-using-the-command-line}#

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)을 사용하여 명령을 실행하고 있다는 것을 의미합니다.

검사가 실패한 경우 수행할 작업 {#what-to-do-if-a-check-failed}#

리포지터리 검사가 실패하면 다음 위치의 디스크에서 repocheck.log 파일에서 오류를 찾습니다:

• Linux 패키지 설치의 경우 /var/log/gitlab/gitlab-rails.
• 자체 컴파일 설치의 경우 /home/git/gitlab/log.
• GitLab Helm 차트 설치의 경우 Sidekiq 파드의 /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를 참조하세요.

댕글링 커밋, 태그 또는 blob 메시지#

리포지터리 검사 출력에는 정리가 필요한 태그, blob 및 커밋이 포함되는 경우가 많습니다:

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

이는 Git 리포지터리에서 흔히 발생합니다. 브랜치에 강제 푸시와 같은 작업으로 인해 생성되며, 이로 인해 ref나 다른 커밋에서 더 이상 참조되지 않는 커밋이 리포지터리에 생성됩니다.

리포지터리 검사가 실패하면 출력에 이러한 경고가 포함될 수 있습니다.

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

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