Commit Gate

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.

Checks the continuous integration state to see if it is either Green or Yellow.
Checks whether the commit object contains some sort of identification that it is for fixing build. This can be as simple as commit message containing text like "Fixing build".

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.

Centralized VCS
Commiter's VCS (in case of distributed VCS) or VCS Client (e.g. with SVN). Since this pattern also amounts to policing running it on the commiter's environment might be socially more acceptable.

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.