白油知 相談する

CI設定を直してもre-runでは効かないことがある — pull_requestイベントが再実行で使うref

GitHub Actionsのpull_requestイベントをre-runしても、直したはずのワークフロー定義が読まれないことがある。公式ドキュメントの記述と、実際に「直したのに赤いまま」を誤診しかけた実例から、re-runとブランチ更新の違いを整理する。

目次
  1. re-runが直さないもの
  2. pull_requestイベントが指すref
  3. 「直したのに赤いまま」を誤診しかけた実例
  4. この設計から引ける手順
  5. FAQ

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_REFrefs/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・現在のブランチの内容

この設計から引ける手順

  1. CI設定を直すPRをマージしたら、その修正を効かせたい既存PRは「ブランチの更新」で新しいrefを作る。re-runでは足りない
  2. re-runしても赤いままの結果を見たら、実行ログに出るベースのコミットSHAを確認する。修正前のSHAのままなら、それは「修正が効いていない」のではなく「古い定義のまま動いた」だけである
  3. 逆に、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)。

出典

  1. Re-run workflows and jobs — GitHub Docs(参照 2026-08-14)
  2. Events that trigger workflows — GitHub Docs(参照 2026-08-14)