GitHub Actions最小CI (lint+test)

学習のねらい

AI が書いたコードを、人がレビューする前に「自動チェック」で先に確認するしくみが CI(Continuous Integration、継続的インテグレーション)です。 lint(コードの書式チェック)や test(動作チェック)が CI で失敗(赤色表示)した PR は merge しない、というシンプルなルールだけで、基本的なミスを早めに見つけやすくなります。

最小の YAML

.github/workflows/ci.yml に下のファイルを置くだけで、PR ごとに自動チェックが走ります。

name: ci
on:
  pull_request:
  push:
    branches: [main]
jobs:
  py:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install ruff pytest
      - run: ruff check .
      - run: pytest -q

Node を混ぜる場合は、同様に setup-node と npm test を別ジョブとして追加します。

なぜ最小から始めるのか

最初からテスト網羅率(coverage)の最低ライン、セキュリティスキャン、依存ライブラリのチェックなどを盛り込みすぎると、赤色のままにする習慣がつきがちです。 まずは「赤になったら必ず直す、緑のときだけ merge する」という基本を身につける方が、長く続けやすくなります。 発展的なチェックは第7章(セキュリティ)で扱います。

branch protection(ブランチの保護)

GitHub の Settings → Branches で main ブランチに対して Require status checks to pass before merging を ON にすると、CI が緑のときしか merge ボタンが押せなくなります(管理者は緊急時にだけ手動で上書きできます)。 これを ON にしておくと、うっかり赤の PR を merge してしまうことを防げます。

AI が書いたコードと CI の相性

AI は「動くコード」を返してくれますが、lint と test はまた別の確認です。 使っていない import 文、型ヒントの食い違い、想定外の入力(例: 空文字列やマイナス値)への対応漏れなどは、lint と test で見つけられます。 AI 出力 → lint 緑 → test 緑 → 自分の目視レビュー、という段階を踏むのを習慣にしましょう。

まとめ

最小の CI は YAML 10行ほどで作れます。 CI が赤の PR を merge しない運用と branch protection をセットで導入することで、AI が作ったコードでも安心して取り込めるベース環境が整います。