stephane ducasse wrote:
Hi yanni
I wanted to know if you can tell us what means (unstable) in the report summary
http://hudson.jooshr.org/job/Pharo1.1/81/ is it because the tests cannot run?
Here's my interpretation. The status of the last build (the big ball in the first column) is important: blue - the code built okay, and all tests passed yellow - the code built okay, but some tests failed grey - the build/test was aborted (either manually, or by the Hudson build timeout plugin I installed) The sun/cloud icon in the second column is some fuzzy indicator that uses the last few builds in its calculation. In the case of Pharo1.1 build 81 (your link above), I don't see an "unstable" report. I see the "Aborted" when I hover over the grey ball. What's confusing is that if you hover over the shiny sun icon, you get a "Build stability: no recent builds failed". That's misleading, because the most recent build was aborted - but that does not count as a failure. Now that I think about it, there might be an option on the timeout plugin, to cause a build failure, when it's been aborted. The timeout happens (and therefore an aborted build), when: - PharoDebug.log is generated and debugger is opened - during the build (i.e. loading packages or running scripts) a popup appears that requires a user response - when running tests, user input is required - long running test exceeds the timeout that was set I usually look at the workspace to see what's happening, or has happened. I watch the package-cache or the size of .changes file to see if code is still loading. I watch the size of .xml test result files, to see if tests are still running. "watch" means click the refresh every few seconds. Back to build 81, the console output has: Build timed out. Aborting Build was aborted Archiving artifacts Recording test results Test reports were found but none of them are new. Did tests run? For example, /home/yanni/.hudson/jobs/Pharo1.1/workspace/core11-tests/AllTestCases.xml is 23 hr old Finished: ABORTED Which means that it's stuck during the package load, since the test .xml was never overwritten. At this point, I would download core11 from the workspace, using the "all files in zip" link. Open the image locally, and filein the core11.st script, to see what happened.