CI設定を直してもre-runでは効かないことがある — pull_requestイベントが再実行で使うref
GitHub Actionsのpull_requestイベントをre-runしても、直したはずのワークフロー定義が読まれないことがある。公式ドキュメントの記述と、実際に「直したのに赤いまま」を誤診しかけた実例から、re-runとブランチ更新の違いを整理する。
re-runが直さないもの
GitHub Actionsのre-run(再実行)は、ワークフローを起動した時点のコミットとrefをそのまま使い直す操作であり、CI設定を直したPRのマージ後にそれを実行しても、直った定義では動かないことがある。
GitHub公式ドキュメントはre-runの挙動をこう説明する。「ワークフローは、実行を起動した元のイベントと同じGITHUB_SHA(コミットSHA)とGITHUB_REF(gitのref)を使う」。CI設定ファイル自体を書き換えるPRをmainにマージしても、別の既存PRが持っているrefは書き換わらない。そのPRに対してre-runを押しても、参照されるのは元のイベント発生時点のrefであり、そこにひも付くワークフロー定義も古いままである。
pull_requestイベントが指すref
pull_requestイベントではGITHUB_REFが refs/pull/PULL_REQUEST_NUMBER/merge に設定される。これはPRのブランチと base ブランチを仮想的にマージした結果を指すrefで、base側の内容が変わるたびに新しく作られる。CI設定の修正をmainにマージしただけでは、まだ動いていないPRのmergerefは古いbaseを含んだまま更新されない。新しいmergerefが作られるのは、そのPRに対して新しいイベント(pushや、ブランチの更新)が発生したときである。
「直したのに赤いまま」を誤診しかけた実例
本システムでは、CI設定側の不具合を直すPRをmainにマージした直後、赤くなっていた別の既存PRに対してre-runを実行し、それでも赤いままだったことがあった。ここで「修正が効いていない」と誤診しかけたが、実行結果に出ているベースのコミットSHAを確認したところ、修正前の古いコミットのままだった。そのPRのブランチを更新する操作(base側の変更を取り込んでmergerefを作り直す操作)を行ってから改めて実行したところ、新しいベースのコミットSHAとともに、修正済みの検査が正しく通った。
「re-runしても赤いまま」という結果だけを見て、修正そのものを疑う前に、どちらの操作を行ったかを確認する必要がある。 re-runは同じrefの再実行であり、ブランチの更新は新しいrefでの新規実行である。この2つはUI上どちらも「もう一度動かす」という見た目の操作だが、参照するワークフロー定義が違う。
| 操作 | 参照するref | ワークフロー定義 |
|---|---|---|
| re-run | 元のイベントと同じref(変わらない) | 元のイベント発生時点のまま |
| ブランチの更新・新しいpush | 新しく作られるref | 現在のbase・現在のブランチの内容 |
この設計から引ける手順
- CI設定を直すPRをマージしたら、その修正を効かせたい既存PRは「ブランチの更新」で新しいrefを作る。re-runでは足りない
- re-runしても赤いままの結果を見たら、実行ログに出るベースのコミットSHAを確認する。修正前のSHAのままなら、それは「修正が効いていない」のではなく「古い定義のまま動いた」だけである
- 逆に、CI設定を直さないただのコード修正であれば、通常のpushで新しいイベントが発生し新しいrefが使われるため、この問題は起きない。問題が起きるのは「実行済みのイベントを、内容を変えずに再実行する」re-run特有の場合に限られる
FAQ
Q. なぜre-runは古い定義のまま動くよう設計されているのですか。 re-runの目的は「同じ入力に対してもう一度実行し、同じ結果が再現するか(あるいは一時的な失敗だったか)を確かめる」ことにあります。実行のたびに定義が変わってしまうと、再現性の確認という目的自体が成立しません。
Q. すべてのイベントタイプで同じ挙動になりますか。 この記事で確認したのはpull_requestイベントの挙動です。イベントの種類によってGITHUB_REFの設定は異なるため、他のイベントで同じ確認が必要な場合は、そのイベント固有の仕様を別途確認してください。
Q. mainへの直接pushをトリガーにするワークフローでも同じ問題が起きますか。 pushイベントは対象のブランチ自体のrefを直接参照するため、CI設定を含むコミットをそのブランチにpushすれば、以降の実行は新しい定義を使います。今回の問題は「base側だけが変わり、PR側のブランチ自体は変わっていない」pull_requestイベント特有の事情です。
Q. re-runの前にログのSHAを確認する以外に、確実な見分け方はありますか。 ワークフローの実行一覧で、対象の実行が「どのコミットに対して」動いたかを見れば区別できます。CI設定を直したコミットより前のSHAで動いていれば、まだ新しい定義は読まれていません。
CI・CDパイプラインの設計や、AIルーティンが継続的にコードを提出し続ける開発基盤の構築を検討している場合は、[ご相談ください](/contact)。
出典
- Re-run workflows and jobs — GitHub Docs(参照 2026-08-14)
- Events that trigger workflows — GitHub Docs(参照 2026-08-14)