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

Test-only plugin from source in RealJenkinsRule #623

Open
jglick opened this issue Jul 17, 2023 · 0 comments · May be fixed by #659
Open

Test-only plugin from source in RealJenkinsRule #623

jglick opened this issue Jul 17, 2023 · 0 comments · May be fixed by #659
Assignees

Comments

@jglick
Copy link
Member

jglick commented Jul 17, 2023

JenkinsRule tests commonly use @TestExtension to define mock implementations of various APIs, which is a very powerful system. For RealJenkinsRule, there is no direct equivalent. As

* <li>Possibly {@link ExtensionList#add(Object)} can be used as an alternative to {@link TestExtension}.
hints at, you can define new types in test sources and load them in a Jenkins JVM, and even register them programmatically with ExtensionList.add (suppressing the deprecation warning), but they will be defined in an unusual class loader (not UberClassLoader) and there may be other reasons why the test cannot be made to pass or would not be convincing if it did.

🤔 There could be a system whereby you could define a src/test/java/some/dedicated/pkg/package-info.java with a SOURCE-retention annotation directing a processor to create a target/test-classes/plugins/some-dedicated-pkg.jpi which could be included in addPlugins.

* @param plugins Filenames of the plugins to install. These are expected to be absolute test classpath resources,
* such as {@code plugins/workflow-job.hpi} for example.
* <p>Committing that file to SCM (say, {@code src/test/resources/sample.jpi}) is
* reasonable for small fake plugins built for this purpose and exercising some bit of code.
* If you wish to test with larger archives of real plugins, this is possible for example by
* binding {@code dependency:copy} to the {@code process-test-resources} phase.
notes that when you do this today, you must commit the plugin binary to Git, making the test harder to review and maintain.

@jglick jglick self-assigned this Sep 27, 2023
@jglick jglick linked a pull request Sep 27, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant