☰

Gitlab repocheck는 매달린 얼룩을 찾아 텍스트를 실패한 것으로 표시합니다.

tag-icon • tag-icon git gitlab
Gitlab repocheck는 매달린 얼룩을 찾아 텍스트를 실패한 것으로 표시합니다.

자체 호스팅된 gitlab 인스턴스가 있는데 갑자기 내 프로젝트 중 하나에서 repo 확인이 실패했다는 이메일을 보냈습니다.

나는 gitlab-15.0.0-ee도커를 통해 실행합니다. 로그 파일을 확인해 보니 repocheck.log내용은 ​​이렇습니다.

E, [2022-06-07T19:08:10.599782 #435] ERROR -- : xxx/xxx: Could not fsck repository: dangling blob ed44e089d0eaf14fc152871bdca12aa6de01a5f1
dangling blob 4317819507d8e4e3ddcce6f3c01b8890e56cc157
dangling commit 2b1f190885dae6bbef0986cd50bc61c790331312
dangling blob 0f7c7218e71e1bd8b964184e149c214734d41944
dangling blob 6f16132326f43f1fd3a9a9cd717830643a162c8a
dangling commit 3b87a380a8095fe83fed257fd89e178323b89bea
dangling commit 14ca539d07483fc309f94cea685fc893a3efaf51
dangling commit 3cf64b574d2ecbc4ffe06559f9495db22bb5f2c9
dangling blob 535b94cb0a9048bbe45eb35ba53a02fe795be823
dangling commit 6778eef6143982b0d96f2934e515b36254e9a31f
dangling commit 0294e6bca9f2a5cacd7bbea61c62e5b5d92eb98f
dangling blob 4144f7437938ea8b0fe5ce6c8a498995b4f96f7c
dangling blob b64cd7abaa200ac4fea060b0dfb8542e260cb301
dangling blob 90545fea55b5e5c1f6245281ebac02b1dd8bfd04
error: Could not read 0957f8065b8fecfa80005eafa673a2a8b67ddbed
failed to parse commit 0957f8065b8fecfa80005eafa673a2a8b67ddbed from object database for commit-graph
error: Could not read 0a70090f6519febb2edbd9c416b5dff46d92d1a1
failed to parse commit 0a70090f6519febb2edbd9c416b5dff46d92d1a1 from object database for commit-graph
error: Could not read 126be254518dfd5b29a553fcfe7843787cbeed08
....

파일에는 커밋 그래프에 없는 커밋이 약 200개 더 있습니다.

내 로컬 저장소에는 대부분의 커밋이 여전히 존재하고 실제로 도달할 수 없으므로 git gc서버에서는 내 로컬 저장소에 여전히 존재하는 커밋을 제거했습니다. 병합 요청이 누락되지 않은 것 같아서 gitlab이 이것이 문제라고 생각하는 이유가 이해되지 않습니다.

슬프게도공식 문서repocheck.log파일을 찾거나 클릭하라고 지시하는 것 외에 무엇을 해야 하는지에 대해 매우 모호합니다.모든 저장소 검사 지우기오류가 지속되는 경우. 클릭한 후에도 전혀 도움이 되지 않습니다.모든 저장소 검사 지우기, 여전히 같은 오류가 발생합니다. 그렇다면 gitlab이 실제로 테스트하는 것은 무엇이며 왜 실패합니까?

답변1

  1. GitLab http://yourgitlab_link/admin/projects?last_repository_check_failed=1에서 받은 "GitLab 관리 패널에서 영향을 받은 프로젝트 보기" 링크에서 실패한 모든 리포지토리를 찾으세요.

  2. /var/log/gitlab/gitlab-rails/repocheck.log프로젝트 관리 영역에서 "트리거 저장소 확인"이 실행될 때 생성되는 파일을 확인합니다 . 파일이 비어 있으면 저장소 확인을 수동으로 다시 시작하십시오. 파일이 비어 있든 없든 이 단계는 그다지 중요하지 않습니다. 아래에 설명된 fsck 명령을 사용하면 유사한 출력을 얻을 수 있기 때문입니다.

  3. 특정 프로젝트 메뉴->관리->프로젝트->프로젝트를 열고 "Gitaly 상대 경로"를 검색하세요. @hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git

  4. docker 콘솔(컨테이너에 연결) 또는 Gitlab Omnibus Server 콘솔로 이동하여 해당 특정 저장소 명령에 대해 fsck 명령을 실행하세요.git옴니버스 설치 시 올바른 사용자로 명령을 실행하십시오.root그렇지 않으면 gitlab이 쓸 수 없는 소유자로 파일이 생성됩니다 .

    /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git fsck 다음과 같은 오류가 있는지 확인하십시오.

    error: Could not read 098b53ffbe581e25b… failed to parse commit 098b53ffbe581e25b… from object database for commit-graph

    이제 가비지 수집기 gc를 실행하세요.

    /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git gc

    fsck로 저장소를 다시 확인하십시오.

    /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git fsck 오류와 실패는 지워져야 합니다.

  5. 저장소 검사가 성공적으로 통과되었는지 확인하기 위해 "트리거 저장소 검사"를 다시 실행하십시오. 성공했다면 이 저장소는 저장소 검사를 통과하지 못한 저장소 목록(GitLab 관리 패널에서 영향을 받은 프로젝트 참조) 또는 http://yourgitlab_link/admin/projects?last_repository_check_failed=1에 있어서는 안 됩니다.

원천:https://forum.gitlab.com/t/gitlab-projects-failed-their-last-repository-check/19147/3

답변2

GitLab 문서를 참조하세요.
GitLab 관리 > ... > 리포지토리 검사 > 명령줄을 사용하여 검사 실행

(귀하의 설치에 가장 적합한 문서 버전을 선택하십시오)

관련 정보