views:

2172

answers:

4

My Hudson projects don't seem to properly aggregate downstream test results and I'm wondering if I've missed a configuration step somewhere. I have two projects, Foo and Foo-Tests, both of which are freestyle jobs.

On project Foo I have the following configuration:

  • Checked "Aggregate downstream test results".
  • Checked "Automatically aggregate all downstream tests" under the previous option.
  • Checked "Build other projects" and specified "Foo-Tests" to build.

On project Foo-Tests I have the following configuration:

  • Checked "Publish JUnit test result report" and specified my JUnit report XML files.

When Foo builds, it builds successfully and correctly triggers a Foo-Tests build. The Foo-Tests build is successful and publishes the JUnit reports correctly. However, when I look for the aggregated test results in Foo, there's a "Latest Test Result (no tests)" link for the build which sends me to a 404.

Here's what I've tried that doesn't solve the problem:

  • Tell Foo to "Publish JUnit test result report" with no parameters (there are no tests in project Foo, just Foo-Tests). This caused an error since there were no test files for it to process within the project.
  • Tell Foo-Tests to "Fingerprint all published artifacts" with no parameters (I was wondering if Hudson treated JUnit reports as artifacts behind the scenes). This caused an error since I hadn't explicitly defined any artifacts to publish.

I'm using Hudson 1.266.

Edit: I should note that I've found two questions on the Hudson Users mailing list that have no answers and would possibly help solve this:

+3  A: 

I was able to replicate your problem with Hudson 1.266. This a Hudson error, which was fixed in a later build (prior to 1.287), so either upgrade Hudson or use this two-click workaround: from the Project page, go first to Latest Build and then Aggregated Test Results.

The problem is that the Project page for Foo is only showing the Latest Test Results link, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/testReport/. Since Foo has no tests of its own, this link has no JUnit XML file to reference and returns the error you mentioned. This was fixed somewhere between 1.266 and 1.287 by redirecting from latestBuild/testReport/ back up to latestBuild/ when there are no tests. The alternative for you in 1.266 is to, instead of clicking on Latest Test Results in the Project page, scroll down a bit and click on Latest Build under Permalinks. This will take you to the latestBuild/ URL, and from there you can click on Aggregated Test Result, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/aggregatedTestReport/. On this page, all your test results from downstream projects will be available under the Drill Down section.

Unfortunately, there is still a problem with the Drill Down links, even in 1.287. From Foo, when you drill down to Foo-Tests as outlined above, you will be taken to a malformed URL, which looks like http://localhost:8080/hudson-1.287job/Foo-Tests/. You'll have to manually modify that URL to insert a / between the hudson context and the job path following it so that it looks like http://localhost:8080/hudson-1.287/job/Foo-Tests/. Then you will be able to actually see the downstream test results.

I haven't had a chance to look through the Hudson source to find the error, but there's already an issue open for this. Its issue 1574, and its been open for almost a year.

On a side note, I really love Hudson for CI, but their interface isn't as smooth as it could be. I look forward to their rework of the UI in ExtJS. Maybe thats what they're spending all their time on.

John Ellinwood
Thanks for the answer, this is excellent. I'll have a chance to try it out tomorrow.
Rob Hruska
No problem. I'll comment again if I find the location of the error in the source.
John Ellinwood
This didn't quite work for me. However, I think this answer is sufficient enough for most people that would be experiencing this issue. Plus, the reference to the JIRA issue that's already open is a good outside reference to keep an eye on. I'll mark this one accepted. Thanks for your help.
Rob Hruska
+2  A: 

I fixed the missing '/' issue in Hudson 1.288

The key to using the aggregate downstream tests results is to run fingerprinting on both jobs. In this case, that would be 'Foo' and 'Foo-tests'

Hudson matches up the build with the downstream tests by finding files with identical fingerprints. So this means your fingerprints have to match. Kind of like a crime scene.

Michael Donohue
+4  A: 

We're using Hudson ver. 1.324 and had similar trouble. Although you mention that you tried enabling fingerprinting and it didn't work for you, it did for us. We followed the instructions found here:

http://shotgunsandpenguins.blogspot.com/2009/07/how-to-aggregate-downstream-test.html

Jonathan Oliver
+2  A: 

the two projects, Foo and Foo-Test, have to know they're on the same stream, so it takes fingerprints (and therefore archiving) of a common file.

i had to pick a file that didn't change between the running of Foo and Foo-Test, and still changed between times they are both run. for me that was an unrelated, temporary .jar generated by Foo in the custom/common workspace for my versions of Foo and Foo-Test.

i.e., i had to let both Foo and Foo-Test fingerprint the same file.

after that, at least with hudson 1.330, things work - aggregated links, drilldown, etc.

Ingvald
Ingvald, could you clarify, did it have to be the *same* file or a file with the same contents? Is it a good idea to let Hudson use a common workspace for this and share it between two jobs?
Artem
Artem, it had to be the same file, yes, not just identical content.sharing workspace can be a good idea at first, not least since you save time on updating from your SCM system (which is less of a problem when you upgrade your CI system to its own computer, or add slaves). con: less direct relation between build fails and specific commits, f.ex. if you want to send an email to the developer(s) who caused a build to fail.
Ingvald