GitHub Actionsで特定Nodeバージョンのテスト失敗を許容する方法

GitHub Actionsで特定Nodeバージョンのテスト失敗を許容する方法
Article actions
View in Markdown

Requires Chrome (latest) built-in AI.

Requires Chrome (latest) built-in AI.

Node.js の最新バージョンがリリースされた直後、プロジェクトの互換性を確認したいが、テストが失敗してもデプロイフローは止めたくない。そんな状況に直面したことはないでしょうか。

この記事では、GitHub Actions の continue-on-error オプションと matrix 戦略を組み合わせて、特定バージョンでのテスト失敗を許容しながら動作監視を継続する方法を解説します。

背景と課題

新しいメジャーバージョンが出た直後は、パッケージの互換性問題やランタイムの変更により、テストが失敗することがあります。しかし、本番環境では安定したバージョンの Node.js を使用しているため、最新バージョンのテスト失敗でリリースプロセス全体を停止させたくありません。

CIでいずれかのバージョンでテストが失敗すると、ワークフロー全体が失敗扱いになります。これでは、build ジョブやリリースワークフローが実行されず、デプロイが止まってしまいます。

理想的なのは、現行バージョンのテストは従来通り厳格に評価しつつ、最新版の結果は参考情報として扱う運用です。

continue-on-error の基本

GitHub Actions の continue-on-error は、ステップやジョブが失敗しても後続の処理を継続させるオプションです。

このオプションを true に設定すると、失敗時の動作が変わります。通常であればワークフロー全体が停止するところ、失敗を記録しつつ次のジョブやステップに進みます。GitHub Actions の UI では、失敗したジョブに警告アイコン(⚠️)が表示されるため、結果の確認は可能です。

重要なのは、continue-on-error が true のジョブが失敗しても、ワークフロー全体のステータスは成功になる点です。これにより、後続の build やデプロイジョブが正常に実行されます。

Matrix 戦略との組み合わせ

複数の Node.js バージョンでテストを実行する場合、matrix 戦略を使うのが一般的です。ここに条件式を組み合わせることで、特定バージョンのみ continue-on-error を有効化できます。

条件式 ${{ matrix.node-version == 26 }} を使えば、Node.js 26 の場合のみ true が返されます。この仕組みを利用して、バージョンごとに異なるエラーハンドリングを実装します。

実装例

以下が、Node.js 26 のテスト失敗を許容する設定例です。

test:
  name: Test
  runs-on: ubuntu-latest
  strategy:
    matrix:
      node-version: [22, 24, 26]
  continue-on-error: ${{ matrix.node-version == 26 }}
  steps:
    - name: Checkout code
      uses: actions/checkout@v6

    - name: Setup pnpm
      uses: pnpm/action-setup@v4
      with:
        version: 9.15.0

    - name: Setup Node.js
      uses: actions/setup-node@v6
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'pnpm'

    - name: Install dependencies
      run: pnpm install --frozen-lockfile

    - name: Run tests
      run: pnpm test

この設定により、以下の動作が実現されます。

Node.js 22 と 24 でテストが失敗した場合、ワークフロー全体が停止します。これは従来通りの動作で、本番環境で使用するバージョンでの品質を保証するためです。

一方、Node.js 26 でテストが失敗しても、ワークフロー全体は続行されます。失敗は警告として記録され、UI で確認できますが、build ジョブやリリースワークフローの実行を妨げません。

運用上のメリット

この設定を導入すると、いくつかの運用上の利点が生まれます。

最新バージョンの動作状況を継続的に監視できるため、将来のバージョンアップ計画が立てやすくなります。Node.js 26 のテストが安定してきたタイミングを、実際のテスト結果から判断できます。

デプロイフローを止めずに新バージョンの検証ができるため、リリース頻度への影響がありません。安定版での開発とリリースを続けながら、並行して次期バージョンへの対応を進められます。

失敗が警告アイコン付きで可視化されるため、チーム全体で最新バージョンの対応状況を共有しやすくなります。いつ本格的な対応作業を開始すべきか、データに基づいた判断が可能です。

まとめ

GitHub Actions の continue-on-error と matrix 戦略を組み合わせることで、特定バージョンのテスト失敗を許容しながら、全体のワークフローを継続できます。

この手法は、最新の Node.js バージョンへの段階的な移行や、実験的な環境での動作確認に有効です。安定版でのリリースを優先しつつ、将来への準備を並行して進められます。

ただし、どのバージョンで失敗を許容するかの判断と、定期的な結果確認は欠かせません。適切な監視体制を整えた上で、この機能を活用してください。

Share:

Hidetaka Okamoto profile photo

Hidetaka Okamoto

Developer Experience Engineer

Developer Experience Engineer. A developer specialized in serverless application development on AWS and Cloudflare. Former Stripe Developer Advocate / AWS Samurai 2017. Skilled in creating content and presentations that introduce service usage and best practices. You can follow me on Twitter at @hidetaka_dev