Gitlab repocheck はぶら下がっている BLOB を見つけ、テキストを失敗としてマークします

2024-11-1 • tag-icon

Gitlab repocheck はぶら下がっている BLOB を見つけ、テキストを失敗としてマークします

自己ホスト型の GitLab インスタンスを持っているのですが、突然、プロジェクトの 1 つからリポジトリチェックが失敗したというメールが届きました。

docker 経由で実行します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サーバー上の a によって、ローカルリポジトリにまだ存在するコミットが削除されました。マージリクエストが失われているようには見えないので、Gitlab がこれを問題だと考える理由がわかりません。

残念なことに公式文書ファイルの場所を指定するrepocheck.logかクリックする以外に何をするかについては非常に曖昧ですすべてのリポジトリチェックをクリアエラーが続く場合は、クリックしても何も解決しません。すべてのリポジトリチェックをクリア、まだ同じエラーが発生します。では、gitlab は実際に何をテストしていて、なぜ失敗するのでしょうか?

答え1

GitLab から受け取ったリンク「GitLab 管理パネルで影響を受けるプロジェクトを確認する」で失敗したすべてのリポジトリを検索します http://yourgitlab_link/admin/projects?last_repository_check_failed=1
プロジェクト管理領域で「リポジトリチェックをトリガー」がトリガーされたときに生成されるファイルを確認します/var/log/gitlab/gitlab-rails/repocheck.log。ファイルが空の場合は、リポジトリチェックを手動で再度トリガーします。この手順は、ファイルが空であるかどうかに関係なく、それほど重要ではありません。これは、少し下で説明するコマンド fsck で同様の出力が得られるためです。
特定のプロジェクトメニュー->管理->プロジェクト->プロジェクトを開き、「Gitaly相対パス」を検索します。 @hashed/48/b3/48b361d46638bfa4eee090c158a750a69c7beec3a62e703e2801125551b1b157.git
docker コンソール (コンテナに接続) または Gitlab Omnibus Server のコンソールに移動し、特定のリポジトリコマンドで fsck コマンドを実行します。gitOmnibusインストールでは必ず正しいユーザーとしてコマンドを実行してください。それ以外の場合、ファイルは所有者で作成され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 エラーや失敗はクリアされる必要がある
リポジトリチェックが正常に完了したかどうかをチェックするために、「リポジトリチェックをトリガー」を再度実行します。成功した場合、このリポジトリはリポジトリチェックに合格しなかったリポジトリリストに含まれていないはずです (GitLab 管理パネルで影響を受けるプロジェクトを確認してください)。または http://yourgitlab_link/admin/projects?last_repository_check_failed=1