Context
Only fix to be allowed on a broken/breaking build
Description
Continuous integration, hence code commit, is a team activity. A broken CI build adversely affects the flow of the entire team, hence needs to be fixed at highest priority. A commit made on top of broken build has no chances of fixing it accidentally. It can in fact make it worse. Negligence or lack of knowledge of build status can lead to commits on top of broken build. This works better than having to revert the commits manually, as it is quite usual for the original commiter to forget to recommit when the build is green again.
Continuous Integration States
Green: Successful and not building
Red: Failed and not building
Yellow: Successful and building
Orange: Failed and building
Pink: Failing (In integration which have multiple jobs running in parallel, if a job fails while others are still running. Might not apply for tools)
Grey: Unknown (for server, network being down)
Of the above states on Green and Yellow are valid states in which a non-fix commit should be allowed. Most modern source control systems provide facility to hook custom code (e.g. http://www.kernel.org/pub/software/scm/git/docs/githooks.html). Pre-commit hook does the following.
If both the tests above pass then Pre Commit Hook allows the commit to go through.
There are places to run the Pre Commit Hook.
Limitation
If the continuous integration server doesn't respond very quickly to status check then the users commit might get delayed. This might cause annoyance to the commiters.