リポジトリのミラーリング

ディープダイブ

2018年12月、Tiago BotelhoはGitLabPull Repository Mirroring機能に関するDeep Dive（GitLabチームメンバー限定：https://gitlab.com/gitlab-org/create-stage/-/issues/1 ）を開催し、将来コードベースのこの部分に携わる可能性のある人に彼のドメイン固有の知識を共有しました。詳しくは 録画は YouTube で、スライドはPDF で見ることができます。このディープダイブで取り上げた内容はすべて GitLab 11.6 の時点でのもので、それ以降に具体的な詳細が変更されている可能性がありますが、それでも良い入門書として役立つはずです。

ミラーリングプロセスの説明

GitLabバージョン14は、APIコールがプルミラーをトリガーしたときに以下のステップを実行します。スケジュールされたミラーの更新も同様ですが、APIコールでは始まりません：

  1. リクエストは API 呼び出しから発生し、project_mirror.rbのstart_pull_mirroring_service をトリガーします。
  2. プルミラーリングサービス(start_pull_mirroring_service.rb)が開始します。プロジェクトの状態が更新され、ジョブが直ちに開始されます。
  3. プロジェクトのインポート状態が更新され、project_import_state.rbのupdate_all_mirrors_worker がトリガーされます。
  4. update all mirrors ワーカー (update_all_mirrors_worker.rb) は、project_import_schedule ワーカーを呼び出すことで、スタンプを回避しようとします。
  5. プロジェクトインポートスケジュールワーカー (project_import_schedule_worker.rb) は、プロジェクトの状態を更新し、インポート遷移プロセスを管理するために Rubystate_machine を起動します。
  6. プロジェクトの状態を更新する間、 project.rb のこの呼び出しはrepository_update_mirror ワーカーを起動します。
  7. Sidekiqバックグラウンドミラーワーカー(repository_update_mirror_worker.rb)はミラーリングタスクの状態を追跡し、良いエラー状態情報を提供します。このステップはGitのステップを管理するので、ここでプロセスがハングすることがあります。
  8. アップデートミラーサービス(update_mirror_service.rb)はGitオペレーションを実行します。

インポートとミラーの更新処理は、ミラーサービスの更新ステップの後で完了します。しかし、含まれる変更内容によっては、さらに多くのタスク (コミット用のパイプラインなど) が発生することもあります。