① 二つのキュー、一台の機械
merge queueは「どのPRを次に主幹へ載せるか／最新既定ブランチ上で緑か」というGit側の問いに答えます。Runnerラベルは「どのリモートMacで動かすか」に答え、リポジトリ間の公平配分は作れません。
体感遅延は多くの場合Runner側が支配します。queue深度が健全でもQueuedが長いならラベルと台数を先に疑い、Wikiにはキュー名・並列・必須チェックとラベル図を一枚にまとめます。
② 判断マトリクス：merge queue とラベルルーティング
下表は主たる制御面の選び方です。成熟チームでは多くの場合両方併用が自然です。merge queueで主幹のねじれを抑え、ラベルでビルダーとXcodeピンを隔離します。週次以上のリリースリズムなら「併用」行をデフォルト推奨としてよいでしょう。
| 方針 | 向く場面 | 主なリスク | 共有Mac上の緩和 |
|---|---|---|---|
| merge queue優先 | マージ頻度が高い、主幹整合を厳格に、多数の貢献者が単一既定ブランチを共有。 | キュー項目ごとにCIサイクルが増え、Runner飽和時は「二重待ち」に感じられる。 | キュー同時ビルド数に上限、必須チェックの整合、キュー用workflowをci-mergeなど容量が裏付いたラベルへルーティング。 |
| ラベルルーティング優先 | マージ頻度は低いがツールチェーン変種が多い、Xcode／SDKピンを厳密に分けたい。 | merge queueが拾える論理衝突で主幹が壊れる余地が残る。 | 既定ブランチではmerge queueを採用しつつ、ラベルはツールチェーン隔離に専念させる。 |
| 両方併用（スケール時の推奨） | 共有リモートMacプールがPRと主幹の両チェックを担い、リリース枠を予約したい。 | ポリシーが散らばる（timeoutやconcurrencyキーの重複、監査が難しい）。 | concurrency:グループの命名規約と先取り規則を文書化し、下節の閾値表にミラーする。 |
| ホストflockのみでキュー規律なし | 単一の重い相互排他（署名など）を一台に閉じる。 | GitHub側の並列度が観測から隠れる。ロック詰まりが無関係なworkflowまで巻き込む。 | flockには必ずウォールクロックtimeoutとアラート。クリティカルセクションを伸ばす前にノード分割を。詳細はflockビルドキューFAQ。 |
③ パラメータチェックリスト（コピー用）
数値は出発基線です。実測の待ち時間p95、ディスク余裕、署名制約で調整してください。運用可能であることが目的で、各パラメータにオーナー・Runbook・ダッシュボード上の可視性を持たせます。
| パラメータ | 開始基線 | メモ |
|---|---|---|
| merge queue深度／並列 | 重いXcodeプールでは並列1〜2。CPU・ディスク指標に余裕がある場合のみ3を試す | 深い並列はフルリビルドを倍加。チェック項目の扇出にも注意。 |
| Runnerプール待ち深度（アラート） | 同一ラベル集合でpendingが約15〜25件で警告、約40件超はページング級を検討 | ラベルは公平スケジューラではない。作成から割当までの待ち分位を監視。 |
| Runner label（例） | self-hosted、macOS、arm64、xcode-16-2、ci-pr／ci-merge／ci-release |
ci-mergeをノイズの多いPRオプション検査と分離し、merge queueジョブが後回しにされないようにする。 |
Workflow concurrency（並行ロック） |
PR：group: ${{ github.workflow }}-${{ github.ref }}＋cancel-in-progress: true。リリースarchiveはfalse |
複数workflowが同一資源に触れる場合は共有のorg/repo+trunk互斥グループを追加。 |
flockクリティカルセクション |
キーチェーンごとに署名／公証は同時一車線。ロックファイルは文書化したCIボリュームまたは/var/tmp |
下記timeoutとセット。保持者IDをログへ。パターンはキューとロックFAQ。 |
Job timeout-minutes |
PRコンパイル30〜60。archive／export90〜120。キュー再検証はPRと同水準（差分極小なら短縮可） | p95で調整。短めのtimeoutは固まったworkerの回収に効く。 |
シェルtimeout（GNU／BSD） |
ネットワーク呼び出し120〜300秒、アップロード300〜600秒 | 懸垂ったcurlがジョブtimeoutまでRunnerを占有するのを防ぐ。 |
| 先取り規則（優先順位） | PR検査＜任意ナイトリー＜merge queue＜リリース。署名mutex保持者は先取りしない | 優先度はラベルとconcurrencyで表現。調整が難しければ負荷分散とフェイルオーバーでプール分割。 |
④ プール化Macでの方針の組み合わせ
⑤ FAQ
merge queue用ジョブはPRと同じラベルでよいか。
ツールチェーンラベル（例：xcode-16-2）は共有してよい一方、容量ラベルはノイズの多い任意workflowと共有しないでください。merge queueとリリースにはci-merge／ci-release接尾辞を付け、ルーティングの意味を固定します。
二つのリポジトリが一台Macを奪い合うとき、最初に回すつまみは。
まずSKUやプロダクト線でRunnerを分割し、その後でconcurrencyを締めます。ルーティングが正直になる前にmerge queueの並列だけ上げると、ハード競合を審査サイクルに押し戻すだけになります。
次の一手：ノード拡張とプラン見直し
キューが深くなる前にプールを広げる
MeshMacでは複数リモートMacノードを組み合わせられます。mutex争いとRunner pendingが閾値を踏み続けるときは、timeoutをさらに詰めるよりノード追加またはプラン拡張でci-merge／ci-releaseレーンに専用CPUを割り当ててください。