# GitHub Actions入門：プッシュだけでCI/CDを回す仕組みを一気に理解するメモ

はじめに

GitHub Actionsは「プッシュしたら即テスト→デプロイ」を完結させる仕掛けを、GitHubだけで実現できる自動化エンジンだ。CircleCIやTravis CIに慣れていた頃は外部サービスとAPIトークンを行ったり来たりしていたが、いざActionsを触り始めると「リポジトリ内のYAMLを書くだけで全部動く」手軽さに驚く。ここでは、自分が使いながら整理した「最低限知っておくべき仕組み」と「よく使う設定パターン」を備忘録的にまとめておく。

---

1️⃣ GitHub Actionsの全体像

• ワークフロー (workflow) … .github/workflows/*.yml に置く1ファイル＝1自動化シナリオ。
• イベント (event) … push, pull_request, schedule など。「何が起きたら走るか」を決める。
• ジョブ (job) … ワークフロー内の処理ブロック。デフォルトで並列に動く。
• ランナー (runner) … ジョブを実行する仮想マシン。ubuntu-latest などを選ぶ。他に自前サーバーを登録する「セルフホストランナー」もある。
• ステップ (step) … ジョブの中で上から順に実行するコマンド／アクション。
• アクション (action) … 再利用可能なスクリプトのパッケージ。actions/checkout@v4 や actions/setup-node@v4 が定番。

この五階層 ―― workflow → job → step → action という入れ子構造さえ掴めば、あとはYAMLで積み木を組む感覚になる。

---

2️⃣ 最小構成サンプル

name: test-on-push
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

1. push をトリガーに
2. Ubuntu上で npm ci → npm test を実行
3. テスト結果がGitHubのPR画面にバッジで返ってくる

これだけでCIの土台ができる。成功・失敗ログを毎回確認できるので、ローカル環境差分による「動く／動かない」論争が激減する。

---

3️⃣ よく使うイベントと実行タイミング

典型イベント	いつ発火するか	使いどころ
push	ブランチにコードがプッシュされた瞬間	単体テスト、静的解析
pull_request	PRが開かれた／更新された	PRごとの統合テスト、レビューチェック
workflow_dispatch	手動トリガー	臨時リリースや緊急パッチ
schedule	cron式で定期実行	バッチ処理、リンクチェッカー
release	GitHub Release作成時	パッケージ公開、タグ付きデプロイ

自分の場合は push と pull_request でテスト → main ブランチにマージされたら workflow_dispatch でデプロイ、という二段構えが多い。

---

4️⃣ Actions Marketplaceで拾う定番アクション

• actions/checkout … リポジトリをRunnerにクローン。ほぼ必須。
• actions/setup-node / setup-python … 言語ランタイムを一行でセットアップ。
• actions/cache … npm や pip の依存をキャッシュしてビルド高速化。
• peaceiris/actions-gh-pages … 静的サイトをGitHub Pagesへデプロイ。
• aws-actions/configure-aws-credentials … AWSデプロイ用の認証情報注入。

Marketplaceを眺めていると「これ自分でシェル書いてた…」という処理がたいてい既製品で転がっている。自作する前に検索が吉。

---

5️⃣ シークレット管理の勘所

リポジトリの Settings → Secrets and variables にAPIキーを入れておくと、ワークフロー内で secrets.MY_TOKEN と参照できる。ポイントは 環境変数へ直接エコーしない こと。ログに値が漏れる恐れがあるので、必要最小限のコマンド引数に渡すか、標準入力から読む工夫をしている。

---

6️⃣ デプロイパターン別スニペット

GitHub Pages（静的サイト）

      - run: npm run build
      - uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

AWS S3

      - run: npm run build
      - uses: jakejarvis/s3-sync-action@v0.5.1
        with:
          args: --acl public-read --follow-symlinks
        env:
          AWS_S3_BUCKET: ${{ secrets.BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ap-northeast-1

Docker Hub

      - run: docker build -t ${{ secrets.USER }}/app:${{ github.sha }} .
      - run: echo ${{ secrets.PAT }} | docker login -u ${{ secrets.USER }} --password-stdin
      - run: docker push ${{ secrets.USER }}/app:${{ github.sha }}

---

7️⃣ セルフホストランナーを置いてみた雑感

社内GPUサーバーでテストしたいケースがあり、Runnerを自己管理した。

• メリット … スペック制限なし、ジョブの待ち時間ゼロ、ネットワーク閉域。
• デメリット … セキュリティパッチ適用・ログローテートなど運用コスト復活。
  結果として「頻繁にGPUを叩くCI」以外はGitHub提供ランナーの方が楽、という落としどころ。

---

8️⃣ 使ってみて感じたメリット

1. GitHub UIだけで完結：PR画面でテスト結果・デプロイログまで確認できる。
2. 学習コストが低い：YAML×イベントドリブンという単純モデル。
3. 無料枠が太い：パブリックリポジトリなら月無制限。プライベートでも月2,000分は十分。
4. Marketplaceが便利：既存アクションで8割方組めてしまう。
5. マトリクス並列実行：Node 20/22 × OS3種 など環境組み合わせテストが一行で書ける。

---

おわりに

「CI/CDは面倒そうだから後回し」という昔の自分に、GitHub Actionsを教えてやりたい。プッシュ一発でテスト・リリースが転がり始める体験は想像以上に開発テンポを上げてくれる。YAMLを数十行書くだけで済むので、まだ触っていなければ試しに echo ワークフローから始めてみると良い。