What exactly is considered "breaking the build?"

Question

In a CI environment, what exactly is considered a broken build?

There are several answers I can imagine (any combination of compiles, tests pass, metrics are in range, documentation exists etc.) , but I am not sure which of these are cannoncial.

For example, just today it happened to me that I actually checked in all code changes but forgot to commit the Visual Studio project file, thus breaking the unit tests. (even though I literally triple checked my commit, as it's a public OSS project on google code).

I was easily able to fix this in under a minute after my first commit, but should I consider myself a buildbreaker now?

How do you configure your CI environment: Is every revision built or only the newest version after each complete build, or do you use time based checking for new revs?

Answer 1

Ideally, you have

1. automated script that is scheduled to run each night to build the application from source code.

2. Scripts to copy the binaries to a directory/set of directories from which another script can be run to deploy the application if it is running in your environment, or used to create deliverables for a customer.

3. Automated suite of tests that run and verify all components pass all tests.

4. Automated script that verifies that the build has been built correctly.

5. Automated script/monitoring system that sends out an alert if the verification script fails.

When an alert is generated by the above process, then that is considered "breaking the build".

But since procedures/processes can vary from company to company, there may be alternate definitions. In some places it may be breaking the unit tests. Others it may be checking in source code that results in the code being unabl to compile.