search

jenkinsci / plugin-compat-tester

Jenkins Plugin Compatibility Tester
MIT License
46 stars 55 forks source link

Update `io.jenkins:configuration-as-code` in lockstep with `io.jenkins.configuration-as-code:test-harness` #703

Open basil opened 2 months ago

basil commented 2 months ago

@mawinter69 reported https://github.com/jenkinsci/configuration-as-code-plugin/pull/2551#issuecomment-2313496131.

basil commented 2 months ago

As of #702 it should be possible to effect the test harness bump by inserting io.jenkins.configuration-as-code:test-harness:<version> into the map returned by BeforeExecutionContext#getOverrideVersions. The tricky part is knowing when to do this (and what version to use), though—in the context of a hook, we don't currently know whether or not io.jenkins:configuration-as-code is being updated, and a hook is the wrong layer to be doing plugin metadata extraction. One solution might be to improve the plugin metadata extraction layer (both WAR and local checkout) to take in a list of "interesting plugins" whose metadata would be extracted and exposed to hooks whether or not the plugin is going to be tested. There might be other solutions I have not thought of. @jtnord are you interested in submitting a PR to fix this ticket?

jtnord commented 2 months ago

CloudBeesInstallationManagerHook (in a proprietary repository) does something similar to this. (it writes out the pom 🤮 after modifying but with the new code I believe that should be ignored and just 2 entries would need to be conditionally set in the overrides map).

there might be other solutions I have not thought of

IIUC this (specific) is of issue when a library needs to be updated in tandem with a plugin. If they should always be in lock-step then would it be beneficial to introduce an argument in the war to keep a given groupId:artifactId in lockstep with another groupId:artifactId?

In some ways this is just adding code for a (non common?) use case, where-as getting the specific info from the war and excluded plugins from the context is relatively quick and efficient. (IIUC the overrides will be ignored if the dependency is not present in the current plugin under test?)

are you interested in submitting a PR to fix this ticket?

I am currently busy on the FIPS related work and do not currently have the time available.