同一 job で steps を並列にする

parallel か background。job の matrix とは別。ログはステップごとに分かれる。

  • #GitHub Actions

同一 job 内なら parallel か background。job を増やす話ではない。

#parallel

独立したステップを同時実行し、全部終わるまで次へ進まない。内部では各ステップが background になり、末尾で暗黙の wait が走る。

yaml
steps:
  - uses: actions/checkout@v6

  - parallel:
      - name: Build frontend
        run: npm run build:frontend
      - name: Build backend
        run: npm run build:backend

  - name: Run tests after all builds complete
    run: npm test

#background / wait / cancel

起動したらすぐ次へ進み、必要なタイミングで待つ・止める。サーバを立てて本処理し、最後に止める流れ向き。

yaml
steps:
  - name: Start server
    id: server
    run: npm start
    background: true

  - name: Run tests against the server
    run: npm test

  - name: Stop the server
    cancel: server
  • wait: 指定 id の完了を待つ（文字列または配列）
  • wait-all: 実行中の background すべてを待つ
  • cancel: 指定 id へ終了信号。まず SIGTERM、だめなら SIGKILL

cancel に if は付けられない。制御フロー用ステップとして常に実行される。

#制約

  • 同一 job の同時 background は最大 10。超えた分はキュー。foreground はスロットが埋まっていてもすぐ実行される
  • composite action の中では background / parallel を宣言できない。composite 自体を background にすることはできる
  • wait / wait-all / cancel に if は付けられない
  • outputs や環境変更は、それを含む wait / wait-all の後でのみ使える
  • background が失敗すると、それを待つ wait / wait-all で job が失敗する（continue-on-error がある場合を除く）
  • ジョブ終了前の post 処理の前に、未 wait の background へ暗黙の wait-all が走る

#job 並列との使い分け

観点job 並列（needs / matrix）steps 並列
ランナー別ランナー同一ランナー
セットアップ各 job で重複しやすい1 回の setup を共有できる
ファイルシステム分離共有
向く処理CPU を食い合う重い独立処理I/O 待ち、軽い独立チェック、サービス起動

CPU を使い切る独立タスクは matrix や別 job の方が終わりやすい。待ちが支配的な処理や、同一ワークスペース上の軽いチェックは steps 並列向き。

次のときは分けたままの方がよい。

  • トリガーが違う（PR では lint のみ、本番ブランチだけデプロイ、など）

  • デプロイ用の強い secrets を lint 側に載せたくない

  • 必須チェックや失敗の意味を workflow 単位で分けたい

  • GitHub Actions の steps 並列で CI/CD を最適化する

編集