GitHub Actions入門 — 商品の計算テストを自動で確かめよう

ひよこ

変更するたびにテストするのを忘れそう……。

ペンギン先生

GitHub Actionsなら、GitHubへ変更を送ったときなどに決めた作業を実行できるよ。まずは「200円の商品を2個買うと400円」のテストだけを自動化しよう。

ひよこ

いきなりサイトが公開されるの？

ペンギン先生

今回の設定はテストだけ。公開したければ、そのための処理と権限を別に設定するんだ。CIは変更を継続的に確かめる活動で、CDにも公開の準備までと自動公開までの違いがあるよ。

ひよこ

設定はどこに書くの？

ペンギン先生

リポジトリの.github/workflows/ci.ymlへ書くよ。onで開始条件、jobsで仕事、stepsで順番を決めるんだ。今回はmainへのpushと手動実行を選ぼう。

ひよこ

テストは自分のPCで動くの？

ペンギン先生

Actionsではrunnerという実行環境で動くよ。ここではGitHub側のUbuntu環境を使うんだ。その前に同じテストを自分のPCで実行して、コード自体が動くか確かめよう。

ひよこ

赤い表示になったらどうしよう？

ペンギン先生

失敗したstepのログを開こう。「期待した400と実際の値が違う」のか、「ファイルがない」のかを見分けるんだ。失敗したまま公開を進めない設定は、公開用のjobでも必要だよ。

ひよこ

actions/checkoutって何？

ペンギン先生

リポジトリのファイルをrunnerへ取り込む部品だよ。setup-nodeはNode.jsを準備する部品。例では確認した版のコミットSHAに固定し、読み取りだけの権限で使うよ。

ひよこ

パスワードも設定ファイルに書くの？

ペンギン先生

書かないよ。今回のテストには秘密情報自体が不要なんだ。後でSecretsなどを使う場合も、信頼できないコードに渡したりログへ出したりしないよう、権限と実行条件を確認しよう。

ひよこ

まず覚えることは？

ペンギン先生

「GitHub Actions」って出てきたら「GitHubで決めたきっかけから作業を実行する仕組み」と思えばだいたいOK！まずはテストの成功を1回確認しよう。

最初のゴール：緑のチェックを1つ付ける

GitHubアカウント、Gitの基本操作、Node.js 24が必要です。Git入門を参考に、自分の練習用リポジトリを用意してください。ここでは有料サービスへの接続やサイトの公開はしません。GitHub Actionsの利用条件・実行枠は契約によって異なります。

まず自分のPCで計算を確かめる

空の練習用フォルダーにtotal.test.mjsを作ります。Node.jsに含まれるテスト機能なので、外部パッケージのインストールは不要です。

import test from 'node:test';
import assert from 'node:assert/strict';

function total(price, count) {
  return price * count;
}

test('200円を2個買うと400円', () => {
  assert.equal(total(200, 2), 400);
});

そのフォルダーでnode --testを実行します。テストが1件成功し、失敗が0件なら次へ進みましょう。練習として期待値を399へ変えると失敗するので、ログを読んでから400へ戻します。入力が正しいか、税込かなどは別のテストが必要です。

GitHub側にも同じ作業を頼む

.github/workflows/ci.ymlを作ります。次のSHAは確認時点のcheckout v7、setup-node v7のものです。新しい版へ更新するときは、提供元のリポジトリと変更内容を確認します。

name: Learning test
on:
  push:
    branches: [main]
  workflow_dispatch:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
        with:
          node-version: '24'
          package-manager-cache: false
      - run: node --test

テストとYAMLを自分のリポジトリへコミットし、mainへpushします。別の既定ブランチを使う場合は名前を合わせてください。GitHubのActions → Learning test → 実行結果でテストstepを開き、成功1件を確認します。手動のRun workflowを表示するには、workflow_dispatchを書いたファイルを既定ブランチへ置く必要があります。

赤いチェックの調べ方

依存パッケージを追加したアプリでは、lockファイルをコミットし、テスト前にnpm ciなどで準備します。今回の例には依存がないので、そのstepを入れていません。キャッシュは再取得を減らす工夫であり、テストを省く仕組みや高速化の保証ではありません。

公開処理を足す前に

公開は別の作業です。テスト成功後にだけ実行するjobの依存関係、対象環境、承認の有無、必要最小限の権限を決めましょう。Secretsのマスクだけで情報漏えいを防げるわけではありません。外部のpull requestのコードに公開権限を渡す設定は特に注意が必要です。

次はDocker入門で実行環境をそろえる方法を学べます。最初はテスト1件の成功と失敗を読めることが出発点です。

参考資料

• GitHub Actionsの開始手順 — workflow・job・stepの関係
• 実行のきっかけ — 手動実行と既定ブランチ
• checkoutの提供元 — v7と資格情報の扱い
• setup-nodeの提供元 — Nodeと自動キャッシュの設定
• Actionsの安全な利用 — SHA固定と権限・信頼できない入力
• Node.jsテストランナー — node:testと実行方法