-
Notifications
You must be signed in to change notification settings - Fork 126
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
Add option to bump baseline of rjrinit plugin default to true #781
Add option to bump baseline of rjrinit plugin default to true #781
Conversation
if the version of Jenkins used by RealJenkinsRuleInit has detached plugins in the version of Jenknis used for the test then this can uncessescarily pull in detached plugins. In most cases this is harmless, but in some cases these plugins may be prevented from running under the test (e.g. testing FIPS and one of the detached plugins like eddsa is not FIPS complaint and blocks startup). The plugin itself has limited exposure to the Jenkins api (via hudson.plugin.Plugin and RealJenkinsRule$Init2). Code running from the plugin tests inside RealJenkinsRule use the uberClassloader and if the plugin was targetting a lower core (where the dependencies have been deteached, they should still be included as this change only affects the version of the RealJenkinsRuleInit plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer this over #780 if it works out.
* The intended use case of this is to prevent any detached plugins being dragged in when they would not normally be. | ||
* @param updateRealJenkinsRuleInitPluginBaseline {@code false} to skip updating the plugin, {@code true} (the default) to update the baseline. | ||
*/ | ||
public RealJenkinsRule updateRealJenkinsRuleInitPluginBaseline(boolean updateRealJenkinsRuleInitPluginBaseline) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or just do it unconditionally? If there are no known problems, why even offer the option to not do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
closing in favor of #782 |
#780 (comment)
to get an incremental build that can then be used in the bom
jenkinsci/bom#3284
Testing done
Submitter checklist