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

13.9でGitLab Premiumに移行しました。

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

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

UIとAPIの更新には、デフォルトのプルミラーリング間隔である5分が適用されます。この間隔はセルフマネージドインスタンスで設定できます。

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

note
ダウンストリームのプルミラーリポジトリから削除され、アップストリームリポジトリに残っているアイテムは、次のプル時に復元されます。例: ミラー_リポジトリでのみ_削除されたブランチは、次のプル後に再び表示されます。

プルミラーの仕組み

GitLab リポジトリをプルミラーとして設定します：

  1. GitLab はリポジトリをキューに追加します。
  2. 1分に1回、Sidekiq cronジョブがリポジトリミラーの更新をスケジュールします：
    • Sidekiq設定によって決定される利用可能な容量。GitLab.comについては、GitLab.com Sidekiq設定をお読みください。
    • いくつのミラーが既にキューにあり、更新期限を迎えているか。更新期限は、リポジトリミラーが最後に更新された日時と、何回更新が再試行されたかに依存します。
  3. Sidekiqが更新を処理できるようになり、ミラーが更新されます。更新処理が
    • 成功した場合：少なくとも30分の待ち時間で更新が再度キューに入れられます。
    • 失敗：更新は後で再試行されます。14回失敗すると、ミラーはハード障害としてマークされ、更新のためにキューに入れられなくなります。ブランチがアップストリームから分岐すると、失敗の原因になることがあります。ブランチが分岐しないようにするには、ミラーを作成するときに分岐したブランチを上書きするを設定してください。

プルミラーの設定

前提条件：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定] > [リポジトリ]を選択します。
  3. リポジトリをミラーリング]を展開します。

  4. Git リポジトリの URL を入力します。必要であれば、URLにユーザー名を含めます：https://MYUSERNAME@gitlab.com/GROUPNAME/PROJECTNAME.git

    note
    gitlab リポジトリをミラーするには、git@gitlab.com:gitlab-org/gitlab.git またはhttps://gitlab.com/gitlab-org/gitlab.gitを使用します。
  5. ミラーの方向で、Pull を選択します。
  6. 認証方法］で、認証方法を選択します。詳細については、ミラーの認証方法を参照してください。
  7. 必要なオプションを選択します：
  8. 設定を保存するには、リポジトリをミラーするを選択してください。

分岐ブランチを上書き

13.9でGitLab Premiumに移行しました。

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

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

ミラーアップデートのトリガーパイプライン

13.9でGitLab Premiumに移行しました。

このオプションを有効にすると、ブランチやタグがリモートリポジトリから更新されたときにパイプラインが起動します。リモートリポジトリのアクティビティによっては、CIランナーの負荷が大幅に増加する可能性があります。負荷に耐えられることがわかっている場合のみ、この機能を有効にしてください。CI は、プルミラーリングを設定したときに割り当てられた認証情報を使用します。

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

13.9でGitLab Premiumに移行しました。

プルミラーリングは、アップストリームに追加された新しいブランチやコミットを検出するためにポーリングを使用します。APIコールを使ってGitLabに通知することができますが、プルミラーリングの制限のための最小間隔はまだ強制されています。

詳しくは、Start the pull mirroring process for a projectをご覧ください。

ミラーリング時のハード障害の修正

13.9でGitLab Premiumに移行しました。

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