CI/CDツール
workflow YAMLを貼り付けると整形され、job/stepツリーを辿りながらmatrixやcronの下書きを作ってから本文に反映できます。
すべてブラウザ内だけで処理され、GitHubやサーバーには送信されません。
検証待ち…
workflow YAMLの不具合はpush後に初めて表面化することが多いものです——runs-onの書き忘れ、実在しないpermissions値、いつまでも発火しないschedule。このGitHub Actionsワークフロー検証ツールは、単なるYAML構文の正しさではなくCIが実際に依存する構造をローカルでチェックすることで、この種のミスを実行前に見つけます。
複数jobを持つ長いworkflowを編集していて壊れている箇所へすぐ飛びたいとき、OSやバージョンの組み合わせでbuild matrixを組むとき、複数stepにまたがるenv・secrets・vars参照を整理したいとき、on.scheduleのcron式を書いてGitHub Actions自体が何を許容するのか知りたいとき——そんな場面で役立ちます。
汎用YAMLリンター、matrix生成ツール、GitHub Actionsのことを何も知らないcronツールを行き来しなくて済みます。
workflowを貼り付けるとYAMLが整形され、job idとstep idの命名規則、各jobがruns-onかusesのどちらかを持つか、permissionsの実際の列挙値（id-tokenはwriteかnoneのみ）、branchesとbranches-ignoreの同時指定といった矛盾まで検証されます。その上でクリック可能なjob/stepツリーが生成され、選ぶとエディタが該当行へ直接ジャンプします。
参照一覧には見つかった${{ env.X }}、${{ secrets.X }}、${{ vars.X }}、${{ github.X }}の式がすべて、所属するjobとstepとともに並びます。公式ドキュメントに記載された3つの既知の詰まりどころ——envはstepのidやusesに使えない、secretsはif:条件に直接書けない、githubはuses:に使えない——も個別に警告されます。
cronパネルは標準的な5フィールド式を組み立てつつ、GitHubがschedule向けに公開している制限——最短5分間隔、デフォルトUTC、任意設定できるIANAタイムゾーン、@dailyのようなエイリアス非対応、公開リポジトリが60日活動なしで自動無効化されること——をそのまま適用します。
ツールバーの見た目より、裏側でずっと多くのことが自動で動いています。
エディタからコピーしたworkflow YAMLを貼り付けるか、内蔵サンプルを読み込みます。サンプルにはschedule、strategy.matrixを持つjob、env/secrets/github参照がすべて含まれているので、5つの機能を一度に確認できます。自動検証はデフォルトで有効で、入力が止まって350ms後に再解析されます——何もアップロードされません。
matrix変数テーブルやcronの各フィールドをいくら編集しても、それだけではworkflowは変わらずプレビューが更新されるだけです。「挿入」を押すまでstrategy.matrixやon.scheduleには何も書き込まれず、押す前でも下書き片段だけを単独でコピーできます。
env/secrets/vars/github参照一覧が示すのは汎用リンターの推測ではなく、GitHub Actionsが実際にエラーを返すと文書化された位置です。自動検証をオフにしている場合はCtrl/Cmd+Enterで再検証できます。検証後に編集を続けると、再検証が済むまでコピーとダウンロードは無効化されるので、古い結果を書き出してしまうことがありません。
5つの機能が別々のタブではなく、ひとつの画面の中で連動します。
2スペースか4スペースの一貫したインデントでworkflowを整形します。プルリクエストのdiffには実際に変更した行だけが表示され、ファイル全体が再整形されて埋もれることがありません。
job idとstep idは命名規則で検証され、各jobがruns-onかusesのどちらかを持つか確認され、permissionsの値は実際の列挙値と照合されます。同じトリガー内でbranchesとbranches-ignoreのような排他的なフィルターが両方指定されている場合も警告されます。
ツリーはworkflowの実際のjob・step構造をそのまま反映し、項目を選ぶとエディタが該当行までスクロールします。インデントを目で数えて探す必要がありません。
osやバージョンといった変数テーブルを組み立て、includeやexcludeの組み合わせを追加し、fail-fastとmax-parallelを設定して、生成されるstrategy.matrixをプレビューしてから選択したjobへ挿入します。
env・secrets・vars・githubを参照する${{ }}式をすべて抽出し、jobとstep単位で一覧表示します。範囲フィルターで1種類の参照だけに絞り込むこともできます。
よく使うプリセットまたはカスタム式から5フィールドのscheduleを組み立て、on.scheduleに挿入される内容をプレビューしてから反映します。GitHub自身のスケジュール制限は自動で適用されるので覚えておく必要がありません。
機能の長さより、境界を知っていることの方が大事です。
回答はすべてGitHubの公式文書に基づいており、推測では書いていません。
生成される内容は公開されている構文としては正しいものです——GitHub Actionsは2024年以降、scheduleに任意のIANAタイムゾーンを指定できるようになりました。ただしGitHub公式コミュニティのディスカッションには、実際には反映されなかったという報告が複数あります。このツールが保証できるのは片段の構文が正しいことだけで、GitHub側のスケジューラーが実際にそれを適用するかどうかまでは保証できません。
考えられる原因はいくつかあります。workflowファイルがデフォルトブランチにない、リポジトリが長期間活動なしでGitHubが60日後に自動的にscheduleを無効化した、あるいは式の間隔が文書化された最短5分より短い、などです。GitHubの文書には高負荷な時間帯、特に毎時ちょうど前後で遅延が起きうるとも書かれています。このツールは構文をチェックするだけで、正確な発火時刻までは保証できません。
workflowをこのGitHub Actionsワークフロー検証ツールに貼り付けると、GitHubの一般的なメッセージの代わりに、具体的なjob名やstep名、行と列の位置まで表示されます。入力が止まって350ms後に自動で再検証されるので、修正しながら位置が更新されていきます。
with:ブロックの中ではenvコンテキスト自体が使えないためです。これは公式文書に明記された3つの制限のひとつで（envはstepのidやusesにも使えません）、参照一覧はこの種の参照を直接警告として表示します。値はjob単位またはworkflow単位のenvに置くか、reusable workflowへ明示的にinputとして渡してください。
多くの場合、if:条件の中に直接書いていることが原因です。secretsはif:条件の中で直接読み取ることができません。まずsecretsをjob単位またはstep単位のenv変数に代入し、そのenvの値をif:条件で判定してください。これは参照一覧が各secrets.*参照に対して警告する3つの危険箇所のひとつです。
引用符なしの3.10はYAMLによって数値3.1として解釈され、末尾の0が黙って失われます。これはYAMLの解析仕様によるもので、GitHub Actions側の不具合ではありません。matrix生成ツールはバージョンらしき値を検出し、生成したstrategy.matrixを挿入する際に自動で引用符を付けます。
このツールが誤判定するworkflowを見つけましたか？
このGitHub Actionsワークフロー検証ツールにworkflowを貼り付けて、job/stepツリーと参照一覧がリアルタイムに更新される様子を確認し、必要になったらmatrixやcronの下書きを作ってみてください。
処理はすべてブラウザ内で完結します——何もアップロードされず、workflowが実行されることもありません。
解析はすべてブラウザ内でローカルに行われます。