GitHub Actionsのランナープロバイダーを切り替える方法：ラベル、キャッシュ、シークレット、課金、フォールバック

このガイドは特定のベンダーに偏らない内容です。GitHub Actionsのランナープロバイダーを変えるときに何が移るのか、何が最もよく壊れるのか、そしてどう元に戻すのかを説明します。私たちはプロバイダーの1つであるCRACIを開発しています。CRACIは、文書化された事実が当てはまる箇所と、最後の専用セクションに登場します。先にプロバイダーを選ぶ場合は、 GitHub Actionsランナープロバイダーの比較と GitHubホステッドランナーの代替をご覧ください。

切り替えで変わるもの、変わらないもの

GitHub Actionsは2つの部分からなります。GitHubはコントロールプレーンで、リポジトリとワークフローファイルを保存し、トリガーを起動し、シークレットを保存し、ジョブを割り当て、ログとチェックを表示し、アーティファクトを保持し、OIDCトークンを発行します。 CIランナーはジョブが実行される場所で、イメージ、CPU、ディスク、インターネットへのネットワーク経路、そして通常はローカルキャッシュを備えたマシンです。GitHubはジョブをランナーに割り当て、開始時にジョブのシークレットを渡し、ランナーはログをストリーミングで返します。

ランナープロバイダーが置き換えるのは、このうち後者だけです。

項目	GitHubに残る	プロバイダーに移る
リポジトリ、ワークフローファイル、トリガー	はい	いいえ
シークレットの保存	はい	シークレットはジョブ開始時にプロバイダーのマシンへ渡されます
ジョブの割り当て、ログ、チェックのUI	はい	ランナーがログをストリーミングで返します
actions/upload-artifactによるアーティファクト	はい	いいえ
OIDCトークンの発行元	はい	いいえ。ただし、トークンにはランナーがセルフホストと記されます
マシン、イメージ、CPU、メモリ、ディスク	いいえ	はい
送信のネットワーク経路とIPアドレス	いいえ	はい
キャッシュのストレージ	プロバイダーによる	プロバイダーによる
移したジョブの分単位の課金	いいえ	はい

サードパーティのランナーは、セルフホストランナーとしてGitHubに登録されます。そのため、セルフホストランナーに関するGitHubのルールがそのまま適用されます。ラベルによるジョブの振り分け、ランナーグループによるアクセス制限、OIDCトークンでの扱い、GitHubの課金方法です。

runs-onの変更とラベル

GitHubは、ジョブのruns-onのラベルとグループに一致するランナーを探します。一致するランナーがオンラインでなければ、ジョブはランナーがオンラインになるまでキューに残ります。割り当てられたランナーが60秒以内にジョブを受け取らなければ再びキューに入り、24時間を超えてキューに残ったジョブは失敗します （GitHubのセルフホストランナーのリファレンス）。ラベルの入力ミスや、リポジトリにプロバイダーのアプリがインストールされていないことは、いつまでも始まらないジョブとして現れます。

プロバイダーがマシンを指定する方法は、次の2つのどちらかです。

• ラベルで指定する。 Ubicloudはubicloud-standard-2、Blacksmithは blacksmith-2vcpu-ubuntu-2404、Avreaはavrea-ubuntu-latest-2-vcpuのようなラベルを使い、ARMマシンではラベルに armを含めます。サイズを変えるにはラベルを変えます。
• セットアップステップで指定する。 CRACIはruns-on: craciという1つのラベルを使い、 cracicorp/setup@v1ステップでサイズ（1 vCPUと3 GBのコンピュートユニットを1〜32、デフォルトは2）、イメージ、ネットワークポリシー、またはスラッグで指定するOrganizationのランナーテンプレートを選びます。CRACIが入力を解析できない場合は、デフォルトの環境で実行してジョブログに警告を書き込みます。不明なイメージやテンプレートは拒否されます。

切り替えを1つの変数にする

ラベルをハードコードせず、リポジトリまたはOrganizationの変数に置きます。そうすれば、切り替えも元に戻すのも設定の変更で済み、すべてのリポジトリにプルリクエストを出す必要はありません。

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

選択はジョブごとなので、ビルドとテストのジョブを移しながら、デプロイのジョブを残せます。変数はOrganizationレベルで設定し、リポジトリごとに上書きできるため、1つの設定で複数のリポジトリをまとめて移し、特定のリポジトリだけを対象外にできます。

再利用可能なワークフロー

同じパイプラインが多くのリポジトリにコピーされている場合は、入力または変数からランナーを読み取る再利用可能なワークフローにまとめます。そこでruns-onを変えれば、それを呼び出すすべてのリポジトリが変わります。ルールセットを使うと、Organizationのリポジトリでワークフローの実行を必須にでき、共有のバージョンが使われ続けます。

ランナーイメージ：互換性と固定

GitHubのホステッドイメージには、多数のプリインストールツールとホステッドツールキャッシュが含まれています。プロバイダーが提供するのは、GitHub互換のイメージか、より軽量なイメージです。ジョブは、宣言していないものに依存していることがよくあります。

• プリインストールされた言語のバージョンとコマンドラインツール
• パスワードなしのsudo、およびsystemd（systemctlで起動するサービス向け）
• BuildxとComposeを備えた、稼働中のDockerデーモン
• setup-*アクションがダウンロード前に参照するホステッドツールキャッシュ
• 大規模なビルド向けの空きディスク容量

判断のルール：まずプロバイダーのGitHub互換イメージから始めます。ジョブが成功するようになってから軽量イメージに移し、暗黙的に使っていたものすべてに明示的なsetup-*ステップを追加します。

固定：ubuntu-latestはGitHubのスケジュールで新しいリリースに切り替わり、 ubuntu-24.04はOSのリリースを固定しますが、その上のパッケージのバージョンは固定しません。重要なものはジョブの中で固定してください。セットアップアクションはバージョンを明示し、コンテナイメージはダイジェストで指定します。各プロバイダーに何を固定できるかを確認してください。ランナーアプリケーション自体は、GitHubと通信するために更新し続ける必要があります。

CRACIのイメージは、x86-64とARM64のCRACI Slim（Ubuntu 24.04、systemdなし）と、GitHub Actionsと完全互換のUbuntu 24.04イメージです。後者はubuntu-24.04またはubuntu-latestとして選択でき、GitHubのUbuntu 24.04ランナーイメージに追従し、ホステッドツールキャッシュを含みます。すべてのイメージにDocker Engine、Buildx、Compose v2が入っています。

キャッシュ：引き継がれるものと、空から始まるもの

新しいプロバイダーでの最初の数回の実行は遅くなることが多く、その理由はたいてい遅いマシンではなく空のキャッシュです。何が起こるかは、 actions/cacheの仕組みで決まります （actions/cacheのREADME）。

• エントリは、キーとバージョン（キャッシュ対象のパスと圧縮ツールのハッシュ）で検索されます。
• エントリはブランチ単位でスコープされ、デフォルトブランチのエントリは他のブランチからも使えます。
• 既定では、リポジトリは最大10 GBのキャッシュを保持でき、それを超えると古いエントリから削除されます。リポジトリ管理者と、Organization または Enterprise のオーナーは上限を引き上げられ、10 GBを超える使用量はアカウントに課金されます（GitHubの依存関係キャッシュのドキュメント）。
• Windowsで保存したキャッシュは、enableCrossOsArchiveを設定しない限り別のOSでは復元されず、その逆も同様です。圧縮ツールが異なる場合もバージョンが変わります。

プロバイダーがキャッシュを提供する方法は、次の2つのどちらかです。

方式	最初の数回の実行	トレードオフ
GitHubホステッドランナーと同じく、ランナーがGitHubのキャッシュサービスを使う	既存のエントリが復元される	キャッシュの通信が、プロバイダーとGitHubの間でインターネットを経由する
プロバイダーが、ランナーの隣にあるストレージからキャッシュAPIを提供する	プロバイダーがGitHubのエントリを取り込むか、GitHubへフォールスルーしない限り、最初の数回の実行で埋まるまで通常は空	復元が速い。そこで書き込まれたエントリは、通常GitHubホステッドランナーからは見えない

2つ目の点は、混在構成とロールバックで重要になります。ジョブを元に戻すと、GitHub側でもキャッシュが空の状態から始まることがあります。プロバイダーがどちらの方式を使い、エントリがどこにあるのかを確認してください。

空のキャッシュと遅いランナーを見分ける。大きなnode_modulesディレクトリをキャッシュするNodeのビルドを例にします。新しいプロバイダーでの最初の実行では、actions/cacheがミスを報告し、インストールステップがすべてをダウンロードし、ポストステップがキャッシュを保存します。同じブランチでの次の実行からは、ステップがヒットを報告し、インストールステップが短くなります。実行の比較は、キャッシュが温まってから行ってください。 cache-hitの出力を確認し、復元ステップとインストールステップの時間をビルド本体とは分けて計測します。キー、スコープ、キャッシュポイズニングについては、GitHub Actionsのキャッシュの仕組みをご覧ください。

CRACIでは、actions/cacheは現在と同じように動作し、ビルドの記録には、各パッケージが取得されたのではなくCIキャッシュから復元されたかどうかが記されます。

Dockerのレイヤーキャッシュ

仕組み	レイヤーの保存場所	知っておくべきこと
BuildKit type=gha	GitHub Actionsのキャッシュ	スコープとサイズのルールは上記と同じ。対応するビルダーが必要
BuildKit type=registry	レジストリ内の別イメージ	どのランナーでも動き、プロバイダーを切り替えても残る。レジストリのストレージと転送の費用がかかる
プロバイダーのローカルなレイヤーキャッシュまたは永続ディスク	プロバイダーのランナーの隣	通常は最速。プロバイダーを離れると置き去りになる

持ち運べる選択肢はレジストリキャッシュです（Dockerのキャッシュバックエンド）。

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

同時に開始した2つのジョブは同じキャッシュを復元し、どちらも不足しているレイヤーをビルドします。これはどのCIでも起こることなので、プロバイダーの問題と受け取らないでください。

CRACIは、ローカルレイヤーキャッシュ、リモートレイヤーキャッシュ、バインドマウントキャッシュによるコンテナレイヤーのキャッシュを提供しています。

シークレット、OIDC、クラウドの認証情報

GitHubはシークレットを保存し、ジョブを実行するランナーに渡します。ジョブをプロバイダーに移すことは、そのジョブのシークレットをプロバイダーに預けることを意味します。次の点を確認してください。

• ジョブごとに専用の仮想マシンが割り当てられるのか、共有ホスト上のコンテナなのか。
• ジョブ後にマシンは破棄されるのか、何か保持されるものはあるのか。
• プロバイダーはどのログを保持するのか。GitHubはジョブログ内の登録済みシークレットをマスクしますが、変換された値については自動マスクが保証されないとしています。プロバイダー自身のシステムログについても確認してください。

OIDCは引き続き機能しますが、注意点が1つあります。OIDCトークンを発行するのはランナーではなくGitHubなので、 permissions: id-token: writeはどのランナーでも機能します。ただし、トークンのrunner_environment クレームはgithub-hostedかself-hostedのどちらかで （GitHubのOIDCリファレンス）、サードパーティのランナーではself-hostedになります。 github-hostedを必須とするクラウドの信頼ポリシーはジョブを拒否します。たとえば、次の属性条件を持つGoogle Cloudのワークロードアイデンティティプールです。

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

ランナーのチェックを外すと認証情報を取得できる範囲が広がるため、同時に別の条件を厳しくしてください。切り替えの前に、すべてのクラウドの信頼ポリシーとワークロードアイデンティティの設定でrunner_environmentを検索してください。

イメージのプッシュ：GITHUB_TOKENにpackages: writeを付ければ、どのランナーからでもGitHub Container Registryにプッシュでき、保存済みのシークレットを使うレジストリのログインもそのまま機能します。

CRACIでは、GitHub AppがコードとActionsの実行を読み取り、Organization向けに登録したランナーを管理します。各ジョブはそれぞれ分離された仮想マシンで実行され、CRACIはソースコードを保存しません。

ネットワーク上のID：IP許可リストとエグレス

新しいランナーは新しいIPアドレスから通信します。送信元アドレスでフィルタリングしているものをすべて洗い出してください。

• データベースとアーティファクトリポジトリの許可リスト
• IP制限のあるSaaSのAPI
• パートナーのSFTPサーバーと、ファイアウォールの内側にある社内サービス

選択肢は、プロバイダーの静的または固定のエグレスIPアドレスか、自社で管理するプロキシです。これは、ジョブがそもそもどこに到達してよいかを決める機会でもあります。ランナー上のエグレスポリシーは、侵害された依存関係が、ビルドに必要のないホストへシークレットを送信するのを防ぎます。 GitHub Actionsのエグレスポリシーをご覧ください。

CRACIは、固定のエグレスIPレンジと、デフォルト拒否またはデフォルト許可を選べるエグレスポリシーを提供しています。ポリシーはジョブ開始前に検証され、フェイルクローズで動作します。network入力がない場合、デフォルトのテンプレートはそれ以外の送信接続も許可するため、エグレス制御はご自身で設定するものです。

混在構成：Linuxを移し、macOSとiOSはそのままに

ランナーはジョブごとに選ぶため、1つのワークフローでLinuxジョブをプロバイダーで、macOSジョブをGitHubホステッドランナーで実行できます。actions/upload-artifactでアップロードしたアーティファクトはGitHubが保存するため、あるランナー上のジョブから別のランナー上のジョブへファイルを渡せます。

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

GitHubに残したジョブは引き続きプランに含まれる利用分を消費し、それを超えた分はGitHubから請求されます。CRACIは現在x86-64とARM64でLinuxを実行し、WindowsとmacOSはロードマップに掲載されています。そのため、CRACIを使う混在構成では、LinuxにCRACI、それ以外にGitHubホステッドランナーを使うことになります。

プロバイダーが停止したときのフォールバック

GitHubには、ランナーラベル間の組み込みのフォールバックはありません。そのラベルのランナーがオンラインでなければジョブは待機し、24時間後に失敗します。次のように備えてください。

• 上で説明した変数による切り替え：値をubuntu-latestに戻せば、新しい実行はGitHubホステッドランナーに向かいます。
• 緊急時の手動オーバーライド：workflow_dispatchの入力を、 runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}として読み取ります。
• ジョブにtimeout-minutesを設定し、ハングしたジョブがデプロイを何時間も止めないようにします。
• キュー待ち時間の監視により、ジョブがいつもより長く待っていることに気付けるようにします。

各プロバイダーに、自動フォールバックがあるか、何がそれを発動させるのかを確認してください。逆方向にも備えておきましょう。すべてのジョブはGitHubがキューに入れて割り当てるため、GitHub Actionsの障害はすべてのランナープロバイダーのジョブも止めます。

課金：GitHubからの請求は続くのか

GitHubはセルフホストランナーに分単位の料金を課さず、サードパーティのランナーはセルフホストとして登録されるため、移した分の利用時間はGitHubの請求書に載らなくなります （GitHub Actionsの課金）。GitHubが引き続き請求するのは次のものです。

• プランのシート
• 含まれる容量を超えて保持するアーティファクトとキャッシュのストレージ
• GitHubホステッドランナーに残したジョブのうち、プランに含まれる利用分を超えた分（含まれる利用分は返金されません）

試験導入の間は、2つの請求書を支払うことになります。プロバイダーによってビルド時間の数え方は異なり、GitHubは各ジョブを1分単位に切り上げ、秒単位で計測するプロバイダーもあります。切り替え前後の利用量を見積もるには、GitHub Actionsのコスト計算ツールをお使いください。CRACIが課金するのはビルド時間だけで、1vCPU分あたり$0.002（デフォルトの2 vCPUランナーでは$0.004）を秒単位で計測し、月額料金はありません。

セキュリティ上の分離：どのプロバイダーにも確認すべきこと

質問	重要な理由
ジョブごとに1台の仮想マシンか、共有ホスト上のコンテナか	共有ホストでは、侵害されたジョブが隣のジョブに到達できる
ジョブ後にマシンは破棄されるか	永続的なマシンは、ファイル、認証情報、プロセスを次のジョブに持ち越す
ハードウェアはどこにあり、誰が運用しているか	データの所在、管轄、自社顧客との契約
プロバイダーは何を、どのくらいの期間保存するか	ログ、キャッシュ、ネットワークデータには機密情報が含まれる場合がある
どの認証を取得しているか	ベンダー審査で必ず問われる
エグレスを制御できるか	悪意あるパッケージを通じたシークレットの流出を防ぐ
そのGitHub Appは何を読み取り、変更できるか	アプリの権限は、インストールしたすべてのリポジトリに及ぶ

GitHubは、誰でもプルリクエストを作成して環境を侵害できるため、パブリックリポジトリでセルフホストランナーを使うべきではほぼないとしています。また、ジャストインタイムのランナーは最大1つのジョブを実行した後に削除されるとしています （GitHubのセキュアな利用に関するリファレンス）。ジョブごとに新しい仮想マシンを使えば、その懸念の大部分に対処できます。

CRACIの回答：各ジョブは、ヨーロッパのベアメタルインフラ上で、それぞれ分離された仮想マシンで実行されます。CRACI Corporation Oyの情報セキュリティマネジメントシステムは、CRACIプラットフォームの開発と運用を対象に、 Into CertificationによるISO/IEC 27001認証を取得しており、詳細はTrust Centerに掲載しています。CRACIが保存するのは、ビルドのメタデータ、パッケージデータ、ネットワークトレース、SBOM、来歴情報、キャッシュ、監査記録で、ソースコードは決して保存しません。CRACIがアクセスできる範囲とセキュリティをご覧ください。

まず1つのリポジトリで試す

1. リリースパイプラインではなく、代表的で頻繁に実行されるLinuxワークフローを持つリポジトリを選びます。
2. GitHubホステッドランナーでベースラインを記録します。直近30回の実行の所要時間とキュー待ち時間の中央値、および課金された利用時間です。
3. プロバイダーのGitHub Appを、そのリポジトリだけにインストールします。
4. ブランチ上で、リポジトリ変数を使ってジョブを1つ切り替えます。
5. 少なくとも10回実行し、最初の3回はキャッシュのウォームアップとして除外します。
6. 所要時間、キュー待ち時間、キャッシュヒット率、失敗、コストを比較し、ログ、OIDC、送信通信を確認します。
7. 変数を変更して元に戻し、ジョブがGitHubホステッドランナーに戻ることを確認します。

指標	GitHubホステッドのベースライン	プロバイダー	合格基準
ジョブ所要時間の中央値			自社の目標（例：30%短縮）
キュー待ち時間の中央値			ベースラインより悪化しない
ウォームアップ後のキャッシュヒット率			ベースラインと同等
コードに起因しない失敗した実行			なし
1回の実行あたりのコスト			ベースラインを下回る
OIDC、許可リスト、送信通信			すべて機能する

速度はご自身のワークフローで計測してください。どのプロバイダーも独自の数値を公表していますが、判断の決め手になるのは自社のパイプラインで得た数値だけです。

CRACIの位置付け

CRACIはGitHub Actionsのランナーです。置き換えるのはランナーであり、GitHub Actionsではありません。ジョブは runs-on: craciで移り、サイズとイメージはcracicorp/setup@v1またはOrganizationのランナーテンプレートで設定し、実行結果は引き続きGitHubに表示されます。CRACIは、より高速なハードウェア、短いキュー待ち時間、キャッシュにより、GitHubホステッドランナーの約2倍の速さでビルドを実行します。

他のプロバイダーではなくCRACIを選ぶ理由は、各ジョブが残すものにあります。ビルドが取得したもののSBOMが完全性の状態とともに、フェイルクローズで動作するエグレスポリシーのもとで記録されます。docs.craci.comでは、ワークフローのジョブごとの移行計画を提案するコーディングエージェント向けのプロンプトも提供しています。 CI/CD連携をご覧ください。

CRACIが適さない場合

• macOSやWindowsのランナーが必要な場合。これらはCRACIのロードマップに掲載されています。
• GitHub Enterprise Serverを使っている場合。CRACIは対応していません。
• CIがGitLab CIまたはJenkinsの場合。どちらもロードマップに掲載されています。
• ランナーを自社のクラウドアカウント内に置く必要がある場合。顧客ホスト型ランナーはロードマップに掲載されています。現在はRunsOnと、WarpBuildのBring Your Own Cloudオプションがこれに対応しています。CRACIとRunsOnの比較と CRACIとWarpBuildの比較をご覧ください。
• 主な目的がCIの可観測性とデバッグの場合。CRACIとAvreaの比較をご覧ください。ランナーを自社で運用する場合は、マネージドランナーとセルフホストランナーの比較をご覧ください。

ランナープロバイダーの切り替えに関するよくあるご質問

GitHub Actionsのランナープロバイダーを変えるには、何を変更する必要がありますか？

プロバイダーのGitHub Appをインストールし、ジョブのruns-onラベルをプロバイダーのラベルに変更します。ワークフロー、トリガー、シークレット、GitHubのUIはそのままです。重要なジョブを移す前に、ランナーイメージ、キャッシュ、送信元IPアドレス、OIDCを使うクラウドの信頼ポリシー、フォールバック、課金を確認してください。

GitHub Actionsのキャッシュは新しいランナープロバイダーに引き継がれますか？

プロバイダーがキャッシュをどこから提供するかによります。ランナーがGitHubのキャッシュサービスを使う場合は、既存のエントリが復元されます。ランナーの隣にあるストレージからキャッシュAPIを提供する場合、キャッシュは通常空の状態から始まり、最初の数回の実行で埋まります。プロバイダーにどちらの方式か、またそのランナーで書き込まれたエントリがGitHubホステッドランナーから見えるかを確認してください。

Dockerのレイヤーキャッシュはサードパーティのランナーでも使えますか？

はい。3つの仕組みのいずれかで使えます。Actionsのキャッシュを使うBuildKitのtype=ghaバックエンド、どのランナーでも動くtype=registryによるレジストリキャッシュ、そしてプロバイダーがランナーの隣に保持するレイヤーキャッシュや永続ディスクです。

Linuxジョブだけを移し、macOSとiOSのビルドはGitHubに残せますか？

はい。ランナーはジョブごとに選ぶため、同じワークフローの中でLinuxジョブをプロバイダーで動かし、macOSジョブをGitHubホステッドランナーに残せます。ジョブはneeds:でつなぎ、ファイルはGitHubが保存するactions/upload-artifactとactions/download-artifactで受け渡します。

サードパーティのランナーが停止したらジョブはどうなりますか？フォールバックはありますか？

GitHubには、ランナーラベル間の組み込みのフォールバックはありません。オンラインのランナーがどれもラベルに一致しないジョブはキューに残り、24時間後に失敗します。ラベルをリポジトリまたはOrganizationの変数に置いて1か所の変更で戻せるようにし、timeout-minutesを設定し、各プロバイダーに独自のフォールバックがあるかを確認してください。

サードパーティのランナーでもシークレットとOIDCは使えますか？

はい。シークレットはGitHubが保存してジョブ開始時にランナーへ渡し、OIDCトークンもGitHubが発行するため、id-token: writeはどのランナーでも機能します。注意点は、サードパーティのランナーではトークンのrunner_environmentクレームがself-hostedになることです。そのため、github-hostedを必須とするクラウドの信頼ポリシーはジョブを拒否します。

別のランナープロバイダーを使っても、GitHubから分単位の料金を請求されますか？

移したジョブについては請求されません。サードパーティのランナーはセルフホストランナーとしてGitHubに登録され、GitHubはセルフホストランナーを分単位の課金なしとしています。GitHubは引き続き、シート、含まれる容量を超えて保持するストレージ、GitHubホステッドランナーに残したジョブを請求します。プロバイダーは自社の利用時間を別途請求します。

ランナーイメージが知らないうちに変わらないよう固定するにはどうすればよいですか？

ubuntu-latestはGitHubのスケジュールで切り替わり、ubuntu-24.04はOSのリリースを固定しますが、その上のパッケージのバージョンは固定しません。重要なものはジョブの中で固定してください。セットアップアクションはバージョンを明示し、コンテナイメージはダイジェストで指定します。各プロバイダーに何を固定できるかを確認してください。ランナーアプリケーション自体は、GitHubと連携し続けるために更新が必要です。

サードパーティのランナーでは、ジョブ同士はどのように分離されますか？

プロバイダーによって異なります。ジョブごとに専用の仮想マシンが割り当てられるのか、共有ホスト上のコンテナなのか、ジョブ後にマシンが破棄されるのか、プロバイダーがその後に何を保持するのかを確認してください。ジョブごとに新しい仮想マシンを使う方式は、一般的な方式の中で最も強力です。あるジョブのものが次のジョブに一切残らないためです。

まず1つのリポジトリでランナープロバイダーを試すにはどうすればよいですか？

プロバイダーのGitHub Appを1つのリポジトリにインストールし、頻繁に実行されるLinuxジョブを1つ、ブランチ上でリポジトリ変数を使って切り替え、少なくとも10回実行します。そのうえで、所要時間、キュー待ち時間、キャッシュヒット、失敗、コストをGitHubホステッドのベースラインと比較します。元に戻すには変数を変更します。