GitHub Actions の matrix で 1 件失敗すると他のジョブが実行できない

要約

matrix で 1 件のジョブが失敗したとき他のジョブがキャンセル扱い（cancelled）になるのは、strategy.fail-fast が既定で true だからです。
fail-fast が有効だと、matrix 内のどれか 1 つが失敗した時点で、進行中・待機中の残りのジョブはすべてキャンセルされます（公式ドキュメント（新しいタブで開く）↗）。
全組み合わせの結果を見たい場合は fail-fast: false を明示します。
ただし実際の GitHub Actions で試すと、Cancelled と表示されたジョブの中身が最後まで実行されていた回がありました（解決策 3 の補足）。

実行例

GitHub の ubuntu-latest ランナーで 3 並列の matrix のうち v=2 だけを即座に失敗させると、v=1 と v=3 は 60 秒かかるステップの最初の 10 秒待ちを終える前（失敗から約 10 秒後）に止められ、後続のステップも実行されないまま、ジョブの結論は cancelled になった。
この回は、解決策 3 の補足にある 9 月 20 日の回と同じ止まり方である。

# start v=2 00:55:11
v=2 を失敗させる 00:55:11
##[error]Process completed with exit code 1.

# start v=1 00:55:12
##[error]The operation was canceled.

# start v=3 00:55:12
##[error]The operation was canceled.

$ gh run view 36079709297 --json jobs --jq '.jobs[] | select(.name | startswith("matrix")) | {name, conclusion}'
{"conclusion":"cancelled","name":"matrix-fail-fast (1)"}
{"conclusion":"cancelled","name":"matrix-fail-fast (3)"}
{"conclusion":"failure","name":"matrix-fail-fast (2)"}

— 2026-09-25 時点の出力

よくある原因

1. fail-fast の既定値: strategy.fail-fast は未指定だと true。
   Node.js 18/20/22 のような matrix で 1 つが落ちると、残りのジョブはキャンセル扱い（cancelled）になる。
2. 実験的ジョブの失敗が波及: 次期バージョンなど「落ちても構わない」ジョブに continue-on-error を付けていないと、その失敗が matrix 全体を止める。
3. failed と cancelled の混同: キャンセルされたジョブには失敗の原因情報が無い。
   調べるべきは最初に failed になった 1 件だけ。
4. concurrency による別系統のキャンセル: 同じ concurrency グループに cancel-in-progress: true があると、新しい push が古い実行を止める。
   matrix の問題と見分けが必要。

解決策

1. fail-fast を無効化して全件実行する

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node-version: [18, 20, 22]

全組み合わせが最後まで実行され、どのバージョンで失敗するかを一覧で確認できます。

2. 特定ジョブだけ失敗を許容する

    strategy:
      fail-fast: true
      matrix:
        node-version: [20, 22]
        experimental: [false]
        include:
          - node-version: 24
            experimental: true
    continue-on-error: ${{ matrix.experimental }}

continue-on-error: true のジョブは失敗してもジョブ自体が成功扱いになり、fail-fast のキャンセルを誘発しません（matrix の公式ガイド（新しいタブで開く）↗）。

3. 調査対象を最初の失敗に絞る

実行サマリーで「Failure」になっているジョブを探し、その 1 件のログだけを読みます。
「Cancelled」のジョブは fail-fast の巻き添えであり、そこに原因はありません。

ただし「Cancelled」は、処理が途中で止まったことを意味するとは限りません。
2026 年 9 月に実際の GitHub Actions で 3 並列の matrix（1 つだけ即座に失敗させ、残り 2 つは 60 秒かかるステップを実行）を試したところ、9 月 23〜24 日の 6 回はすべて、残り 2 つのジョブが 60 秒のステップを最後まで実行したうえで Cancelled と表示されました。
後ろにもう 1 ステップを足した 2 回では、そのステップも実行されています。
一方、9 月 20 日と 25 日の各 1 回は、失敗からそれぞれ約 14 秒・約 10 秒で実行中のステップが止められ、25 日の回は後ろのステップも実行されませんでした（skipped）。
デプロイや外部への書き込みを matrix で並列に走らせている場合は、表示だけで判断せず、各ジョブのログで実際にどこまで実行されたかを確認してください。