- GitLab UI を使ってプロジェクトのリポジトリをチェックします。
- すべてのプロジェクトのリポジトリチェックを有効にします。
- コマンドラインを使ってチェックを実行します。
- チェックに失敗した場合の対処法
- トラブルシューティング
リポジトリチェック
git fsck
を使って、リポジトリにコミットされたすべてのデータの整合性を確認することができます。GitLab 管理者は以下のことができます:
- プロジェクトに対して手動でこのチェックをトリガーします。
- すべてのプロジェクトでこのチェックが自動的に実行されるようにスケジュールします。
- コマンドラインからこのチェックを実行します。
- Git リポジトリをチェックするRake タスクを実行します。
git fsck
をすべてのリポジトリに対して実行し、リポジトリのチェックサムを生成することで、異なるサーバー上のリポジトリを比較することができます。
GitLab UI を使ってプロジェクトのリポジトリをチェックします。
GitLab UI を使ってプロジェクトのリポジトリを確認します:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、「概要」>「プロジェクト」を選択します。
- チェックするプロジェクトを選択します。
- リポジトリチェックセクションで、リポジトリチェックをトリガーするを選択します。
チェックは非同期で実行されるため、チェック結果が管理エリアのプロジェクトページに表示されるまで数分かかる場合があります。チェックに失敗した場合は、どうすればよいかを参照してください。
すべてのプロジェクトのリポジトリチェックを有効にします。
リポジトリを手動でチェックする代わりに、GitLabは定期的にチェックを実行するように設定することができます:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、[設定] > [リポジトリ] (
/admin/application_settings/repository
) を選択します。 - リポジトリメンテナンスセクションを展開します。
- リポジトリチェックを有効にします。
有効にすると、GitLabはすべてのプロジェクトリポジトリとWikiリポジトリに対して定期的にリポジトリチェックを実行し、データ破損の可能性を検出します。プロジェクトのチェックは月に1回までです。管理者はリポジトリチェックの頻度を設定できます。頻度を編集するには
- Linux パッケージインストールの場合は、
/etc/gitlab/gitlab.rb
のgitlab_rails['repository_check_worker_cron']
を編集します。 - ソースベースのインストールの場合は、
/home/git/gitlab/config/gitlab.yml
の[gitlab.cron_jobs.repository_check_worker]
を編集してください。
リポジトリのチェックに失敗したプロジェクトがあると、すべての GitLab 管理者にその状況がメールで通知されます。デフォルトでは、この通知は週に一度、日曜日の午前0時に送信されます。
チェックに失敗したことが分かっているリポジトリは、/admin/projects?last_repository_check_failed=1
で確認できます。
コマンドラインを使ってチェックを実行します。
Gitalyサーバー上のリポジトリに対して、コマンドラインを使用してgit fsck
を実行することができます。リポジトリを探すには
- リポジトリの保存場所に移動します:
- Linux パッケージのインストールでは、リポジトリはデフォルトで
/var/opt/gitlab/git-data/repositories
ディレクトリに保存されます。 - GitLab Helmチャートのインストールでは、リポジトリはデフォルトでGitalyポッド内の
/home/git/repositories
ディレクトリに保存されます。
- Linux パッケージのインストールでは、リポジトリはデフォルトで
- 確認したいリポジトリがあるサブディレクトリを特定します。
-
チェックを実行します。例えば
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
。
チェックに失敗した場合の対処法
リポジトリのチェックに失敗した場合、ディスク上のrepocheck.log
ファイル でエラーの場所を確認してください:
-
/var/log/gitlab/gitlab-rails
Linux パッケージインストール用。 -
/home/git/gitlab/log
セルフコンパイルインストールの場合。 -
/var/log/gitlab
GitLab Helmチャートインストール用のSidekiqポッドで。
定期的なリポジトリチェックが誤報を引き起こす場合は、すべてのリポジトリチェックの状態をクリアすることができます:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、[設定] > [リポジトリ] (
/admin/application_settings/repository
) を選択します。 - リポジトリメンテナンスセクションを展開します。
- 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
古い場合に発生します。commit-graph
キャッシュは commit-graph
補助的なキャッシュであり、通常の Git オペレーションには必要ありません。
このメッセージは無視しても問題ありませんが、イシューエラーをご覧ください:詳細は issue error:Could not read from object database for commit-graphを参照ください。
コミット、タグ、ブロブメッセージのぶら下がり
リポジトリチェック出力には、刈り込みが必要なタグ、ブロブ、コミットが含まれていることがよくあります:
dangling tag 5c6886c774b713a43158aae35c4effdb03a3ceca
dangling blob 3e268c23fcd736db92e89b31d9f267dd4a50ac4b
dangling commit 919ff61d8d78c2e3ea9a32701dff70ecbefdd1d7
Git リポジトリではよくあることです。ブランチへの強制プッシュのようなオペレーションで発生するもので、リポジトリ内に ref や他のコミットで参照されなくなったコミットが発生するからです。
リポジトリのチェックに失敗すると、このような警告が出力されることになります。
これらのメッセージは無視し、他の出力からリポジトリチェック失敗の根本原因を特定してください。
GitLab 15.8 以降では、これらのメッセージをチェックの出力に含めなくなりました。コマンドラインから実行する場合は、--no-dangling
オプションを使用してこれらのメッセージを抑制してください。