⚙️ GitHub Actions ジェネレーター
ワークフロー種別とトリガーをフォームで選ぶだけで、.github/workflows/xxx.yml にそのまま貼り付けられる YAML を即生成。Node.js / Python / PHP / Go / Docker / Pages / Vercel / Netlify / Release / Cron / Lint に対応。
🔒 プライバシーについて
- ・YAML 生成はすべてブラウザ内で完結します
- ・入力したブランチ名・バージョン等はサーバーに一切送信されません
- ・保存ログ・データベース等は存在しません
- ・登録・ログイン・課金は一切不要です
（左上の「YAML を生成」を押してください）
📖 つまずきやすいポイント
ワークフロー種別 (Node / Python / PHP / Go / Docker / Pages / Vercel / Netlify / Release / Cron / Lint) とトリガーを選ぶと、.github/workflows/ にそのまま置ける YAML を生成します。処理はブラウザ内で完結し、ブランチ名やバージョンは送信されません。生成されるのは構文的に正しいワークフローであって、あなたのプロジェクトで通るワークフローではありません — 依存のインストールもテストの実行も、実際のコマンドはリポジトリごとに違います。そして CI で本当に痛い目を見るのは、YAML の書式ではなく「権限」と「時間」です。以下はその話です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| fork からの PR には secrets が渡らない | pull_request でトリガーされたワークフローは、fork からの PR の場合、GITHUB_TOKEN が読み取り専用になり、リポジトリの secrets も渡されません。これは意図された安全策です — そうでなければ、誰でも PR を送るだけであなたの秘密を印刷させられます。しかし結果として、デプロイやカバレッジ送信を含むワークフローは、fork の PR で必ず失敗します。ここで危険な回避策が知られています: pull_request_target に切り替えると secrets が渡るのですが、このトリガーはベースブランチの権限で動くため、そこで PR のコードを actions/checkout して実行すると、外部の人間が書いたコードがあなたの secrets を持って動きます — 実質的にリポジトリの乗っ取りです。 |
ワークフローを 2 つに分けてください。 テストと lint は pull_request で (secrets 不要)、デプロイは push の main ブランチか release で実行します。これで fork の PR も普通に CI を通り、secrets が外に出る経路も存在しません。pull_request_target を使うなら、PR のコードを絶対に checkout しないでください — ラベル付けやコメント投稿のような、コードを実行しない用途に限定します。あわせて、すべてのワークフローの先頭に permissions: を明示してください — permissions: {contents: read} と書くだけで、そのワークフローの GITHUB_TOKEN から書き込み権限が消えます。必要な権限だけをジョブ単位で足していくのが正しい順序です。 |
| サードパーティの action をタグで参照する | uses: some/action@v1 の v1 はブランチやタグ、つまり動かせる参照です — action の作者 (またはそのアカウントを奪った人) が中身を差し替えれば、あなたの CI は次の実行で別のコードを動かします。そのコードは GITHUB_TOKEN と、そのジョブに渡した secrets にアクセスできます。これは理論上の話ではなく、人気のある action が侵害されて秘密を収集する事例は実際に起きています。公式 (actions/*) はまだしも、star の少ない便利 action を無造作に @main で参照するのは、他人にあなたのリポジトリへの書き込み権限を渡しているのと変わりません。 |
サードパーティの action は commit SHA で固定してください — uses: some/action@a1b2c3d4... の形です。SHA は書き換えられないので、次に何が動くかが確定します。更新は Dependabot に任せます (.github/dependabot.yml に package-ecosystem: "github-actions" を追加すると、SHA 更新の PR を自動で作ってくれます) — 固定と更新は両立します。そもそも action を減らすのも有効です: ファイルを 1 つコピーするだけの action なら、run: に cp と書けば依存が 1 つ消えます。そして secrets はジョブ単位で最小限に渡してください — ワークフロー全体に環境変数として置くと、その中のすべての action から読めます。 |
| cron は時刻どおりに動かず、60 日で止まる | schedule トリガーには、書式以外に 3 つの落とし穴があります。時刻は必ず UTCで、あなたのタイムゾーンではありません — 0 3 * * * は「UTC の午前 3 時」です。実行はオンタイムではありません — 混雑時には数分から数十分遅れ、負荷が高いときは実行そのものが飛ぶことがあります。毎時 0 分は最も混むので、ちょうどの時刻を避けるだけで安定します。そして最も驚かれるのが 3 つめです: 60 日間コミットのないリポジトリでは、スケジュールされたワークフローが自動的に無効化されます — メールは届きますが、見落とすと「気付いたら数か月動いていなかった」ということが普通に起きます。 |
cron 式は UTC で書き、狙う時刻から数分ずらしてください — 0 3 * * * ではなく 17 3 * * * のように。そして必ず workflow_dispatch を併記してください — 手動で実行できるだけで、動作確認も再実行もできるようになります (スケジュールが来るまで待たないと試せない状態は、それ自体が事故のもとです)。無効化への対策は「気付ける」ようにすることです: ジョブの最後に成功を外部へ通知させ、通知が途絶えたことに気付ける仕組みを作ってください — 失敗の通知だけでは、実行されなくなったことを検出できません。正確な時刻や高い信頼性が要るなら、GitHub Actions の cron ではなく専用のスケジューラを使ってください。 |
キャッシュはロックファイルと一緒に鍵を作ってください。actions/setup-node の cache: npm や actions/cache の key にロックファイルのハッシュを含めないと、依存を更新しても古いキャッシュが使われ続けます — ローカルでは直っているのに CI だけ古い依存で失敗するという、原因の分かりにくい状態になります。hashFiles('**/package-lock.json') を鍵に入れてください。そしてキャッシュはブランチをまたいで共有されます — 壊れたキャッシュが他のブランチに伝染するので、疑わしいときは名前を変えて作り直すのが早いです。もうひとつ、ログに秘密を出さないよう気を付けてください: GitHub は登録済みの secrets を自動でマスクしますが、加工した値 (Base64 化した、JSON に埋めた、一部だけ切り出した) はマスクされません。set -x やデバッグ出力を有効にすると、コマンドラインごと記録されます — そして Actions のログは、パブリックリポジトリなら誰でも読めます。
📖 使い方
-
1
ワークフロータイプを選ぶNode.js / Python / PHP / Go / Docker / Pages / Vercel / Netlify / Release / Cron / Lint から選択。
-
2
トリガーとブランチを指定push / pull_request / schedule / workflow_dispatch を有効化。対象ブランチや cron 式も入力。
-
3
YAML を生成してコミット「YAML を生成」を押し、コピーまたはダウンロード。.github/workflows/ にファイルを置いて push すれば動作します。
❓ よくある質問
生成されるシークレットはどう設定しますか？
どの actions のバージョンが入りますか？
Self-hosted runner にも使えますか？
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。