下林明正のブログ

個人的かつ雑多なブログです。

Dependabotが起動するGitHub Actions Workflowを単にre-runしても権限が変わらなくなっていた

shogo82148.github.io

によると過去の公式ドキュメントでは

You can also manually re-run a failed Dependabot workflow, and it will run with a read-write token and access to secrets. Before manually re-running a failed workflow, you should always check the dependency being updated to ensure that the change doesn’t introduce any malicious or unintended behavior.

公式日本語訳:

失敗したDependabotワークフローを手動で再実行することもできます。これは、読み書きできるトークンを持ち、シークレットにアクセスできる状態で実行されます。 失敗したワークフローを手動で再実行する前には、更新される依存関係を常にチェックし、その変更によって悪意ある、あるいは意図しない動作が入り込むことがないようにすべきです。

と書いてあったようだけど、先ほど Automating Dependabot with GitHub Actions - GitHub Docs を確認したところ、

When you manually re-run a Dependabot workflow, it will run with the same privileges as before even if the user who initiated the rerun has different privileges. For more information, see "Re-running workflows and jobs."

となっていて、どうやらre-runしただけでは権限が変わらなくなっていたようだった。

Re-running workflows and jobs - GitHub Docsを読んでも権限の変え方はパッと見つからなかった。


じゃあどうすんの?というところで、当該のPRに空コミットをpushすると変わるんじゃ無いか?という噂をもらったので試してみたところ、確かにGITHUB_TOKENは色々とwriteになり、Secret sourceもDependabotではなくActionsになった。どういう理屈なのかは全然分かってない。

このあたり何が使われているかは、jobの実行ログみたいなところのSet up jobステップを開くとズラズラと書いてあるのでそこから確認できる。 Automatic token authentication - GitHub Docs

ちなみに空コミットはgit commit --allow-emptyでできます。


まあそもそもre-runで突破すること自体が応急処置的だと思うので、本当は根本対処した方が良いんだろうとは思う。 軽く検索しただけでも根本対処の選択肢はいくつか出てくるように見えた。