Workflow to automerge Dependabot PRs

[jglick]

Manually merging things like https://github.com/jenkinsci/workflow-api-plugin/pull/359 is very tedious if you are responsible for a lot of plugin repositories. Something like https://github.com/jenkinsci/build-token-root-plugin/commit/0c8842af91294efe9212f45dcbad0b888e557cf8 is a lot more convenient. Does it make sense to make a reusable workflow out of this?

Ideally it would be more selective about which dependencies to merge automatically and which to leave to human review. plugin-pom and git-changelist-maven-extension are almost always safe. bom-* like in https://github.com/jenkinsci/build-token-root-plugin/pull/171 is potentially unwanted, since it can gratuitously pull in newer deps on other plugins that can make certain backporting tasks harder. Dependencies on non-BOM plugins would probably not be wanted for automerge for the same reason. Maven plugins are typically fine to automerge. Third-party library JARs could go either way. Is there some include/exclude pattern which would be sufficiently universal and uncontroversial?

[jtnord]

bom-* like in https://github.com/jenkinsci/build-token-root-plugin/pull/171 is potentially unwanted, since it can gratuitously pull in newer deps on other plugins that can make certain backporting tasks harder.

Additionally these are mostly noise and I would say iff the CI check passes they should be automatically closed. A user can update the version manually if they need to pickup some newer dependencies for some API, and the failing builds which are the "🚩something is probably broken here" would then be left for a maintainer to address some source (or binary) incompatibilities.

[timja]

I just use this in my plugins: https://github.com/jenkinsci/slack-plugin/blob/master/.github/renovate.json

[jglick]

https://github.com/openrewrite/rewrite-jenkins/issues/20#issuecomment-1705427671 yes that is an alternative, though enabling automerge from DB is straightforward enough and probably more familiar to most developers.

On a tangential note, I am not sure what to do about the dozens of PRs like https://github.com/jenkinsci/workflow-api-plugin/pull/361 as https://github.com/jenkinsci/plugin-pom/pull/1004 is not yet appropriate for most plugins. We could recommend that the DB config for plugins ignore major version bumps for plugin-pom generally. (Automerge just ignores such PRs since they do not pass checks, unless your baseline is in fact new enough.)

[timja]

I don't think there's a great way to solve it for dependabot apart from updating every repository to ignore v5 or just waiting a bit (few weeks?) and updating baselines (open-rewrite?)

For renovate, setting up an shared preset could be done and plugins changed to use that so in future we could have less effort for something like this happening: https://docs.renovatebot.com/config-presets/

[jglick]

(One-off example FTR: https://github.com/jenkinsci/archetypes/pull/763)