Test-only plugin from source in RealJenkinsRule

[jglick]

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

jenkins-test-harness/src/main/java/org/jvnet/hudson/test/RealJenkinsRule.java

Line 140 in 787a641

* <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.

jenkins-test-harness/src/main/java/org/jvnet/hudson/test/RealJenkinsRule.java

Lines 222 to 227 in 787a641

	* @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.