As a build engineer, I'm constantly looking for new and interesting ways to improve our build process - and that includes looking for new and interesting ways to fail our builds!
I have yet to find a canonical list of reasons to fail a build ... so I figure it's time to get one created. With that in mind:
What build-time checks - both obvious and creative - have you seen fail builds?
Something as simple as a check on compilation failure should be considered mandatory, nuff said.
Check-ins that lead to broken builds should be unacceptable, although the sad truth is that many organizations do accept such.
If the compilation fails:
Why? BECAUSE THE BUILD IS BROKEN.
In his article introducing Continuous Integration, Martin Fowler presented failure to run the application's suite of unit tests as a compelling reason to fail a build.
Unapproved Checkins in Build. Things like code checked in that is not associated to a work item or a bug fix.
Introducing a cyclical dependency between modules (eg java packages).
My company doesn't actually do this, but with a large legacy codebase like ours, it would be good to fail on undocumented changes. Without a bug ticket of some kind, our QA department wouldn't know to test the changes, and that is scary!
Check for duplicate classes (same package and class name) in different jar files (Java).
Code coverage decreases or falls below an acceptable threshold.