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?