ドキュメントメニュー

はじめに

ダッシュボードと分析

マネージドランナー

キャッシュ

チームと通知

請求とプラン

ヘルプ

Latchkey ランナーで最初のジョブを実行する

1 行の YAML を変更するだけで GitHub Actions ジョブをマネージドランナーに切り替え、ピックアップされる様子を見て、ダッシュボードで確認します。

始める前に

Latchkey GitHub App が私の組織にインストールされているリポジトリが Latchkey で監視されている私のトライアルまたはサブスクリプションがアクティブである

1 行の変更#

変更前: GitHub ホステッド

yaml

jobs:
  test:
    runs-on: ubuntu-latest

変更後: Latchkey

yaml

jobs:
  test:
    runs-on: latchkey-small

ラベルを記憶から入力する必要はまったくありません: Runners ページの Your runners テーブルの各行には Copy CI snippet アクションがあり、各ランナーの詳細ドロワーには、ラベルとコピー可能なスニペットを備えた Use in CI カードが含まれています。

どちらのラベル形式も同じようにルーティングされます。あなたの規約が好むほうを使ってください:

.github/workflows/ci.yml

name: CI
on: [push]

jobs:
  test:
    runs-on: latchkey-small
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm test

.github/workflows/ci.yml

name: CI
on: [push]

jobs:
  test:
    runs-on: [self-hosted, latchkey-small]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm test

サイズはワークフローごとではなくジョブごとに選択します: 重いジョブにより大きなマシンを与え、それ以外はすべて latchkey-small に留めます。1 サイズ上げると 1 分あたりの料金が倍になるため、ジョブの所要時間を少なくとも半分にできるときに元が取れます。サイジングの指針を参照してください。

.github/workflows/build.yml

jobs:
  heavy-build:
    runs-on: latchkey-large   # 8 vCPU / 32 GB for the heavy job
  quick-lint:
    runs-on: latchkey-small   # keep cheap jobs on small

runs-on は式を受け付けるため、matrix は各レグを必要なサイズにルーティングできます: 軽いレグは small の料金に留まり、重いレグだけが大きなマシンの分を支払います。

.github/workflows/ci.yml

jobs:
  test:
    strategy:
      matrix:
        include:
          - suite: unit
            runner: latchkey-small
          - suite: integration
            runner: latchkey-large
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - run: npm run test:${{ matrix.suite }}

または生成する#

Build your runs-on line

Runner

Label form

Job name

Paste this into any workflow under .github/workflows/. Everything else in the job stays unchanged.

デプロイして確認する#

コミットしてワークフローをトリガーする

変更をプッシュするか、ワークフローを手動でトリガーします。GitHub では、ランナーがピックアップするまでジョブはキュー状態として表示されます: ウォームランナーが利用可能なら数秒、新しいランナーなら約 10 秒 (GitHub ホステッドは通常 30-60 秒)、いずれの場合もキュー待ち時間はゼロです。

どこで実行されたか確認する

GitHub の実行ビューで、ジョブのランナー名により、GitHub ホステッドではなく Latchkey のマシンが引き受けたことが確認できます。すべてのランナーは 1 ジョブの後に破棄されるため、実行ごとに見慣れた名前を期待しないでください: 各ジョブを新しいマシンが引き受けます。これはエフェメラル設計が意図どおりに機能している証です。

分数を見つける

Latchkey ダッシュボードでは、Runners ページがその実行をあなたのフリートアクティビティに表示し、その分数が無料ティアに対して計上されます。時間が経つと、同じ数字がさらに 2 か所に現れます: 課金モーダル (無料ティアの進捗、課金対象の分数、これまでの推定コスト) と、GitHub の支出と並べて Latchkey ランナーの支出を追跡するコスト分析ページです。詳細はランナーの使用量と無料分にあります。

ジョブが "queued" のまま留まる場合#

ピックアップされないジョブは、あらゆるルーティング問題の標準的な症状です: リポジトリが監視されていない、マネージドランナーが有効になっていない、ラベルにタイプミスがある、カスタムランナーのイメージがまだビルド中である、または課金によってランナーの起動がブロックされている。これらの場合、GitHub の UI に明示的なエラーは表示されません。トラブルシューティング: ジョブがキューに留まるを順にたどって、どれに該当するかを特定してください。

よくある質問#

GitHub ホステッドのラベルは引き続き機能しますか?

はい。ubuntu-latest などは並行して機能し続けます。Latchkey をインストールしてもそれらは何も変わりません。一度に 1 ジョブずつ移行し、残りは好きなだけ手を付けずに残せます。

1 つのワークフローで Latchkey と GitHub ホステッドのランナーを混在させられますか?

はい、自由に。runs-on はジョブごとに決定されるため、ワークフローは Linux ジョブを latchkey-* ラベルで実行しつつ、GPU、Windows、macOS、arm64 ホストを必要とするジョブは GitHub ホステッドや他のランナーに留めることができます。

runs-on 以外に何か変更する必要はありますか?

ほとんどのワークフローでは不要です。ランナーイメージは GitHub ホステッドランナーに匹敵するか上回るよう設計されており、actions/setup-* ステップは同じ toolcache レイアウトから解決されるため、ジョブの残りはそのままです。

この最初の実行にはいくらかかりますか?

分数はジョブごとに切り上げて 1 分単位でサイズの料金で課金され、すべてのプランに毎月の無料分が含まれます。無料ティアを既に使い切っていない限り、短いテスト実行に費用はかかりません。ランナーの使用量と無料分を参照してください。