Dependabot PRs cleanup and version pins

In theory dependabot automatic PRs whenever a dependency gets a new release, and specially when it is a security one, are nice and handy :sparkles:

The problem :scream: is that if a package has plenty of version pins (hi :wave:t4: JavaScript lock files, but also python requirements.txt :sweat_smile: ) and the repository is maybe an add-on happily idling in the collective organization... it will happily keep collecting open PRs that nobody pays attentions to it.

I did not finish removing all the PRs that it created, there are ~50 or so left for anyway wishing to do a few clicks, I already removed +250 of them only on the collective organization.

Not to bring stop energy to start using more requirements.txt to pin dependencies, which I'm a huge fan of, but specially for add-ons, I would rather suggest to try to keep version pins at a minimal, or share it across multiple repositories (there is this plone testing repository to get configurations right? can't remember the name :confused: ).

Maybe there is a way to tell dependabot to stop bothering to create PRs for small version bumps :thinking:

Ideas on how to improve the situation, so that in half a year someone (me?) has to close again +200 PRs? :smile:

1 Like

Thanks for the work, that sound like a boring task.

That said, requirements.txt must not contain version pins at all, that is what constraints.txt is made for. Best practice is to have a first line -c constraints.txt in your requirements.txt.

FTR: The difference is, all in requirements.txt is installed as a package, while constraints.txt should contain all the dependencies to be pinned to a specific version (like what pip freeze dumps).

1 Like

Oh, that's a nice escape hatch you just found :tada:

Seems that GitHub's dependabot does not know about constraints.txt so it only checks requirements.txt.

Of course, at some point it will learn about it :person_shrugging:t4: :person_facepalming:t4:

I haven't looked at it, but dependabot can be configured on a per repository and/or organization basis, so if we eventually get again on the same situation we might look at that.

P.D. fortunately GitHub has a way to mass close PRs on the PR list view, so it was not that bad :sweat_smile:

1 Like