GitHub ホステッドランナーからの移行

完全な移行ガイド: 実際に何が変わるか、3 つの移行パス、Migrate Runners ツールが適用する正確なラベルマッピング、PR に含まれる内容、検証、そしてロールバック。

Latchkey ランナーへの移行は、書き直しではなくルーティングの変更です。どのランナーがジョブを引き受けるかを決めるのは runs-on: ラベルだけであり、移行が触れるのもそれだけです。それ以外のすべては以前とまったく同じように機能し続けます: あなたが呼び出す actions、GitHub が注入するシークレット、environments とその保護ルール、そして GitHub 側のキャッシュ。さらに、GitHub ホステッドのラベルは latchkey-* ラベルと並行して機能し続けるため、完全な切り替えを強いられることはありません。

何が変わり、何が機能し続けるか#

始める前に#

移行する 3 つの方法#

3 つのパスは組み合わせられます: ほとんどのチームは、パイロットとして 1 つのワークフローを手動で編集し、ツールで一括移行し、独自のイメージに値する少数のリポジトリには AI Scan を使います。

パス 1: Migrate Runners ツール#

このツールには 2 つの入口があり、どちらも同じモーダルを開きます: ダッシュボードのサイドバーにある Migrate Runners 項目と、Runners ページ の Runner Types カードのフッターにある CTA です。移行 PR を開くにはオーナーまたは管理者のロールが必要です。

チームがそのプルリクエストをマージするまで、リポジトリでは何も変わりません。リポジトリに既に開いている移行 PR がある場合、ツールは重複を開く代わりにそれへリンクします。切り替えるものが何も残っていない場合は、Nothing to migrate の状態を表示します。移動するリポジトリが 20 を超える場合は、複数回のパスに分けて移行してください。

ツールが適用する正確なマッピング#

手を付けない行は意図的なものです: ツールが確信を持ってルーティングできないジョブは、今日とまったく同じ場所で実行され続けるため、Linux フリートを今すぐ移行しつつ、OS 混在のワークフローは安全に手つかずのまま残せます。ツールがスキップしたものも、準備ができたときにいつでも手動で移動できます。

各プルリクエストに含まれるもの#

各 PR は runs-on: の行を書き換え、それ以外には何もしません。PR 本文自身が述べるとおり、"Only runs-on: lines were touched. Every other line in each file is byte-identical." 唯一の例外: 移行が Latchkey のキャッシュステップも注入する場合、それらのステップが runs-on の行以外の唯一の追加であり、本文にもそう記されます。各ファイルの変更前後のマッピングテーブルが、何が変わったかを正確に示すため、レビューには数日ではなく数分しかかかりません。

パス 2: 単一のワークフローを手動で編集する#

1 つのワークフローであれば、変更はジョブごとに 1 行で、どちらのラベル形式も同じようにルーティングされます:

jobs:
  test:
    runs-on: latchkey-small

jobs:
  test:
    runs-on: [self-hosted, latchkey-small]

最初の実行の検証やサイズの選択を含む、このパスのステップバイステップ版は 最初のジョブを実行する です。

パス 3: AI Scan、独自のイメージに値するリポジトリ向け#

一部のリポジトリはラベルの置き換え以上の価値があります。AI Scan はリポジトリが実際に実行するワークフローを読み取り、適切なサイズの形状と、リポジトリのツールチェーンをプリインストールするイメージを備えたカスタムランナー構成を提案します。これによりジョブはセットアップステップを丸ごとスキップできます。心当たりのあるリポジトリがあれば、AI Scan によるカスタムランナー から始め、そのリポジトリをプリセットではなくカスタムラベルに移行してください。

段階的な戦略#

一括移行は必要なく、避けることをお勧めします。低リスクのリポジトリ 1 つ、理想的には、安い分、速いピックアップ、自己修復が最も見えやすい不安定または遅いリポジトリから始め、フリート全体を移す前に 1 週間実行させてください。

GPU、Windows、macOS、arm64 ホストを必要とするジョブは GitHub ホステッドや他のランナーに留まり、それはいつまでもそのままで問題ありません: runs-on はジョブごとに決定されるため、ワークフローは Latchkey と GitHub ホステッドのジョブを自由に混在させられます。

マージ後に検証する#

ロールバック#

ロールバックは同じ 1 行の変更を逆方向に行うだけです: 移行 PR をリバートすれば、ジョブは即座に GitHub ホステッドランナーへ戻ります。それ以外に取り消すものはなく、アンインストールするエージェントも、片付ける構成もありません。リポジトリは監視されたままなので、いずれにせよ分析は継続します。

よくある質問#