-
New Feature
-
Resolution: Done
-
Critical
JenkinsRule-based tests generally load not only Jenkins core but also all plugins from ${java.class.path}, i.e., the Maven test-scoped classpath. This is convenient in some ways but also means that class loading is done in a very different way than in an actual production instance, or even mvn hpi:run, making it very hard to test changes like JENKINS-26192 without using the much clunkier, slower, and flakier acceptance-test-harness. It also means that we are forever fighting with Maven's weird transitive dependency management (JENKINS-41631, JENKINS-39301, etc.).
There should be an option to run JenkinsRule in a mode whereby the test classpath is only used to load Jetty; Jenkins core and its WEB-INF/lib/*.jar (including modules!) is loaded in a derivative class loader; and then plugins are discovered from the test classpath, transitive dependencies computed and verified, and finally loaded in the real plugin class loader (probably using *.jpl files to allow us to still load from unpacked development trees). Finally, the test suite itself needs to be reloaded in a fresh loader parented to UberClassLoader, and executed from there.
NbModuleSuite demonstrates the concept, though the details would be rather different for Jenkins.
There are a lot of details to be checked, such as
- @TestExtension handling
- PluginWorkspaceMap support for coördinated snapshot development
- moving InjectedTest from HudsonTestCase so that it can use the new mode
- blocks
-
JENKINS-5303 Upgrade Acegi Security to the latest Spring Security release
-
- Resolved
-
- causes
-
JENKINS-62776 NoClassDefFoundErrors after updating
-
- Resolved
-
- is blocking
-
JENKINS-50520 Remove jClouds shading
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Open
-
-
-
- Open
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Open
-
-
-
- Open
-
- links to
[JENKINS-41827] JenkinsRule mode to use realistic class loading
Another use case for out-of-process testing is to reproduce bugs specific to a non-Jetty container, such as JENKINS-31068.
Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/hudson/plugins/mercurial/MercurialSCMSource2Test.java
http://jenkins-ci.org/commit/mercurial-plugin/8a429bf3d682c73b451697e4bf7cb8f35b8b9efa
Log:
Test fails on CI when it should merely be skipped (pending JENKINS-41827 rewrite to keep master in a container).
In discussion with svanoort we realized this could be useful for testing durability guarantees & recovery scenarios in Pipeline, for example if there is a SIGKILL delivered to the master at a specific point in the build.
Durability tests turned out to be feasible with a simple addition to RestartableJenkinsRule.
I suspect Arquillian would be much more trouble than it is worth, since Jenkins uses only a little bit of the Servlet system and then has its own big complex module system completely outside of that.
Can this issue be also the root case for my failing tests? I moved the JS files of my warnings plugin into separate plugins to simplify the reuse in other plugins. Now all UI tests fail since the JS files are not found any more: example failure - 404. I get the 404 for all JS scripts that are part of one of my dependencies (the JS files in my plugin seem to work). Everything works fine in a real Jenkins instance.
java.io.IOException: Unable to download JavaScript from 'http://localhost:39309/plugin/data-tables-api/js/table.js' (status 404). at com.gargoylesoftware.htmlunit.html.HtmlPage.loadJavaScriptFromUrl(HtmlPage.java:1054) at com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:982) at com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:362) at com.gargoylesoftware.htmlunit.html.HtmlScript$2.execute(HtmlScript.java:236) at com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:257) at com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:792)
Optional dependencies (JENKINS-19508) could also be verified by a harness which allowed some of the plugins in the test classpath to be omitted from the set.
More ambitiously, there could be an option to start Jenkins and run the tests in another JVM, in a Docker container running an image specified in the test case. This would allow tests to reproduce issues specific to certain on-master operations, such as native executables used for SCM caching, which docker-fixtures cannot simulate. On the other hand perhaps this indicates that the feature in question needs to be rewritten to use an agent! Another use case is bugs specific to a certain JVM.