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

Dynamically create the RealJenkinsRuleInit plugin #782

Merged
merged 6 commits into from
Jun 10, 2024

Conversation

jtnord
Copy link
Member

@jtnord jtnord commented Jun 6, 2024

Switch to dynamically creating the plugin used by RealJenkinsRule

The plugin will have its Jenkis baseline set to the version of the war to ensure that no detached plugins are pulled in.

Previously 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 useis 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.

based on a suggestion by @jglick #780 (comment)

obsoletes: #781

Testing done

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@jtnord jtnord force-pushed the build-rjrinit-plugin-dynamically branch 2 times, most recently from 0f623ed to 77215ac Compare June 6, 2024 13:17
Switch to dynamically creating the plugin used by RealJenkinsRule

The plugin will have its Jenkis baseline set to the version of the war
to ensure that no detached plugins are pulled in.

Previously 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 useis 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.
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks perfect.

src/main/java/org/jvnet/hudson/test/PluginUtils.java Outdated Show resolved Hide resolved
src/main/java/org/jvnet/hudson/test/PluginUtils.java Outdated Show resolved Hide resolved
src/main/java/org/jvnet/hudson/test/PluginUtils.java Outdated Show resolved Hide resolved
Co-authored-by: Jesse Glick <jglick@cloudbees.com>
@jtnord jtnord marked this pull request as ready for review June 10, 2024 10:52
@jtnord jtnord merged commit 0622967 into jenkinsci:master Jun 10, 2024
14 checks passed
@jtnord jtnord deleted the build-rjrinit-plugin-dynamically branch June 10, 2024 10:53
@jglick
Copy link
Member

jglick commented Jul 5, 2024

This seems to break tests which deliberately run an older Jenkins version (withWar) for purposes of testing compatibility. Maybe we can get a new method in RJR to override targetJenkinsVersion?

Edit: probably unnecessary; I found a workaround: call withWar before the test starts.

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

Successfully merging this pull request may close these issues.

2 participants