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
