Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
basil opened this issue Aug 29, 2024 · 2 comments

Comments

@basil
Copy link
Member

basil commented Aug 29, 2024

@mawinter69 reported jenkinsci/configuration-as-code-plugin#2551 (comment).

@basil
Copy link
Member Author

basil commented Aug 29, 2024

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
Copy link
Member

jtnord commented Sep 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants