リポジトリチェック

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed、GitLab Dedicated

リポジトリにコミットされたすべてのデータの整合性を確認するには、git fsckを使用できます。GitLab管理者は、次のことができます:

プロジェクトのこのチェックを手動でトリガーする。
すべてのプロジェクトに対して自動的に実行されるように、このチェックをスケジュールします。
コマンドラインからこのチェックを実行します。
GitリポジトリをチェックするためのRakeタスクを実行します。これは、すべてのリポジトリに対してgit fsckを実行し、リポジトリのチェックサムを生成し、異なるサーバー上のリポジトリを比較する方法として使用できます。

コマンドラインで手動で実行されないチェックは、Gitalyノードを介して実行されます。Gitalyリポジトリの一貫性チェック、一部の無効なチェック、および一貫性チェックの構成方法については、リポジトリの一貫性チェックを参照してください。

GitLab UIを使用したプロジェクトのリポジトリのチェック

GitLab UIを使用してプロジェクトのリポジトリをチェックするには、次の手順を実行します:

左側のサイドバーの下部で、管理者を選択します。
概要 > プロジェクトを選択します。
チェックするプロジェクトを選択します。
リポジトリチェックセクションで、リポジトリチェックをトリガーを選択します。

チェックは非同期で実行されるため、プロジェクトページの管理者エリアにチェック結果が表示されるまでに数分かかる場合があります。チェックが失敗した場合は、対処方法を参照してください。

すべてのプロジェクトのリポジトリチェックを有効にする

リポジトリを手動でチェックする代わりに、定期的にチェックを実行するようにGitLabを構成できます:

左側のサイドバーの下部で、管理者を選択します。
設定 > リポジトリを選択します。
リポジトリの保守を展開します。
リポジトリチェックを有効にするを有効にします。

有効にすると、GitLabはすべてのプロジェクトリポジトリとWikiリポジトリでリポジトリチェックを定期的に実行して、発生する可能性のあるデータ破損を検出します。プロジェクトがチェックされるのは月に1回までで、新しいプロジェクトは少なくとも24時間はチェックされません。

GitLab Self-Managed管理者は、リポジトリチェックの頻度を設定できます。頻度を編集するには:

Linuxパッケージインストールの場合は、gitlab_rails['repository_check_worker_cron']の/etc/gitlab/gitlab.rbを編集してください。
ソースベースのインストールの場合、/home/git/gitlab/config/gitlab.ymlの[gitlab.cron_jobs.repository_check_worker]を編集します。

リポジトリチェックに失敗したプロジェクトがある場合、すべてのGitLab管理者は、状況に関するメール通知を受信します。デフォルトでは、この通知は、日曜日の開始時に週に1回深夜に送信されます。

チェックの失敗が確認されているリポジトリは、/admin/projects?last_repository_check_failed=trueにあります。

コマンドラインを使用してチェックを実行する

提供形態: GitLab Self-Managed

Gitalyサーバー上のリポジトリで、コマンドラインを使用してgit fsckを実行できます。リポジトリの場所を特定するには:

リポジトリのストレージの場所に移動します:
- Linuxパッケージインストールの場合、リポジトリはデフォルトで/var/opt/gitlab/git-data/repositoriesディレクトリに保存されます。
- GitLab Helmチャートインストールの場合、リポジトリはデフォルトでGitalyポッド内の/home/git/repositoriesディレクトリに保存されます。
チェックする必要があるリポジトリを含むサブディレクトリを特定します。
チェックを実行します。次に例を示します:
```
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などです。

チェックが失敗した場合の対処方法

提供形態: GitLab Self-Managed

リポジトリチェックが失敗した場合は、ディスク上のrepocheck.logファイルのエラーを次の場所で特定します:

Linuxパッケージインストールの場合: /var/log/gitlab/gitlab-rails。
自己コンパイルによるインストールの場合: /home/git/gitlab/log。
GitLab HelmチャートインストールのSidekiqポッドの/var/log/gitlab。

定期的なリポジトリチェックが誤ったアラームを引き起こす場合は、すべてのリポジトリチェック状態をクリアできます:

左側のサイドバーの下部で、管理者を選択します。
設定 > リポジトリを選択します。
リポジトリの保守を展開します。
すべてのリポジトリのチェックをクリアするを選択します。

トラブルシューティング

提供形態: GitLab Self-Managed

リポジトリチェックの操作中に、次の問題が発生する可能性があります。

エラー: `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操作には必要ありません。

メッセージは安全に無視できますが、詳細については、エラー：commit-graphのオブジェクトデータベースから読み取れませんでしたを参照してください。

Danglingコミット、タグ、またはバイナリラージオブジェクトメッセージ

リポジトリチェックの出力には、プルーニングする必要のあるタグ、バイナリラージオブジェクト、コミットが含まれていることがよくあります:

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

これはGitリポジトリでは一般的です。これらは、強制プッシュのような操作によって生成されます。これは、ブランチへの操作によって、refsまたは別のコミットによって参照されなくなったリポジトリにコミットが生成されるためです。

リポジトリチェックが失敗した場合、出力にこれらの警告が含まれる可能性があります。

これらのメッセージを無視して、他の出力からリポジトリチェックの失敗の根本原因を特定します。

GitLab 15.8以降では、チェック出力にこれらのメッセージは含まれなくなりました。コマンドラインから実行する場合、--no-danglingオプションを使用して、それらを抑制します。