リモートリポジトリからのプル

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

GitLabでホストされていなくても、GitLabインターフェースを使用して、リポジトリのコンテンツとアクティビティーを閲覧できます。アップストリームリポジトリからブランチ、タグ、コミットをコピーするには、プルミラーを作成します。

プッシュミラーとは異なり、プルミラーはスケジュールに基づいてアップストリーム（リモート）リポジトリから変更を取得します。ミラーがアップストリームリポジトリから分岐するのを防ぐために、ダウンストリームミラーにコミットを直接プッシュしないでください。代わりに、コミットをアップストリームリポジトリにプッシュします。リモートリポジトリの変更は、GitLabリポジトリにプルされます:

前回のプルから30分後に自動的に行われます。これは無効にできません。
管理者がミラーを強制的に更新する場合。
APIコールが更新をトリガーする場合。

UIとAPIの更新は、デフォルトの5分間のプルミラーリング間隔の対象となります。この間隔は、GitLab Self-Managedインスタンスで設定できます。

デフォルトでは、ダウンストリームのプルミラー上のブランチまたはタグがローカルリポジトリから分岐した場合、GitLabはブランチの更新を停止します。これにより、データ損失が防止されます。アップストリームリポジトリで削除されたブランチとタグは、ダウンストリームリポジトリには反映されません。

ダウンストリームのプルミラーリポジトリから削除されたが、アップストリームリポジトリにはまだ存在する項目は、次回のプル時に復元されます。例: ミラーリングされたリポジトリのみで削除されたブランチは、次回のプル後に再び表示されます。

プルミラーリングの仕組み

GitLabリポジトリをプルミラーとして設定した後:

GitLabは、リポジトリをキューに追加します。
1分に1回、Sidekiq cronジョブは、以下に基づいてリポジトリミラーを更新するようにスケジュールします:
- Sidekiqの設定によって決定される利用可能な容量。GitLab.comについては、GitLab.com Sidekiqの設定をお読みください。
- キュー内にあり、更新が必要なミラーの数。期限がいつになるかは、リポジトリミラーが最後に更新された時期と、更新が再試行された回数によって異なります。
Sidekiqが更新を処理できるようになると、ミラーが更新されます。更新プロセスが次のようになる場合:
- 成功: 少なくとも30分待ってから、更新が再びキューに入れられます。
- 失敗: 更新は後で再び試行されます。14回失敗すると、ミラーはハード障害としてマークされ、更新のためにキューに入れられなくなります。ブランチがアップストリームの対応するものから分岐すると、障害が発生する可能性があります。ブランチの分岐を防ぐには、ミラーの作成時に分岐したブランチを上書きするように設定します。

プルミラーリングを設定する

前提要件:

リモートリポジトリがGitHub上にあり、2要素認証（2FA）が設定されている場合は、repoスコープでGitHubのパーソナルアクセストークンを作成します。2FAが有効になっている場合、このパーソナルアクセストークンはGitHubパスワードとして機能します。
GitLabサイレントモードが有効になっていません。

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > リポジトリを選択します。
リポジトリのミラーリングを展開します。
GitリポジトリのURLを入力します。
gitlabリポジトリをミラーリングするには、gitlab.com:gitlab-org/gitlab.gitまたはhttps://gitlab.com/gitlab-org/gitlab.gitを使用します。
ミラーの方向で、プルを選択します。
認証方法で、認証方法を選択します。詳細については、ミラーの認証方法を参照してください。
必要なオプションを選択します:
- 分岐したブランチを上書き
- ミラーの更新のためにパイプラインをトリガー
- Only mirror protected branches（保護ブランチのみをミラーリング）
設定を保存するには、ミラーリポジトリを選択します。

分岐したブランチを上書き

リモートから分岐している場合でも、リモートバージョンでローカルブランチを常に更新するには、ミラーの作成時に分岐したブランチを上書きを選択します。

ミラーリングされたブランチの場合、このオプションを有効にすると、ローカルの変更が失われます。

ミラーの更新のためにパイプラインをトリガー

リモートリポジトリがブランチまたはタグを更新したときに、パイプラインを自動的にトリガーするようにミラーを設定できます。この機能を有効にする前に:

CI Runnerがリモートリポジトリアクティビティーからの追加の負荷を処理できることを確認します。
セキュリティへの影響を考慮してください。パイプラインはプルミラーリングからの認証情報を使用し、レビューされていないコードを実行します。
この機能は、自分のプロジェクトまたは信頼できるメンテナーのいるプロジェクトに対してのみ有効にしてください。

APIを使用して更新をトリガーする

プルミラーリングは、ポーリングを使用してアップストリームに追加された新しいブランチとコミットを検出します。これは多くの場合、数分後です。APIコールを使用してGitLabに通知できますが、プルミラーリング制限の最小間隔は引き続き適用されます。

詳細については、プロジェクトのプルミラーリングプロセスの開始をお読みください。

ミラーリング時にハード障害を修正する

14回連続して再試行が失敗すると、ミラーリングプロセスはハード障害としてマークされ、ミラーリングの試行は停止します。この障害は、次のいずれかで確認できます:

プロジェクトのメインダッシュボード。
プルミラー設定ページ。

プロジェクトのミラーリングを再開するには、更新を強制します。

ネットワークやサーバーの長期的な停止後など、複数のプロジェクトがこの問題の影響を受けている場合は、Railsコンソールを使用して、このコマンドで影響を受けるすべてのプロジェクトを特定して更新できます:

Project.find_each do |p|
  if p.import_state && p.import_state.retry_count >= 14
    puts "Resetting mirroring operation for #{p.full_path}"
    p.import_state.reset_retry_count
    p.import_state.set_next_execution_to_now(prioritized: true)
    p.import_state.save!
  end
end