GitHub Actions生成ツール

GitHub Actionsの概要・基礎知識

GitHub ActionsはGitHubが提供するCI/CDサービスで、リポジトリ内の.github/workflows/ディレクトリに配置したYAMLファイルをトリガーに、テスト・ビルド・デプロイなどを実行できます。push・pull_request・スケジュール(cron)・手動実行など、さまざまなイベントに反応するパイプラインを宣言的に定義できる点が特徴です。本ツールはNode.js CI・Python CI・Docker Build & Push・GitHub Pages・Releaseといった代表的なワークフローのテンプレートを揃え、ランナー・ブランチ・matrix戦略・キャッシュ・環境変数を選ぶだけで実用的なYAMLを生成します。

主要テンプレートと用途

テンプレート用途主なアクション
Node.js CInpm/pnpm/yarnのテスト・ビルドactions/setup-node
Python CIpytest・linterの実行actions/setup-python
Docker Build & Pushイメージのビルドとレジストリ登録docker/build-push-action
Deploy to Pages静的サイトをGitHub Pagesへ公開actions/deploy-pages
Releaseタグpush時のリリース作成softprops/action-gh-release
カスタム最小構成のひな形actions/checkout

使い方の流れ

  1. Step 1で利用したいテンプレートを選びます。テンプレートごとに必要な入力項目(Node.jsバージョン・Pythonバージョン等)が自動で表示されます。
  2. Step 2でワークフロー名・トリガー(push / pull_request / workflow_dispatch / schedule)・対象ブランチを設定します。scheduleを選ぶとcron式を入力できます。
  3. Step 3でランナー(ubuntu-latest / macos-latest / windows-latest)を選びます。クロスプラットフォーム検証が必要ならmatrix戦略でNodeやPythonの複数バージョンも指定できます。
  4. Step 4でキャッシュの有無や環境変数(KEY=VALUE形式)を設定します。npm依存などをキャッシュすると2回目以降のビルド時間が大きく短縮されます。
  5. 「ワークフローを生成」を押すと整形済みYAMLが表示されます。コピーして.github/workflows/ci.yml等の名前で保存し、リポジトリへpushすれば即座に動作開始します。

こんな場面で使う

  • 新規OSSリポジトリのCI整備:作成直後にCIテンプレートを投入することで、最初のPRから自動テストが回る環境を即座に作れます。
  • Dockerイメージの自動公開:mainブランチへのマージをトリガーに、GHCRやDocker Hubへイメージを自動pushする運用を素早く構築できます。
  • 静的サイトのデプロイ:Astro・Hugo・Next.js Static Exportなどで作ったサイトをGitHub Pagesへ自動公開できます。
  • 定期バッチ処理:cronトリガーで日次レポート生成やデータスクレイピングを無料枠内で動かせます(パブリックリポジトリは無制限、プライベートは月間枠内)。
  • リリースノートの自動生成:v1.0.0などのタグpushを契機にリリース作成・成果物アップロードまで自動化できます。

使う前に知っておきたい注意点

  • 本ツールが生成するYAMLは標準的なベストプラクティス例です。プロジェクト固有のテストコマンドやデプロイ先設定は、生成後に手動で調整してください。
  • シークレット(DOCKER_PASSWORD・PERSONAL_TOKEN等)はGitHubの「Settings → Secrets and variables → Actions」で登録し、YAML内では${{ secrets.NAME }}で参照します。生成YAMLに直接書き込まないでください。
  • プライベートリポジトリのActionsは無料枠(Free planで月2,000分)に上限があります。長時間ジョブを回す際は使用量を監視してください。
  • matrix戦略は便利ですが、組み合わせ数が増えると消費分が乗算で増加します。Node 18・20、OS 3種なら6並列分です。
  • actions/checkout@v3 のようなバージョンタグは定期的に更新する必要があります。Dependabotで自動更新を有効化すると保守が楽になります。

用語の補足

  • matrix戦略:複数のバージョンやOSで並列にジョブを実行する仕組み。互換性検証で必須の機能です。
  • workflow_dispatch:GitHubのUIから手動でワークフローを起動できるトリガー。手動デプロイや棚卸しスクリプトに便利です。
  • concurrency:同じブランチでワークフローが多重起動するのを防ぐ設定。デプロイ系ワークフローでは必須に近い項目です。

よくある質問

リポジトリの.github/workflows/ディレクトリに保存してください。ファイル名は自由ですが、ci.ymldeploy.ymlのように用途が分かる名前が推奨です。pushしてGitHubで「Actions」タブを開くと、認識されたワークフローが一覧表示されます。
複数のバージョンやOS環境で並列にジョブを実行する仕組みです。例えばNode.js 18・20の両方でテストを走らせると、特定バージョンだけで再現する不具合を早期に発見できます。組み合わせ数に比例して消費時間も増えるので、必要最小限の構成にしておくと節約できます。
GitHubの「Settings → Secrets and variables → Actions」で登録し、YAML内では${{ secrets.MY_KEY }}のように参照します。YAMLに直接書くとリポジトリ閲覧者全員に見えてしまうため絶対に避けてください。Organization単位でも共有可能なので、複数リポジトリで使うキーはOrgレベルに置くと管理が楽です。
パブリックリポジトリは無制限、プライベートリポジトリはGitHub Free planで月2,000分(Linux換算)です。Windows/macOSランナーは消費レートが高い(Linuxの2倍・10倍)点に注意してください。Settings → Billingで使用量をリアルタイム確認できます。
標準的なcron式(5フィールド)を使います。例えば0 0 * * *は毎日UTC 0時、0 */6 * * *は6時間ごとです。GitHub Actionsはタイムゾーン指定がUTC固定なので、JSTに合わせるには9時間ずらして書く必要があります(JST 0時はUTC 15時)。
まずYAMLのインデント(半角スペース2)に誤りがないかを確認してください。次に.github/workflows/の場所が正しいか、ブランチ名が指定通りか、Actionsが「Disabled」になっていないかを順にチェックします。失敗時のログは「Actions」タブから各ジョブを開くと詳細を確認できます。
いいえ、すべての生成処理はブラウザ上で完結し、入力したワークフロー名や環境変数値が外部に送信されることはありません。プロジェクト名やシークレット名のヒントを含む値も安全に取り扱えます。