リモートリポジトリからのプル
13.9でGitLab Premiumに移行しました。
GitLab でホストされていなくても、GitLab インターフェースを使ってリポジトリのコンテンツやアクティビティを閲覧できます。プルミラーを作成して、ブランチ、タグ、コミットをアップストリームリポジトリから自分のリポジトリにコピーできます。
プッシュミラーとは異なり、プルミラーはスケジュールに基づいてアップストリーム(リモート)リポジトリから変更を取得します。ミラーがアップストリームリポジトリから分岐するのを防ぐために、コミットをダウンストリームミラーに直接プッシュしないでください。代わりにアップストリームリポジトリにコミットをプッシュします。リモートリポジトリの変更は GitLab リポジトリにプルされます:
- 前回のプルから30分後に自動的に。これを無効にすることはできません。
- 管理者がミラーを強制更新したとき。
- API コールが更新のトリガとなった場合。
UIとAPIの更新には、デフォルトのプルミラーリング間隔である5分が適用されます。この間隔はセルフマネージドインスタンスで設定できます。
デフォルトでは、ダウンストリームのプルミラー上のブランチやタグがローカルリポジトリから分岐した場合、GitLabはそのブランチの更新を停止します。これにより、データの損失を防ぐことができます。アップストリームリポジトリで削除されたブランチやタグは、ダウンストリームリポジトリには反映されません。
プルミラーの仕組み
GitLab リポジトリをプルミラーとして設定します:
- GitLab はリポジトリをキューに追加します。
- 1分に1回、Sidekiq cronジョブがリポジトリミラーの更新をスケジュールします:
- Sidekiq設定によって決定される利用可能な容量。GitLab.comについては、GitLab.com Sidekiq設定をお読みください。
- いくつのミラーが既にキューにあり、更新期限を迎えているか。更新期限は、リポジトリミラーが最後に更新された日時と、何回更新が再試行されたかに依存します。
- Sidekiqが更新を処理できるようになり、ミラーが更新されます。更新処理が
- 成功した場合:少なくとも30分の待ち時間で更新が再度キューに入れられます。
- 失敗:更新は後で再試行されます。14回失敗すると、ミラーはハード障害としてマークされ、更新のためにキューに入れられなくなります。ブランチがアップストリームから分岐すると、失敗の原因になることがあります。ブランチが分岐しないようにするには、ミラーを作成するときに分岐したブランチを上書きするを設定してください。
プルミラーの設定
前提条件:
- リモートリポジトリが GitHub 上にあり、二要素認証 (2FA) を設定している場合は、
repo
スコープでGitHub 用の個人アクセストークンを作成します。2FA が有効になっている場合は、この個人アクセストークンが GitHub のパスワードとなります。 - GitLab サイレントモードは有効ではありません。
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 設定] > [リポジトリ]を選択します。
- リポジトリをミラーリング]を展開します。
-
Git リポジトリの URL を入力します。必要であれば、URLにユーザー名を含めます:
https://MYUSERNAME@gitlab.com/GROUPNAME/PROJECTNAME.git
gitlab
リポジトリをミラーするには、git@gitlab.com:gitlab-org/gitlab.git
またはhttps://gitlab.com/gitlab-org/gitlab.git
を使用します。 - ミラーの方向で、Pull を選択します。
- 認証方法]で、認証方法を選択します。詳細については、ミラーの認証方法を参照してください。
- 必要なオプションを選択します:
- 分岐ブランチの上書き
- ミラーアップデートのパイプラインをトリガー
- 保護されたブランチだけをミラーします。
- 設定を保存するには、リポジトリをミラーするを選択してください。
分岐ブランチを上書き
13.9でGitLab Premiumに移行しました。
ローカルブランチがリモートから分岐した場合でも、常にリモートのバージョンで更新するには、ミラー作成時に分岐したブランチを上書きするを選択してください。
ミラーアップデートのトリガーパイプライン
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
関連するトピック
- リポジトリミラーリングのトラブルシューティング
- プルミラーリングの間隔
- プルミラーリング API