tags:

views:

116

answers:

1

I'm using the filesytem plugin for Hudson, and when a build happens it looks for new/modified files, copies them to the Workspace, runs tests using Rake, and then publishes those junit xml result files.

However, the updated junit xml result files don't get pushed to the workspace until the next build. This means that when the publishing of the junit xml result files happens, it's always one step behind. And this means I need to run a build twice before the results show.

The Rake task is creating the junit xml files in the project directory. I've tried outputting to the workspace directory, but it seems to make things worse and the results don't get published at all.

Am I doing something fundamentally wrong here? Is there a simple way of getting those junit xml results pushed to the workspace so that the post-build "Publish JUnit test result report" actually runs against the newly created xml files?

A: 

I am confused with the following sentence:

However, the updated junit xml result files don't get pushed to the workspace until the next build.

Does Rake produce the junit.xml? The whole description sounds like: The build happens outside of Hudson. The build produces the junit.xml and Hudson just picks up the build and the junit.xml and copies it into the workspace for publishing the junit.xml. So hudson detects the changes before the build (including junit tests) is finished and there only gets half of the build or even the old build. The fix would be to configure either quite periode longer than what your build takes or let your build notify Hudson when to run your rake job. The configuration setting would be "Trigger builds remotly" instead of poll SCM. Even if rake produces the junit.xml, it might be that rake actually runs on an old version of code, because the rake job starts before the new build artifacts are available.

My suggestion would be to use Hudson for building and chain both jobs together so that the rake job will be triggered when the build job is finished. The transfer of the necessary build artifacts can be through an repository outside of Hudson (could be as simple as a network share). In this case the build job copies the necessary files into the repository and the rake job pulls it again. You can also play around with the archive artifacts functions from Hudson. Another more elegant option is the Clone Workspace SCM Plugin, which handles the transfer of a workspace to another job.

Peter Schuetze