Dependabot configuration

[callumforrester]

As a Github user I (desperately) want to reduce the signal to noise ratio in my Github notifications so I don't miss important things.

For projects using the copier template, I currently ignore dependabot notifications for Github actions and dependencies pinned by the template (e.g. pydata-sphinx-theme>). As maintainers we should publish template updates with well-tested versions of those.

However that doesn't stop the notifications from cluttering my inbox. Can we configure dependabot to ignore those particular dependencies?

It would be ideal if dependabot could actually open PRs with template updates, but that doesn't seem to be a high priority (dependabot/dependabot-core#4410). As an alternative we have played with renovate which does support copier, but we had a few issues with that too.

[DiamondJoseph]

For reference here is the [Renovate] configuration used in the services-template which groups some updates in the template and makes those updates ignored in the repositories created from the template.
https://github.com/epics-containers/services-template-helm/pull/23/files

[DiamondJoseph]

Copier also supports being able to disable groups of dependencies, to allow e.g. managing the github action versions entirely through the copier template. This does require that the template eagerly tests, accepts and releases new version of those actions, with the alternative being each repository manages them themselves, risking merge conflicts or regressing version of actions especially those pinned to just a tag and so hard to see if a change is forward or backwards when updating the copier template.

[DiamondJoseph]

I will fork the copier template and configure it in my userspace with renovate, setting GHA dependencies to automerge if the pipeline passes as an experiment

[coretl]

I will fork the copier template and configure it in my userspace with renovate, setting GHA dependencies to automerge if the pipeline passes as an experiment

The workflow for GHA that I've been trying to (manually) follow:

• If it's a GH published action (like actions/checkout) then specify only major version, if CI passes on major version bump then check it still produces artifacts, then merge
• If it's not a GH published action (like softprops/action-gh-release) then pin to SHA and manually review each upstream diff before merging

If we automerge then we don't do any manual checking, it's entirely possible that we don't need to, but wanted to mention what I'm doing at the moment

[DiamondJoseph]

* If it's a GH published action (like `actions/checkout`) then specify only major version, if CI passes on major version bump then check it still produces artifacts, then merge

* If it's not a GH published action (like `softprops/action-gh-release`) then pin to SHA and manually review each upstream diff before merging

If we automerge then we don't do any manual checking, it's entirely possible that we don't need to, but wanted to mention what I'm doing at the moment

Renovate will (if you extend the best-practices config) pin all Actions to SHA

[coretl]

Renovate will (if you extend the best-practices config) pin all Actions to SHA

Excellent, but if we are being paranoid enough to pin to SHA, we should at least give a cursory check of the diff before merging the PR...

[DiamondJoseph]

We're also experiencing issues where having a requirements.txt file and dependencies defined in the pyproject.toml (when using Renovate and those dependencies are pinned, as per the best-practices above). We believe this will be fixed by uv, as the pep621 docs for Renovate says it supports uv including uv.lock.