要約

  • GitHub Actions の並行実行は、同じ名前のグループに解決されるジョブまたはワークフロー実行を対象にする。待機中の作業は設定により置換、待機、取消しになり得る。
  • GitHub は、並行実行と environment は自動的には結び付かないと明記している。同じ環境を使う別のワークフローが、あるグループの規則に従うとは限らない。
  • 「デプロイは直列化された」と言うには、展開後のグループ名、構成員、実行記録、対象側の観測を結び付ける必要がある。設定画面上のグループ名だけでは足りない。

「本番は一度に一つだけ動く」という説明は、観測結果ではなく設計意図を短く言い換えたものになりやすい。GitHub Actions では、ワークフローまたはジョブに並行実行グループを設定できる。同じグループへ解決される作業の同時実行を抑え、保留中の実行を新しい実行で置き換え、明示的にキューを選べば待機列を保てる。これは有効なスケジューリング制御である。しかし、その名前が対象環境に接続するすべての経路を捕捉するわけではない。効力の範囲は、実際にそのグループへ解決されるジョブと実行から始まる。

通常の既定動作にも注意が要る。GitHub の説明では、一つのグループに実行中の仕事が一つ、保留中の仕事が一つ存在でき、さらに新しい候補が来れば先の保留を置き換え得る。queue: max は待機列の上限を明示する設定であり、cancel-in-progress: true は既に動き始めた仕事も中止し得る。これは同じ結果ではない。一つの実行がキューに入った記録は、先に保留されていた実行が残った証拠ではない。取消された実行の記録も、停止時点までに外部 API 呼出し、成果物公開、対象側変更がなかったことを意味しない。

順序も設定名からは読めない。GitHub は、キューに入った実行を待機開始時刻に基づいて FIFO として扱う一方、実際の開始時刻は変わり得るとしている。したがって、グループを普遍的な時系列の代用にしてはならない。順序を主張するなら、展開済みグループキー、関係するジョブまたは実行の識別子、待機・開始・終了の時刻と結論、さらに使われたソースと成果物の識別子を揃える必要がある。画面に出る dispatch 時刻だけでは、その結論に届かない。

デプロイの文脈では、並行実行と environment の差が重要になる。GitHub は両者が接続されていないと述べている。並行実行の値は任意の文字列であり、同じ environment を使用しても当該グループを指定しないワークフローは、その規則の対象にならない。environment には保護規則やシークレットなど固有の制御があり得るが、それは共有グループ式の代わりではない。反対に共有グループ式も、environment 全体をロックする装置ではない。両者は別の構成面である。

並行実行グループ API は、現在アクティブなグループのメンバーと、pending または in-progress の状態を見せられる。運用上、これは価値のある証拠になる。ただし範囲は現在のプラットフォーム内に限られる。過去の全コマンドや対象の状態を復元する台帳ではない。対象を後から検査するなら、手法と時刻を伴う別個の記録として保存すべきである。

Daniel Kade が勧めるのは七点の「直列化レシート」だ。並行実行式と展開済みキー、キューと取消しの設定、関係する実行・ジョブの構成員と時刻・処分、正確なコミットと不変の成果物、environment の選択、実行の証拠、そして時点を限定した対象観測を残す。対象の詳細が機密なら保護すればよい。グループ名がもたらす安心感で、欠けた結合まで埋めてはならない。

出典

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API