My initial blog on this topic attracted a bunch of comments, and some great blogs on this, especially RobHelmer’s blog and Rob Campbell’s blog.
One thing that became quickly apparent is that if we do change from “build-always” to “build-on-checkin”, we should have the pool of slaves already setup beforehand. We had originally planned to start off with one slave per o.s., and then grow to multiple slaves per o.s.. However, setting up multiple slaves *before* changing the build-mode is also fine to do, so we’ll change plans to that. For details, see bug#411629.
I wanted to quickly thank everyone for their comments so far, they were really helpful. We’re still digging through all the other posts & comments, but if people had any further thoughts, please keep them coming…
I may be repeating something lots of other people have suggested here, in which case I apologize.
One of your prior posts mentioned that one of the problems with build-on-checkin is that it doesn’t flag changes that aren’t triggered by a checkin – hardware problems, build environment changes, etc. Worse, it incorrectly flags those problems as having been caused by the next checkin that happens afterwards, which could cause all manner of headaches for the poor unwitting developer who checked in a perfectly good change and is now on the hook for something they can do nothing about.
One way around that would be to have the build machines build all the time, just like they do now, BUT if a checkin happens mid-build (and at least one full build has completed since the LAST checkin), throw away the build in progress, kill all the processes, and start over. Then you still get the instant triggering of a new build on checkin, but problems that occur while the machines are idle don’t get masked.
The only downside is that it’s less eco-friendly to have the machines constantly working hard, compared to having them idle when not “needed”.
Is that remotely feasible?