Issue と GitHub Actions — 課題管理と自動化

学習目標

このレッスンを終えると、次のことができるようになります。

GitHub Issue の役割と PR との関係を理解できる
Issue / PR の番号でクロスリンクする書き方を使える
GitHub Actions の役割を 1 行で説明し、ailms での運用を読める

Issue とは

Issue (イシュー) = リポジトリに紐づくやること・バグ報告・議論の単位。

flowchart LR I[Issue 作成 「ログイン後の遷移先がバグ」] --> A[担当を assign] A --> B[branch を切る fix/login-redirect-#123] B --> P[PR を作る "Closes #123"] P --> M[merge で Issue 自動 close]

Issue は「これからやる」「議論中」「バグ報告」など何でも置ける。チャットツールに流れて消える話題を 永続化された場 に書ける。

Issue のクロスリンク

PR 説明文・commit メッセージに #123 と書くと Issue 123 への自動リンクになる。

記法	効果
`#123`	Issue / PR 123 へのリンク
`Closes #123` (PR 説明文)	merge 時に Issue 123 を自動クローズ
`Fixes #123`	同上 (バグ用)
`Refs #123`	関連付けるが自動クローズしない
`compassdata/ailms#123`	別リポジトリの Issue 参照

例:

## 概要
ログイン後のリダイレクト先を /home に統一する。

## 関連
Fixes #123
Refs #100

Label とマイルストーン

機能	用途
Label	`bug` / `enhancement` / `documentation` / `good first issue` 等。検索・絞り込み
Milestone	「v2.0 リリースまでに片付ける Issue 群」のグルーピング
Project	カンバン形式の進捗管理

ailms では priority: P1/P2/P3 / area: marketing/authoring/billing 等の label を使い分けている。

GitHub Actions — 自動化の中核

GitHub Actions = push / PR / cron をトリガーに任意のコマンドを自動実行する仕組み。

代表的な用途:

flowchart TB PR[Pull Request 作成] --> T[テスト実行] T --> L[Lint チェック] L --> S[セキュリティスキャン] S --> C{全部緑?} C -->|Yes| M[merge ボタン有効化] C -->|No| F[merge ブロック 結果表示] P[push to main] --> D[本番デプロイ] P --> N[Slack 通知] CR[毎日 0:00 cron] --> B[バックアップ実行] CR --> R[リポート生成]

設定ファイルの場所

.github/workflows/*.yml に置く。例:

name: CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: pytest

ailms で動いているもの (一部)

ワークフロー	トリガー	目的
`ci-tests.yml`	PR / push	テスト + lint
`deploy-prod.yml`	main への merge	本番デプロイ
`lp-monitor.yml`	日次 cron	LP 死活監視
`weekly-audit.yml`	週次 cron	コンテンツ品質監査

実物は .github/workflows/ ディレクトリで確認できる。

Status check と保護ルール連動

「テストが通らないと merge できない」を実現するには:

GitHub Actions で pytest が走るワークフローを作る
Settings → Branches → main の保護ルールで 「Require status checks to pass before merging」 を有効化
その中で pytest (上の job 名) を必須にチェック

→ PR を出してテストが赤いと、 merge ボタンが灰色のまま押せない。人間の意志に頼らず仕組みで止める。

自動化のアンチパターン

やりがちなこと	何が悪い
シークレットを `.yml` に直書き	履歴に永久保存 → 漏洩
`secrets.GITHUB_TOKEN` を雑に渡す	権限スコープを最小に
自分の PR を自分で auto-merge	レビュー回避 (規制)
Actions の job タイムアウト未設定	暴走でクレジット消費

ailms では GITHUB_TOKEN の権限を Settings → Actions で read-only デフォルト にしている。書き込みが必要な job だけ明示的に permissions を付与。

振り返り

Issue = やること / バグ / 議論。#123 でクロスリンク、Closes #123 で自動クローズ
GitHub Actions = push / PR / cron トリガーの自動化。.github/workflows/*.yml
Status check + 保護ルールで「テスト緑じゃないと merge できない」を機械的に強制

次のセクションでは、AI Agent と Git/GitHub をどう組み合わせるかの 応用編 に進みます。

参考リンク

GitHub Docs「Issue について」: https://docs.github.com/ja/issues/tracking-your-work-with-issues/about-issues
GitHub Actions 公式: https://docs.github.com/ja/actions
ailms .github/workflows/ を直接見る

他の講座を見る次のプレビューレッスンへ →

全 14 レッスンを、登録なしで無料で読めます。