☰

Gitlab Repocheck findet baumelnde Blobs und markiert den Text als fehlgeschlagen

tag-icon • tag-icon git gitlab
Gitlab Repocheck findet baumelnde Blobs und markiert den Text als fehlgeschlagen

Ich habe eine selbstgehostete Gitlab-Instanz und plötzlich sendet mir eines meiner Projekte E-Mails mit der Meldung, dass die Repo-Prüfung fehlschlägt.

Ich verwende gitlab-15.0.0-eeDocker. Ich habe die Protokolldatei überprüft repocheck.logund das ist der Inhalt:

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
....

und die Datei hat etwa 200 weitere Commits, die nicht im Commit-Graphen vorhanden sind.

In meinem lokalen Repository sind die meisten dieser Commits noch vorhanden und tatsächlich nicht erreichbar. Daher wurden git gcdie Commits, die noch in meinem lokalen Repository vorhanden sind, auf dem Server entfernt. Mir scheinen keine Merge-Requests zu fehlen, daher ist es mir schleierhaft, warum Gitlab denkt, dass dies ein Problem ist.

Leideramtliche Dokumentationist sehr vage darüber, was zu tun ist, außer zu sagen, die repocheck.logDatei zu finden und oder auf zu klickenAlle Repository-Prüfungen löschenwenn der Fehler weiterhin besteht. Das hilft überhaupt nicht, denn auch nach einem Klick aufAlle Repository-Prüfungen löschen, ich erhalte immer noch denselben Fehler. Was testet Gitlab also eigentlich und warum schlägt es fehl?

Antwort1

  1. Finden Sie alle Repositories, bei denen der Link „Sehen Sie sich die betroffenen Projekte im GitLab-Admin-Panel an“ fehlgeschlagen ist, den Sie von GitLab erhalten haben http://yourgitlab_link/admin/projects?last_repository_check_failed=1

  2. Überprüfen Sie /var/log/gitlab/gitlab-rails/repocheck.logdie Datei, die generiert wird, wenn „Repository-Prüfung auslösen“ im Projektadministrationsbereich ausgelöst wird. Wenn die Datei leer ist, lösen Sie die Repository-Prüfung erneut manuell aus. Dieser Schritt ist nicht so wichtig, egal ob die Datei leer ist oder nicht, da Sie mit dem Befehl fsck, der etwas weiter unten beschrieben wird, eine ähnliche Ausgabe erhalten.

  3. Öffnen Sie das spezifische Projektmenü->Admin->Projekte->Ihr Projekt und suchen Sie nach „Gitaly relativer Pfad“ @hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git

  4. Gehen Sie zur Docker-Konsole (mit Container verbinden) oder zur Konsole des Gitlab Omnibus-Servers und führen Sie den Befehl fsck für diesen bestimmten Repository-Befehl aus.gitStellen Sie sicher, dass Sie den Befehl bei Omnibus-Installationen als korrekter Benutzer ausführen., andernfalls werden Dateien mit dem Besitzer erstellt root, in die Gitlab nicht schreiben kann:

    /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git fsck und prüfen Sie, ob Fehler vorliegen, wie

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

    Führen Sie nun den Garbage Collector gc aus mit

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

    und überprüfen Sie das Repository erneut mit fsck

    /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git fsck und Fehler und Ausfälle sollten behoben werden

  5. Führen Sie „Repository-Prüfung auslösen“ erneut aus, wenn die Repository-Prüfung erfolgreich war. Wenn sie erfolgreich war, sollte dieses Repository nicht in der Liste der Repositorys enthalten sein, die die Repository-Prüfung nicht bestanden haben (siehe die betroffenen Projekte im GitLab-Administrationsbereich) oder http://yourgitlab_link/admin/projects?last_repository_check_failed=1

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

Antwort2

Siehe die Dokumentation von GitLab:
GitLab verwalten > ... > Repository-Prüfungen > Eine Prüfung über die Kommandozeile ausführen

(Wählen Sie die Version der Dokumentation aus, die am besten zu Ihrer Installation passt)

verwandte Informationen