Critical problem statement
Currently, the plugins that are only transitive dependencies in essentials.yaml and ingest.json can be chosen on older versions.
This leads, for instance, to generating warning or error logs that have actually been fixed already, sometimes long ago.
This is very easy to fix, we just have to declare all transitive dependencies directly under the spec.plugins node in essentials.yaml, but I'm a bit reluctant to do that: we would lose a bit the main plugins we do depend on and want installed, and the ones we only put there to force a specific version (and that we do not really care about if it had to be removed, say).
Expected behavior
Evergreen installed plugins should (strive to be) always be latest.
So that we do not see error logs or behaviors in production that are already fixed in the given plugin.
- relates to
-
JENKINS-53767
Offer plugin management tooling
-
- Resolved
-
[JENKINS-53506] Update all installed plugins to latest version
IMO the transitive flag is something we should implement rather sooner than later, cause it seems like a simple enough way to fulfil our current use case to bump a transitive version of a given plugin, while still storing in the essentials.yaml that this one is not one we actually care about (but which we just want to bump the version of).
We wouldn't have/need that flag to be under the computed status node obviously, only useful in the manually edited part.
Possible to do such updates today (evergreen PR 312), but cumbersome—requires a lot of time in a text editor copying and pasting stuff into the spec section (being careful not to paste anything into status where it will be discarded), iteratively running the goal to propose updates, which produces a ton of noise since the current JavaScript tool does not grok some details of the version syntax actually used by both Maven and the Jenkins plugin manager.
I think my suggestion at the time was to require essentials.yaml to declare all plugins explicitly, but add a boolean transitive flag to each plugin entry and then fail the build if there are any plugins marked as transitive which do not have a hard (~ not optional) dependency chain from at least one nontransitive plugin in the list. Thus you can see at a glance which plugins are there because they offer some important feature, vs. being just along for the ride, and if you accidentally “orphan” some transitive dependency (for example because some routine plugin update finally picks up the holy grail of dropping the last hard dep on maven-plugin) then you will be alerted to the situation immediately and can delete the now-obsolete plugin (or decide you really wanted to keep it after all, and mark it nontransitive).