We recently had an issue where our CI build broke over the weekend.
We used git bisect to figure out where the problem occurred.
We wrote a cucumber feature (feature/path/to/is_it_fixed.feature) that worked on Friday and fails today.
We start by setting up git bisect:
git bisect GOOD BAD
Where GOOD is the git SHA from last Friday and BAD is this morning’s SHA.
Then we created a shell script that will setup the environment and run the feature:
#!/bin/bash set -e git checkout . rake db:drop rake db:create rake db:migrate rake db:test:prepare cucumber feature/path/to/is_it_fixed.feature:20 -r features
We then run this command with the following:
git bisect run /path/to/shell/script.sh
This will then automatically keep running until it finds the SHA that breaks that feature. At the end of the run, it helpfully prints “SHA __ caused the issue”.
Very cool.
Yeah, git bisect is definitely nice. The main gotcha I know of is that “git bisect run” will get confused if a commit makes the test fail for a reason unrelated to the problem you are trying to track down. To avoid this, I sometimes run the test manually and explicitly say “git bisect good” or “git bisect bad” at each step (so I can look at the test output and make sure it is failing in the expected way, or “git bisect skip” if it is not able to run well enough to test the thing I am looking for).
May 10, 2011 at 7:24 am