> > We could introduce a new system property or environment variable pointing > to a custom WAR file > path for `WarExploder` to use, perhaps. >
Yes, I had something like that in my TODO list for the final impl. It would require plugins to update to the recent JTH, but it's not a problem since we can always pass Maven property when running builds in CI/PCT. It may fail in some cases (upper bounds, new injected tests, etc.), but should work for the most of the plugins Yes it does, but that has no direct effect on the file which is loaded by > `WarExploder`. The actual test runs will go back to the local Maven > repository for a `jenkins-war` artifact with the specified version number It is fine with me, because Custom War Packager installs artifacts to the local repo anyway. Obviously there are some limitations on groupId and artifactId to make such approach running, but it works. BR, Oleg On Thursday, March 22, 2018 at 9:00:12 PM UTC+1, Jesse Glick wrote: > > On Thu, Mar 22, 2018 at 2:58 PM, Oleg Nenashev <[email protected] > <javascript:>> wrote: > >> How would that work with JTH tests as run via PCT, since these will > only > >> pick up a Jenkins WAR from the local Maven repository > > > > JTH can take WAR from different sources, not only from local Maven > > repository (see WAR Exploder). I was a bit lazy during prototyping, so I > was > > just putting WAR to war/target/jenkins > > Uh…but that is only supposed to be used from `jenkinsci/jenkins`. We > should not abuse that for other purposes. We could introduce a new > system property or environment variable pointing to a custom WAR file > path for `WarExploder` to use, perhaps. > > > PCT supports "-war" option, which allows specifying a custom WAR path. > > Yes it does, but that has no direct effect on the file which is loaded > by `WarExploder`. > > > https://github.com/jenkinsci/plugin-compat-tester/blob/4898b916f81f813d202721e1fe0eb36d222977a5/plugins-compat-tester/src/main/java/org/jenkins/tools/test/PluginCompatTester.java#L155-L207 > > > It is only used to pick up metadata about the core version to test > against, the list of plugins and their versions to test, and some > miscellaneous stuff like that. The actual test runs will go back to > the local Maven repository for a `jenkins-war` artifact with the > specified version number, unless `WarExploder` is patched as discussed > above. > > > Next week I will create a demo which actually runs JTH and PCT with a > custom WAR file within the repository. > > Yes please—somehow verifying that the tests run against the actual > core and plugin versions specified in the YAML definition, even if > those are unreleased, present only in local source checkouts, etc.; > and that all plugins listed in the YAML are loaded during the test > execution, even if they are not present as `test`-scoped dependencies > in the POM of the plugin defining the test. > > Also would be useful to see a demo of ATH tests running against this > WAR, with the same version constraints, and analogously verifying that > all listed plugins are loaded even if they are not mentioned in a > `@WithPlugins` annotation. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d3c7ab12-626d-4654-9ff3-e50aaab66417%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
