GitHub Actionsのステップを並列実行できるようになった

GitHub Actionsで、ジョブ内のステップを並列実行できるようになりました。

ステップは上から順番に実行されるのが基本です。
シェルのバックグラウンド実行 (&) を使えば並列実行は可能だったものの、制御が難しかったりログが混ざったりといった問題がありました。

新機能の使い方と従来のジョブ並列との違い、使いどころを整理していきます。

使い方

parallel を使う

シンプルに複数のコマンドを並列実行する場合は parallel: の下にステップを並べます。

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

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

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

          - name: Build docs
            run: npm run build:docs

      - name: Run tests
        run: npm test

この場合 npm run build:* を同時に実行し、すべて終わってから次に進みます。

background と wait を使う

もう少し柔軟に制御したい場合は background を使います。

name: build

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Build frontend
        id: build-frontend
        run: npm run build:frontend
        background: true

      - name: Build backend
        id: build-backend
        run: npm run build:backend
        background: true

      - name: Run linter while builds are running
        run: npm run lint

      - name: Wait for builds
        wait: [build-frontend, build-backend]

      - name: Run tests
        run: npm test

background: true を付けると、そのステップはバックグラウンドで実行され、完了を待たずに次のステップへ進みます。

• wait: 指定したステップの完了を待つ
• wait-all: 実行中のすべてを待つ
• cancel: 実行中のステップを停止する

parallel との違いは、途中に別の処理を挟めることです。ビルドを裏で走らせながら lint を実行する、といった書き方ができます。

サーバーを裏で起動する

background はサーバー用途にも便利です。

on:
  push:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Install dependencies
        run: npm ci

      - name: Start app server
        id: app-server
        run: npm start
        background: true

      - name: Run integration tests
        run: npm run test:integration

      - name: Stop app server
        cancel: app-server

テストの間だけサーバーを動かし、最後に cancel で止めます。

これまでもシェルでバックグラウンド起動はできましたが、ステップとして分離できることでログや制御が扱いやすくなります。

ジョブ並列との違い

これまでもジョブを分けることで並列実行は可能でしたが、従来のジョブの並列実行は別runnerで動きます。一方、今回の機能は同じrunner上で動きます。

観点	ジョブ並列	ステップ並列
実行場所	別runner	同じrunner
ファイル	共有されない	共有される
用途	OS違い・大きな処理	同一環境での並列処理

同じ環境・同じファイルを使いたい場合はステップ並列が向いています。逆に、OS違いや言語バージョン違いのテストなどは従来どおりmatrixを使ったジョブ並列の方が自然です。

こんなときに便利かも

• 依存関係のない複数のビルド
  同じ依存関係インストール結果を使いながら、複数のビルドだけを並列化できる

• サーバーを起動して統合テスト
  アプリケーションやモックサーバーを裏で動かしながらテストできる

• 裏で補助処理を動かす
  ビルド中に別の検証や生成処理を進めるなど、待ち時間を減らせる

あまり向かなそうなケース

• テストやビルドツール側で並列化できる場合

  • テストフレームワークやビルドツール（make など）の多くは並列実行機能を持っており、ツール側で処理の並列実行が可能です。そちらを使えるならその方がシンプルですし、わざわざGitHub Actionsを書き換える旨味は少ないでしょう。

• CPUバウンドな大量処理

  • ステップ並列は同じrunner上で動くため、CPUコア数以上に並列化しても性能は伸びません。むしろコンテキストスイッチやメモリ競合で遅くなることがあります。本当に並列化したい場合はジョブを分ける方が適しています。

• 同じファイルを書き換える処理

  • 同じrunner上でファイルシステムを共有するため、複数のステップが同じファイルやディレクトリを書き換えると競合が起きます。出力先を分けるなどの設計が必要になります。

まとめ

ステップ並列実行機能によって、GitHub Actionsの実装の選択肢が広がりました。
使い方や使いどころを理解して上手く利用し、CIの高速化にも繋げましょう！