🐛

「えっ、‎workflow_call じゃないの？」GitHub Reuse Workflows の ‎event_name の話す

2026/05/20に公開

こんにちは、天海です。

 今日になって初めて、GitHub Reusable Workflows の event_name が workflow_call ではないことを知りました直感的には「Reusable Workflow なんだから workflow_call で動くでしょ」と思いがちですが、実際には 親ワークフローの event_name をそのまま引き継ぐ 仕様です。
親ワークフローが push で起動 → Reusable Workflow 側の github.event_name も push
親ワークフローが workflow_dispatch で起動 → Reusable Workflow 側の github.event_name も workflow_dispatch
今回の内容は、チームの知識共有と技術の蓄積に役立てるため、調査プロセスも含めて記録しておくことにしました。将来的には、この手順を 1 つの「GitHub Actions Issues 調査用ワークフロー」として整理し、エンジニア成長や同様の問題調査にそのまま使える形にしていきたいと考えています。

 事象：deploy-sand/* が実行されない（job was skipped）deploy-sand/* 系の Workflow が期待通り動いていない、という報告がありました。GitHub Actions の画面上では、該当ジョブが job was skipped としてスキップ扱いになっています。
つまり、どこかの条件で ジョブがスキップされる判定になっている 状態です。

 1. 原因調査：Reusable Workflow 側の if 条件まずは Workflow の定義を確認しました。

deploy-sand-frontend ジョブは deploy-p-app に needs している

deploy-p-app 自体は正常終了している
依存元に問題はなさそうなので、次に Reusable Workflow である deploy_sand_p_frontend.yml を確認しました。そこには次のような条件が書かれていました。
jobs:
  deploy-p-frontend:
    if: github.event_name == 'workflow_dispatch' || (github.event_name == 'workflow_call' && vars.STOP_AUTO_DEPLOY_SAND_REASON == '-')
意図としては、
手動実行（workflow_dispatch）なら常に実行
Reuse 呼び出し（workflow_call）の場合は、vars.STOP_AUTO_DEPLOY_SAND_REASON == '-' のときだけ実行
というものです。
ところが、ここに問題がありました。vars.STOP_AUTO_DEPLOY_SAND_REASON 自体が設定されていなかった点です。

 2. 一度は vars を設定しても、問題は解決しなかったリポジトリ変数として STOP_AUTO_DEPLOY_SAND_REASON = '-' を追加し、Workflow を再実行しました。
しかし、それでもジョブはスキップされたまま。

 3. Action debug logs を確認するここで「単なる変数の有無ではなさそうだな」と判断し、ログを詳しく追うことにしました。
Action のデバッグログを有効にして github.event_name を確認したところ、想定していた workflow_call ではなく、親ワークフロー側のイベント名（例：push） が入っていることがわかりました。
つまり、先ほどの条件は実際にはこう評価されています。
親 Workflow が push で起動 → github.event_name は push

if 条件には workflow_dispatch と workflow_call しか書いていない
結果として常に false → job skipped
本来は「親 Workflow から自動実行されたときにだけ条件付きで動かす」つもりだったのに、event_name の勘違いで 常にスキップ される状態になっていた、というわけです。

 4. 応急処置としての修正案github.event_name が実際には push であると分かった時点で、まずは次のような修正を試しました。
- if: github.event_name == 'workflow_dispatch' || (github.event_name == 'workflow_call' && vars.STOP_AUTO_DEPLOY_SAND_REASON == '-')
+ if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && vars.STOP_AUTO_DEPLOY_SAND_REASON == '-')
これで少なくとも「push のときに条件付きで実行する」という要件は満たせます。
ただ、調査を進める中で、「そもそもこの条件自体、本当に Reusable Workflow 側に必要か？」という疑問が出てきました。

 5. 単に修正ではなく、正しいコードを目指すWorkflow 全体の設計を見直してみると、構造は次のようになっていました。

deploy-sand-frontend は必ず deploy-sand からのみ呼び出される

deploy-sand 側ですでに「実行するかどうか」の判定ロジックを持っている
つまり、実行可否の判断は親 Workflow 側だけで完結させられる設計 になっています。

であれば、子側（Reusable Workflow 側）でさらに if 条件を重ねる必要はありません。
最終的には、deploy-sand-frontend 内の if 条件自体を削除する、という形に落ち着きました。責務を親に集約し、子は「呼ばれたら実行する」だけにすると、挙動も読みやすくなります。

 結果

deploy-sand/* のジョブは期待通り実行されるようになった
実行可否の判断は deploy-sand に一本化
Reusable Workflow 側は「どうデプロイするか」に専念できる形に整理

 最後に最初は「こういうのは AI に聞けばすぐ解決する」と思っていました。実際、チームでも日常的に Claude を使っています。それでも今回は解決できず、最終的には自分で深掘りする必要がありました。
AI に丸投げでは解決しなかったの、自分なりに考えた理由は次の 3 つです。
人間側が問題を正しく言語化できていない
AI Coding Agent はコーディングは得意だが、DevOps 的な調査・切り分けがまだ苦手
GitHub が AI 向けの調査手段を十分に提供しておらず、AI を活かしきれない
だからこそ、今回のような調査プロセスを「GitHub Actions Issues 調査フロー」として整理・共有しておく価値があると感じました。

 参考リンクGitHub Docs: Reusing workflows