GitHub ActionsでNode.jsのPR CIを作る - lint・test・build

初級 | 15分 で読める | 2025.12.02

公式ドキュメント

今回やること

Node.jsプロジェクトのPull Requestで、次の4コマンドを自動実行するCIを作ります。

npm ci → npm run lint → npm test → npm run build

CI(継続的インテグレーション)は、変更をmainへ取り込む前に同じ検査を自動実行する仕組みです。この記事ではデプロイまで広げず、PRの品質確認だけを完成させます。

eventがGitHub Actions workflowを起動し、複数jobがそれぞれ別runner上でstepを順序実行し、必要なjob間だけneedsで依存する階層図

前提条件

  • GitHub上にNode.jsプロジェクトがある
  • package-lock.jsonをコミットしている
  • 次のnpm scriptsがローカルで成功する
npm run lint
npm test
npm run build

プロジェクトによってコマンド名は異なります。package.jsonscriptsに存在しないコマンドは、CIを作る前に用意してください。

Workflowを作る

リポジトリに.github/workflows/ci.ymlを作成します。

name: Node CI

on:
  pull_request:
    branches:
      - main

permissions:
  contents: read

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Test
        run: npm test

      - name: Build
        run: npm run build

このWorkflowには1つのquality jobがあり、同じrunner上でstepを上から順番に実行します。途中のコマンドが失敗すると、それ以降のstepは通常実行されません。

設定の要点

permissions: contents: readは、自動発行されるGITHUB_TOKENの権限を読み取りへ限定します。このCIはリポジトリへ書き込まないため、書き込み権限は不要です。

cache: npmが保存するのはnpmのパッケージ管理用キャッシュであり、node_modulesではありません。そのため、キャッシュが復元されてもnpm ciは毎回必要です。package-lock.jsonに従って依存関係を入れ直すことで、再現性を保ちます。

この学習例では読みやすさと更新しやすさを優先し、GitHub公式Actionのmajor tag(@v6)を使っています。第三者Actionや権限の強い本番Workflowでは、供給元を確認し、改変されない完全なcommit SHAへの固定を検討してください。

成功を確認する

  1. 作業ブランチへ.github/workflows/ci.ymlをコミットしてpushする
  2. GitHubでmain向けPull Requestを作る
  3. Pull Requestの「Checks」を開く
  4. Node CI / qualityが緑のチェックになることを確認する

各stepを開くと、npm ci、lint、test、buildのログを確認できます。

よくあるエラー

npm ciが失敗する

package.jsonpackage-lock.jsonが一致していない可能性があります。ローカルで次を実行し、更新されたlockfileもコミットします。

npm install
npm ci

Missing script: lintと表示される

package.jsonscriptslintがありません。実際のプロジェクトに合わせてscriptを追加するか、Workflowのコマンド名を直します。

ローカルでは成功するのにCIだけ失敗する

ファイル名の大文字・小文字、コミット漏れ、Node.jsバージョンを確認します。Linux runnerではUser.tsuser.tsは別のファイルです。

CIが起動しない

Pull Requestの取り込み先がmainか、Workflowファイルが.github/workflows/にあるか、YAMLのインデントがスペースになっているかを確認します。

練習

テストを意図的に1つ失敗させてpushし、PRのチェックが赤になることを確認してください。ログから失敗したstepを特定したら、テストを元へ戻して再び緑にします。

次のステップ

CIが安定してから実行時間を計測し、必要な場合だけGitHub ActionsでCIを高速化する基本へ進んでください。

参考リソース

(最終確認: 2026年7月25日)

← 一覧に戻る
PR
PR
PR
PR