Hi, all
Ok, there's a new analysis on the public server on the extra page.
Choose: hacky2004-all, [EMAIL PROTECTED], Oct 11, 2005.
It appears that everything is correct, at least from my own data. I do
have a failed local testing cycle earlier in the day, but that's the
checkstyle error in the files I chose not to commit.
The build sensor needs updating. To my surprise, it only detects module
name in compilation task.
Please let me knwo if you have any suggestions for improvement, apart
from page formatting.
Thanks.
Cedric
Philip Johnson wrote:
This is fun. :-)
So, the build failed:
Hackystat build (configuration Hackystat-ALL) failed.
And then with great excitement I checked my build analysis email:
Integration build for hacky2004-all project on 12-Oct-2005 FAILED.
[C:\CruiseControls\instance-ALL\hacky\hackyAnt] [Compilation, ]
[Plausible culprit: N/A]
[EMAIL PROTECTED]: 1 [1 / 0 / 0 / 0]
[EMAIL PROTECTED]: 2 [1 / 0 / 0 / 1]
[EMAIL PROTECTED]: 1 [1 / 0 / 0 / 0]
Boo hoo! It couldn't figure it out! I went to the changelogs and
found the following:
[1] the failure was due to a compilation error in hackyAnt:
BuildSensorAntListener.java:129: cannot resolve symbol
symbol : method setBuildResult (boolean)
location: class org.hackystat.stdext.build.sdt.BuildResult
this.buildResult.setBuildResult(this.buildResult.getBuildFailures().size()
0);
[2] there were no commits directly to hackyAnt (which is why the build
analysis couldn't figure anything out)
[3] however, there were commits to:
- hackyBuild
- hackyBuildAnalysis
- hackyInstaller
- hackyKernel
- hackyReport
- hackyStatistics
- hackyStdExt
[4] The file (BuildResult.java) defining the class involved in the
compilation error (org.hackystat.stdext.build.sdt.BuildResult) was
changed by qzhang (btw, there was no commit message!). This is in the
module hackyStdExt. There was actually another commit to this module
by johnson (v7.local.build.xml), but of course that file is irrelevent.
Conclusions:
- This is the second build failure in a week in which simplistic
checking the module that failed for the culprit does not suffice. We
may need to make the system more intelligent. (If so, the
'intelligence' should be designed in a modular and extensible way,
because this could be a really nice general purpose facility.)
- In this case, the system could have correctly identified the culprit
by:
- identifying the class that failed during compilation (BuildResult)
- checking to see if the associated file (BuildResult.java) was
changed (it was)
- who did the change (qzhang).
As you can see, this is a somewhat heuristic routine. That's why I
think the BuildAnalysis module needs to be designed in a modular and
extensible way: we might incrementally build up a dozen or two of
these heuristics which get applied one after the other before we get
to an analysis system that deals with most of the ways we fail the
build (and, of course, another development environment would need a
different set of heuristics.)
Actually, there's another, more simple heuristic that could be
successfully applied using this info:
[EMAIL PROTECTED]: 1 [1 / 0 / 0 / 0]
[EMAIL PROTECTED]: 2 [1 / 0 / 0 / 1]
[EMAIL PROTECTED]: 1 [1 / 0 / 0 / 0]
Note that out of the three committers, qzhang was the only one with a
commit batch that wasn't fully tested. Applying the heuristic that
"whoever didn't do the full build/test is the culprit" would have also
correctly identified Cedric!
Cheers,
Philip
