Failing injected tests for Jenkins plugin

[Andrei Tuicu]

Hello everyone,

I have finished implementing a plugin[1] that integrates Jenkins with Jira, but I cannot release it, because two injected tests are failing. I did some research, but I could not find a clear indication about how to resolve the root causes for them.

I created an issue in JIRA [2], where I posted the stack traces, steps to reproduce, link to the official Jenkins job[3] and other details, but no one replied there so I'm trying the mailing list as well.

The two tests that I'm having trouble with are:

org.jvnet.hudson.test.PluginAutomaticTestBuilder$CliSanityTest.testCliSanity

org.jvnet.hudson.test.junit.FailedTest.org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite

Is there anyone how encountered these problems, or could offer any information about what are the root causes of the failing tests and how can I fix them?

Thank you,

Andrei Tuicu

[1] https://github.com/jenkinsci/JiraTestResultReporter-plugin 

[2] https://issues.jenkins-ci.org/browse/JENKINS-34129

[3] https://jenkins.ci.cloudbees.com/job/plugins/job/JiraTestResultReporter-plugin/

[Slide]

Just as an FYI, no one probably looked at the issue because it wasn't assigned to anyone. Do you specifically need version 2.10 of the maven plugin for your compilation? If not, you can remove that as a dependency. You may also want to look at using the new 2.x parent pom version for plugins. 

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJb%2Bn00fUf-w8Zxfi9r2fbv_SmRDV9uhcb7dBmO73oX%3D-TLUHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Andrei Tuicu]

Hello, slide,

Thank you for your response!

The reason why the issue is not assigned to anyone is because I added the wrong component (release-plugin) when I created it, so it got assigned to the person in charge of that particular component. Later, I changed the component and removed the assignee, but I did not know who to assign it to, so I just left it like that hoping it will be picked up. Can you recommend someone to assign it to?

I removed the dependency and changed the parent pom for the plugin, but the first test is still failing. I don't know if the second one is not failing anymore, or if with this configuration maven stops running tests after the first fail.

Thank you,

Andrei

[Andrei Tuicu]

Hello everyone,

I am trying one last time to find an official fix for these problems. If not, I'm going to release the plugin as is and perform a new release for fixing those particular tests when I find a solution in the future.

Thank you,

Andrei

[Robert Sandell]

The first one is most likely a version clash of com.google.common.cache.CacheBuilder

Do you have a dependency to guava in your plugin that is different from the one in core?

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9098ca69-960f-40a8-84f5-a84d1d2bd6ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Andrei Tuicu]

Hi, Robert!

Thank you for your response! Yes, I do have an indirect dependency to guava, because I am using the Jira Rest Client library[0]. Do you have any advice on how to resolve this conflict without breaking any functionality in Jenkins or the plugin?

Andrei

[0] https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client/server/overview

[Robert Sandell]

Well it's kind of a tricky situation.

The test issue is probably because in the test scope when you run via maven the guava jar from the jira lib is discovered before the one from core, and guava is notorious for not keeping backwards compatibility (that's why core hasn't updated from the ancient one it's already using) And the test is using something in a class that doesn't exist any more.

You can solve that by adding an exclude of the indirect guava dependency in your pom, making the one from core the "only one" in the classpath.

But that would likely cause issues for the jira lib because it most likely needs the newer classes.

If it was a runtime issue (when the plugin is running in a standalone Jenkins instance) It should be solvable by setting pluginFirstClassLoader https://jenkinsci.github.io/maven-hpi-plugin/hpi-mojo.html#pluginFirstClassLoader but I don't think that solves the test scoped issue.

I would look at what all the other jira related plugins are using, for example https://github.com/jenkinsci/jira-ext-plugin

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/84351d3f-cbbd-441c-97a8-8aeb4c962e4d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.