 |
History
| Log In
|
|
|
|
Sorry for the late response, but when you say "modify the build to clean out the results", what do you mean? I ask because we run "mvn clean install" and this _would_ normally clean out the results, but if maven has a problem starting (missing plugin, badly configured pom, etc) then the build is properly flagged with an error. However, the UI will show that the tests from the previous run all passed. It is merely a UI detail which is easily diagnosed if you look at the build log and see that maven didn't start. However, PHB's may not be "sophisticated" enough to grasp this. Sorry, been reading Dilbert lately.
I suppose what I was really asking is if I was missing something, which I obviously was! I hadn't considered this case (the build failing before it had a chance to clean). That certainly makes life more interesting. I will need to think more about this, but now I understand why you are suggesting timestamp checks.
Current workarounds for this include: - using either the clean checkout or clean update scheme (preferred if your build is quick anyhow) - using a custom/versioned build and splitting the build into multiple commands, where the artifact is captured in the last (test) command: if the test command doesn't run, the artifact won't be captured However, we will also review options for making this work with built-in projects and incremental builds. Glad I finally started making sense to you. :)
Actually my builds are clean checkouts and take less than 30 seconds. It's another of the project's I'm trying Pulse with that sadly checks out hundreds of MB of data (top level project, with a lot of sub projects). This project is simply too slow to do agile, clean checkouts with scm triggers. What we will probably end up doing is adding an option to ignore "stale" artifacts. This will be off by default, but at least it gives a way to handle this situation.
Re: long builds: we added incremental building for exactly this reason. Short builds are great, but life isn't always that easy :). |
|||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Incorrect test results reported when using checkout scheme: incremental update
We would prefer not to have Pulse second-guessing artifacts based on timestamps. In this case, our preferred solution is to clean out test reports at the start of the build. These test results are stale in any case: they do not correspond to the newly-built code. This has the potential to confuse users as well as Pulse!
Is it difficult to modify the build to clean the test results first?
Cheers,
Jason