Typical build-breaker usually knows what’s wrong and attempts to fix the build by checking changed code in. Now, how many times we knew exactly why build was red after our check-in but we could not fix it quickly anyway? We needed few commits, few more red passes to finally make the bloody thing green.
I like when unfortunate build-breaker first reverts his change, lets the build go green and in meantime tries to solve famous it-works-locally mystery. However I can see 3 and only 3 exceptions to the golden you break you revert rule:
- The team is small. Small team usually means small and easily manageable codebase, simple and stable CI process, not many problems in merging. To wrap up: not much time and money is spent if build is red.
- Oops, I forgot to check-in new files. Everybody does it from time to time (famous ‘show unversioned files checkbox‘ in tortoise should not exist or at least should be hardcoded to true), there is not point in reverting – just check in missing files. It’s always worth looking why the build failed and see whether there are any cannot-be-resolved-to-a-type compilation errors (oh, that’s java =).
- Cannot really reproduce the problem locally. CI environment is usually different than local (different OS, etc.) and that can cause problems. Sometimes it’s better to check the fix in since you cannot reproduce the problem locally anyway. However, if it’s possible to test the build in CI environment before checking in, than I would definitely do the revert.