runner の label とは？job はどう runner を選ぶのか
runner の label とは、runner に付けられたタグです。job は runs-on を使って一致する label を持つ runner を要求し、これが CI が各 job の行き先を決める仕組みです。
label は CI のルーティング層です。job は「これらの label を持つ runner が必要」と言い、サービスはそれに一致する runner に渡します。label を間違えると、job は存在しない runner を待って永遠にキューに留まることがあります。
label がどう job をルーティングするか
各 runner は label を広告します - self-hosted、linux、x64 のような組み込みのもの、加えて追加する任意のカスタムなもの。job の runs-on は必要な label を列挙し、サービスはそのすべてを持つ runner にのみ job を割り当てます。
組み込み vs カスタムの label
組み込みの label は OS とアーキテクチャを自動的に記述します。カスタムの label は、特定の job を特定のキャパシティにルーティングできます - 例えば ML の job 用の gpu label や、マネージドフリートに job を送るプロバイダーの label。
典型的な不一致の失敗
job がどのオンライン runner も提供していない label を要求すると、「waiting for a runner」で無期限にキューに入ります。タイプミス、廃止された runner、削除された label はすべて、同じキューで止まる症状を生みます。
label と移行
runner プロバイダーの切り替えは、多くの場合 label 変更だけです。runs-on を新しいプロバイダーの label に向ければ、同じワークフローが新しいフリートで実行されます。Latchkey の導入は通常、runs-on の label を差し替えることを意味します。
label の問題のデバッグ
job がキューに留まっているとき、オンラインの runner が実際に広告している label を一覧し、runs-on の要求と比較します。修正はほぼ常に、両者を一致させること - タイプミスの訂正、runner のオンライン化、削除された label の復元です。
重要なポイント
- runner の label は runner にタグを付け、job が runs-on を通じて要求できるようにします。
- job は、要求するすべての label を持つ runner でのみ実行されます。
- どの runner も提供していない label を要求すると、job は無期限にキューに入ります。
- runner プロバイダーの移行は、多くの場合 runs-on の label 変更だけです。