リポジトリチェック

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

GitLab UI を使ってプロジェクトのリポジトリをチェックします。

GitLab UI を使ってプロジェクトのリポジトリを確認します:

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、「概要」>「プロジェクト」を選択します。
  4. チェックするプロジェクトを選択します。
  5. リポジトリチェックセクションでリポジトリチェックをトリガーするを選択します。

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

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

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

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、[設定] > [リポジトリ] (/admin/application_settings/repository) を選択します。
  4. リポジトリメンテナンスセクションを展開します。
  5. リポジトリチェックを有効にします。

有効にすると、GitLabはすべてのプロジェクトリポジトリとWikiリポジトリに対して定期的にリポジトリチェックを実行し、データ破損の可能性を検出します。プロジェクトのチェックは月に1回までです。管理者はリポジトリチェックの頻度を設定できます。頻度を編集するには

  • Linux パッケージインストールの場合は、/etc/gitlab/gitlab.rbgitlab_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 を実行することができます。リポジトリを探すには

  1. リポジトリの保存場所に移動します:
    • Linux パッケージのインストールでは、リポジトリはデフォルトで/var/opt/gitlab/git-data/repositories ディレクトリに保存されます。
    • GitLab Helmチャートのインストールでは、リポジトリはデフォルトでGitalyポッド内の/home/git/repositories ディレクトリに保存されます。
  2. 確認したいリポジトリがあるサブディレクトリを特定します。
  3. チェックを実行します。例えば

    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ポッドで。

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

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、[設定] > [リポジトリ] (/admin/application_settings/repository) を選択します。
  4. リポジトリメンテナンスセクションを展開します。
  5. 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 オプションを使用してこれらのメッセージを抑制してください。