ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

ワークフローでのセルフホストランナーの利用

ワークフローでセルフホストランナーを使うには、ラベルを使ってジョブのためのランナーの種類を指定できます。

ここには以下の内容があります:

カスタム及びデフォルトラベルの作成に関する情報については「セルフホストランナーでのラベルの利用」を参照してください。

ワークフローでのセルフホストランナーの利用

ラベルを使うと、セルフホストランナーの共有される特徴に基づき、ワークフローのジョブを特定の種類のセルフホストランナーに送れます。 たとえば、ジョブが特定のハードウェアコンポーネントやソフトウェアパッケージを必要とするなら、カスタムラベルをランナーに割り当て、そのラベルを持つランナー上でのみ実行されるようジョブを設定できます。

ジョブでセルフホストランナーを指定するには、ワークフローファイル中でセルフホストランナーのラベルでruns-onを設定してください。

すべてのセルフホストランナーはself-hostedラベルを持ち、self-hostedラベルだけを提供すれば任意のセルフホストランナーを選択できます。 あるいは、特定のオペレーティングシステムやシステムアーキテクチャのラベルといった追加のラベルと合わせて配列中でself-hostedを使い、指定した種類のランナーだけを選択することもできます。

詳細については、「GitHub Actionsのワークフロー構文」を参照してください。

デフォルトラベルを使ったジョブの転送

セルフホストランナーは、GitHub Actionsに追加されたときに特定のラベルを自動的に受信します。 それらは、ランナーのオペレーティングシステムとハードウェアプラットフォームを示すために使われます。

  • self-hosted: セルフホストランナーに適用されるデフォルトのラベル。
  • linuxwindowsmacOS: オペレーティングシステムに基づいて適用されます。
  • x86x64ARMARM64: ハードウェアアーキテクチャに基づいて適用されます。

ワークフローのYAMLを使って、これらのラベルの組み合わせに対してジョブを送信できます。 この例では、3つのラベルすべてにマッチするセルフホストランナーが、ジョブを実行する資格を持つことになります。

runs-on: [self-hosted, linux, ARM64]
  • self-hosted - このジョブをセルフホストランナー上で実行します。
  • linux - Linuxベースのランナーだけを使います。
  • ARM64 - ARM64ハードウェアベースのランナーだけを使います。

デフォルトラベルは固定されており、変更や削除はできません。 ジョブの転送をもっと制御する必要がある場合は、カスタムラベルの利用を検討してください。

カスタムラベルを使ったジョブの転送

カスタムラベルを作成し、セルフホストランナーに割り当てることがいつでもできます。 カスタムラベルを使えば、付けられたラベルに基づいて特定の種類のセルフホストランナーにジョブを送信できるようになります。

たとえば、特定の種類のグラフィックハードウェアを必要とするジョブがあるなら、gpuというカスタムラベルを作成し、そのハードウェアがインストールされているランナーに割り当てることができます。 割り当てられたすべてのラベルにマッチするセルフホストランナーが、そのジョブを実行できるようになります。

以下の例は、デフォルトとカスタムのラベルを組み合わせたジョブです。

runs-on: [self-hosted, linux, x64, gpu]
  • self-hosted - このジョブはセルフホストランナーで実行されます。
  • linux - Linuxベースのランナーだけを使います。
  • x64 - x64ハードウェアベースのランナーだけを使います。
  • gpu - このカスタムラベルは、GPUハードウェアがインストールされているセルフホストランナーに手動で割り当てられました。

これらのラベルは累積的に働くので、このジョブを処理できるセルフホストランナーは、4つすべてのラベルがマッチしていなければなりません。

Routing precedence for self-hosted runners

If you use both repository-level and organization-level runners, GitHub follows an order of precedence when routing jobs to self-hosted runners:

  1. The job's runs-on labels are processed. GitHub then attempts to locate a runner that matches the label requirements:
  2. The job is sent to a repository-level runner that matches the job labels. If no repository-level runner is available (either busy, offline, or no matching labels):
  3. The job is sent to an organization-level runner that matches the job labels. If no organization-level runner is available, the job request fails with an error.

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください