-
Notifications
You must be signed in to change notification settings - Fork 55
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
Set jth.jenkins-war.path
unconditionally when running tests
#470
Conversation
this causes a large amount of test failures as the megawar we use for testing is actually our product war which also contains other things - its not just on top of that there are a few other issues, but they may be fallouts of the above. I'm seeing if I can quickly fix the issues, will continue tomorrow morning, however if not I would suggest we close this. |
as mentioned in the upstream PR that attempted to do this unconditionally this is broken by design. the JTH and tests assume that the classpath is correctly setup however it is not, as demonstrated in the prior commit. According to Jenkins there is a plugin installed (trilead-api) because it is in the megawar, however its classess are not in the flat classpath used by JenkinsRule and thus breakage ensues. ref: jenkinsci/plugin-compat-tester#470 (comment)
as mentioned in the upstream PR that attempted to do this unconditionally this is broken by design. the JTH and tests assume that the classpath is correctly setup however it is not, as demonstrated in the prior commit. According to Jenkins there is a plugin installed (trilead-api) because it is in the megawar, however its classess are not in the flat classpath used by JenkinsRule and thus breakage ensues. ref: jenkinsci/plugin-compat-tester#470 (comment)
as mentioned in the upstream PR that attempted to do this unconditionally this is broken by design. the JTH and tests assume that the classpath is correctly setup however it is not, as demonstrated in the prior commit. According to Jenkins there is a plugin installed (trilead-api) because it is in the megawar, however its classess are not in the flat classpath used by JenkinsRule and thus breakage ensues. There are also issues where a plugin is present that is incompatable with a mode of running for the test - e.g. a system property is set when running JTH to test a mode of running for a plugin (e.g. FIPS) and the plugin itself is incompatable with that mode (which causes a BootFailure). ref: jenkinsci/plugin-compat-tester#470 (comment) fixes: jenkinsci#3231
as mentioned in the upstream PR that attempted to do this unconditionally this is broken by design. the JTH and tests assume that the classpath is correctly setup however it is not, as demonstrated in the prior commit. According to Jenkins there is a plugin installed (trilead-api) because it is in the megawar, however its classess are not in the flat classpath used by JenkinsRule and thus breakage ensues. There are also issues where a plugin is present that is incompatable with a mode of running for the test - e.g. a system property is set when running JTH to test a mode of running for a plugin (e.g. FIPS) and the plugin itself is incompatable with that mode (which causes a BootFailure). ref: jenkinsci/plugin-compat-tester#470 (comment) fixes: #3231
* Introduce EdDSA-api plugin * Do not set the JTH War file as mentioned in the upstream PR that attempted to do this unconditionally this is broken by design. the JTH and tests assume that the classpath is correctly setup however it is not, as demonstrated in the prior commit. According to Jenkins there is a plugin installed (trilead-api) because it is in the megawar, however its classess are not in the flat classpath used by JenkinsRule and thus breakage ensues. ref: jenkinsci/plugin-compat-tester#470 (comment) --------- Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
moves #468 onto an origin branch.