はじめに

本記事は2024/11/09時点の情報です。また、DependabotとGitHub Actions自体の説明は割愛します。詳細、および、最新情報は公式ドキュメントを確認してください。
本記事に記載された内容やコードによって生じたいかなる損害についても責任を負いません。使用する際は自己責任でお願いします。

更新情報

2025/05/02

下記issuesでtool.poetryセクションがないと、Dependabotでエラーになる現象は解決されたようです。

一方で更新されるのは、tool.poetry.group.dev.dependenciesセクションのみで、projectセクションのdependenciesキーは更新されませんでした。

tool.poetryセクションは更新されたが、project.optional-dependenciesは更新されなかった。今後対応されるのだろうか。現時点で両方保守する場合は個別に同期する処理を実行しないとだめそうだ。 https://t.co/yrqs6s9JFV pic.twitter.com/jnftX8TMDy
— 7z(7rikaz) (@tw_7rikazhexde) 2025年4月28日

projectキーの対応は下記issueで対応中のようです。

github.com

Partial support for Poetry 2 was added in dependabot/dependabot-core#11642, but the project section is not yet supported.

uvの方は、dependabot対応が進展したようですね。 issuesはcloseされています。
package ecosystemはpipではなく、uvで指定するようです。まだエラーも報告されているようですが、こちらも並行して動作確認はしたいところです。

2025/03/01

その後、運用していた結果、以下の問題が発生し、ワークフローを見直すことにしました。

2025/02/16以前の情報は古く適切ではありませんが、備忘録として残します。参照する場合はご注意ください。

以下のワークフローではGistへの投稿が発生しますので、使用する場合は、PATの設定とgistIDを取得してください。

問題

リポジトリでrequirement(-dev).txtとpyproject.toml(poetry.lock)が存在する場合、dependabotはrequirement(-dev).txtのみ更新する
一方で、poetry exportコマンドでは、poetry.lockファイルをベースにrequirement(-dev).txtを生成するため、そのrequirement(-dev).txtをコミットした場合、dependabotで生成されたrequirement(-dev).txtと差異が発生する。
その結果、dependabotのバージョン更新の無限ループが起きる。

解決方法

リポジトリではrequirement(-dev).txtをコミットせず、pyproject.toml,poetry.lockファイルのみコミットする。
requirement(-dev).txtは、後述するupdate-requirements-after-dependabot.ymlで最新のpyproject.tomlベースでpoetry.lockファイルを生成し、その後、poetry exportコマンドを実行して生成する。
生成したrequirement(-dev).txtはGistにコミットする。

将来的にDependabotがpoetryのver2.0.0以降に対応されれば、PEP621の仕様により、pyproject.toml指定でpip installできるようになるため、requirement(-dev).txtは必ずしも生成する必要はなくなります。

一方で、pyproject.tomlとrequirement.txtはおそらく今後も共存されることはないと思うので、両方のファイルを保守管理したい場合は、Gistや別のリポジトリにrequirement.txtを保存する方法を取るしか手段はないと考えます。

2025/02/16

Poetryのver2.0.0でPEP621対応がサポートされ、pyproject.tomlは[project]セクションでプロジェクト情報を管理するようになりましたが、dependabot側はまだ未対応のようです。（下記issue参照）

python-poetry.org

github.com

PEP621形式でpyproject.tomlを作成する場合（poetry newコマンドでも[project]セクションの形式でpyproject.tomlが作成されます。）、 Dependabotでは[tool.poetry]セクションが必要になりバージョン更新のプルリクエストが正常動作しません。

[project]セクションのみ記載するとDependabotは以下のエラーになります。

Dependabot can't parse your pyproject.toml

一方で、 [project]セクションと[tool.poetry]セクションを両方記載した場合、poetry checkコマンドを使用すると、エラーにはなりませんが、以下警告が表示されます。

Warning: [project.name] and [tool.poetry.name] are both set. The latter will be ignored.
Warning: [project.version] and [tool.poetry.version] are both set. The latter will be ignored.
If you want to set the version dynamically via `poetry build --local-version` or you are using a plugin, which sets the version dynamically, you should define the version in [tool.poetry] and add 'version' to [project.dynamic].
Warning: [project.description] and [tool.poetry.description] are both set. The latter will be ignored.
Warning: [project.authors] and [tool.poetry.authors] are both set. The latter will be ignored.

また、debendabotでは、 [project]セクションと[tool.poetry]セクションでバージョン不一致が起き、poetry installを実行するとエラーになります。(rm poetry.lock）を削除しても正常動作しません。

2/16時点では、dependabot側がpoetry ver2.0.0の変更に対応するまでは、
これまで通り、[tool.poetry]セクションのみを有効にしておくのが良さそうです。
そのため、下記のワークフローについても、[tool.poetry]セクション形式でpyproject.tomlで作成しないと動作しないので注意してください。

poetry checkを実行すると以下の警告が表示されますが、issueがcloseされるまでは無視するしかないと思います。上記issue以外にも関連issueは報告されているので早期対応が待たれます。

Warning: [tool.poetry.name] is deprecated. Use [project.name] instead.
Warning: [tool.poetry.version] is set but 'version' is not in [project.dynamic]. If it is static use [project.version]. If it is dynamic, add 'version' to [project.dynamic].
If you want to set the version dynamically via `poetry build --local-version` or you are using a plugin, which sets the version dynamically, you should define the version in [tool.poetry] and add 'version' to [project.dynamic].
Warning: [tool.poetry.description] is deprecated. Use [project.description] instead.
Warning: [tool.poetry.authors] is deprecated. Use [project.authors] instead.

個人的にはuvに移行したいところですが、dependabotが未対応なので完全以降するまで至っていないのが現状です。Poetryもよいのですが、最近のuvの状況は軽視できず。

dependabot/dependabot-core#10478のコメントを見ると25年の2月から作業着手する予定のようですね。poetryの上記issueの件もあるので進捗が遅れないといいですが。

docs.astral.sh

2025/01/30

プルリクエストを確認すると、Dependabot は、pyproject.toml、poetry.lock、および requirements.txt ファイルの更新に対応しているようです。Dependabotを有効化しているプロジェクト全てを確認できているわけではありませんが。基本的にPEP621に対応している場合は更新管理できるようです。そのため、本ワークフローを使用なくても更新管理できますが、参考記事として投稿は残しておくことにします。

docs.github.com

経緯

Poetryで管理するプロジェクトのパッケージ情報をpyproject.toml,requirements.txtで管理しているが、パッケージ情報の更新を自動化したかった。
パッケージ情報の更新はDependabotを使用することで対応可能だが、pyproject.toml,requirements.txtを同時に管理する設定は存在しなかった。¹

実現方法

pyproject.tomlはdependabotで管理、更新する。
requirements.txtはgithub actionsのワークフローでpoetry exportコマンドを使用して生成する。
ワークフローの実行条件はdependabotで作成されたプルリクエストがマージされた時とする。

シーケンス図

この方法であれば、dependabotによるプルリクエスト作成を起点にパッケージ情報（pyproject.toml(コミットしていればpoetry.lockも対象),requirements(-dev).txt）をセットで更新可能になります。

以下、処理に必要になる情報の詳細です。

dependabotの設定(dependabot.yml)

公式ドキュメント(package-ecosystem)に従いdependabot.ymlを作成します。

ワークフローについて(update-requirements-after-dependabot.yml)

rulesetによる制限を考慮する場合について

リポジトリのrulesetでRequire status checks to pass(例：pytest)を設定している場合、上記ワークフローではrequirements(-dev).txtのコミットしかしていないため、エラーになります。

具体的には以下のようなエラー例になります。

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: - 8 of 8 required status checks are expected.
remote: - Changes must be made through a pull request.

ワークフローのあるべき動作としては、update-requirements-after-dependabot.yml内で、Require status checks to passの条件（例：pytest）を追加して、それがパスすることです。

しかし、それはupdate-requirements-after-dependabot.ymlで行うべきではなく、dependabotのプルリクエスト時にチェックすべきです。上記ワークフローではdependabotによるマージを前提としていることもあり、そこでパスすれば、update-requirements-after-dependabot.ymlのワークフローで、再度Require status checks to passの条件がパスすることをチェックする必要はないと言えます。

このような場合、rulesetのBypass Listにリポジトリ管理者（Repository Admin）権限を対象に追加して、リポジトリ管理者（Repository Admin）権限を持つPATをワークフローに設定することで、Require status checks to passをバイパスして実行する対応が可能です。²

ワークフローでは、上記例の、secrets.GITHUB_TOKENをPATの変数名に差し替えてください。合わせて、permissionsキーは不要になるため、ワークフローで権限変更しない場合は削除可能です。

まとめ

Poetryで管理するパッケージ情報（pyproject.toml,requirements.txt）をDependabotとGitHub Actionsを使用して更新管理する方法について紹介しました。
現状のDependabotのプルリクエスト承認は手動ですが、マージ権限を考慮すれば、一連の処理を自動化できると思います。
将来的にdependabotがpyproject.toml,requirements.txtをまとめて管理できるようになるかもしれませんが、その場合はワークフローを無効にすれば良いので、サポートに伴う影響はないのではないかと思います。

2024/11/09時点では、公式ドキュメント(package-ecosystem)より、pip,poetryともに、package-ecosystemはpipであり、pyproject.tomlを検出対象とする指定はない。→　すみません。これは誤りです。requirement.txtがリポジトリに存在しない場合は管理対象になります。↩
GITHUB_TOKENはGitHub Actionsの実行コンテキストとして動作するため、バイパス権限を持っていません。将来的にGitHub Actionsにもバイパス権限を付与できるようになれば、PATを使用せずに secrets.GITHUB_TOKEN で実現できる可能性がありますが、現時点ではその機能は提供されていません。↩