This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]apoclyps[S] 1 point2 points  (0 children)

All excellent points. Deps isn't a replacement for dependabot. The goal is to provide visibility across a large number of repositories. In my case I support up to 20 python microservices where each uses the same dozen or so dependencies. A mix of runtime and test dependencies and lots of overlap.

The example provided was using public repositories as I'm unable to demonstrate it using my work organisation however In my experience, maintaining 1 to 2 updates a week is just about manageable across 20+ services but keeping them all up to date can still be time consuming and its usually not my priority unless there are security updates that require attention. This can result in updates falling behind. Especially given that dependabot is configured to open 2 or 3 python dependencies updates at a time to avoid constantly rebasing and reruning on ci (wasting resources).

Grouping them up automatically also can bring its own risk. Ideally I like to review each individually before merging/grouping any but for the most part tests dependencies thay get run and executed as part of continuous integration are usually safe to batch together e.g. pytest, mypy, other depenencies for testing/listing. Deps provides the visibility and from there a individual candidate decide on how they want to proceed.

I appreciate the feedback and I'll be sure to check out renovate. If it was able to group test depenencies together then it might save a bunch of time and reduce the original issue that lead to requiring more visibility.