jtnord
commented
5 days ago 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.
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-pomandgit-changelist-maven-extensionare 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?