Status: Closed (View Workflow)
Resolution: Won't Do
Evergreen - Milestone 1, Evergreen - Milestone 2
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).
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
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.
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).