workflow は、GitHub Actions における自動処理の定義単位です。
リポジトリの .github/workflows/ に置いた YAML ファイル1つが、1つの workflow になります。
3つの階層を区別する
用語が入れ子になっているので、ここを混同すると設定が読めません。
| 単位 | 意味 | 実行される場所 |
|---|---|---|
| workflow | ファイル1つ。いつ動くかを定義 | — |
| job | 独立した処理のまとまり | jobごとに別のrunner |
| step | job の中の1手順 | 同じ runner |
重要なのはjobごとにマシンが変わるという点です。ビルドしたファイルは、別の job では消えています。渡したいなら成果物として明示的に受け渡す必要があります。「ビルドは通ったのにデプロイでファイルが無い」の原因はほぼこれです。
いつ動かすかの設計
on: で起動条件を書きます。何も絞らないと、関係のない変更でも毎回フルビルドが走り、待ち時間と課金が積み上がります。
- ブランチを絞る（
mainへのpushだけ、など） - パスを絞る（ドキュメントだけの変更ではビルドしない）
- 手動実行（
workflow_dispatch）を用意しておくと運用が楽
並行実行を止める仕組みを入れる
連続でpushしたとき、既定では古い実行も最後まで走ります。デプロイ系の workflow でこれが起きると、古いコードが後から本番へ上書きされることがあります。
同時実行を1本に制限し、古いものを打ち切る設定（concurrency）を入れておくと防げます。flock で二重起動を止めるのと同じ考え方です。