git bisect…

…or how I found out who broke Jira’s coverage build last night.

Jira’s Clover Code Coverage build is scheduled to run once a day. Yesterday someone checked in something that broke 194 tests. The problem is there were 18 commits by 7 unique authors and none of the commits come with a helpful message like “Warning, this commit is the one that will break the coverage build!”

To try to narrow down which of the commits was the problem, I decided to use an automated bisection of commits.

git comes with a built-in utility called bisect. This isn’t unique to git. You can even do it with subversion via svn-bisect. The idea is that you tell it a good revision and a bad revision and then git helps you perform a binary search to narrow down exactly which commit broke things.

git bisect start
git bisect good 954f7b79c36ac39087ebb441079a638e7c497a0c

I knew that things were working yesterday so I found a git commit that I knew was good.

git bisect bad HEAD

And I know that HEAD is currently broken. At this point git tells me there are 15 revisions to test.

git bisect run maven clean test:single -Dtestcase=com.atlassian.jira.service.util.handler.TestCreateIssueHandler

Then I give git an automated test to run and let it go through revisions to figure out when the break occurred. I picked just one of the failing tests rather than running the entire suite to speed up the process.

The setup took less than 60 seconds. “git bisect run” took 1 minute, 41 seconds to bisect the revisions. In under three minutes I knew who had made the bad commit.

Hmmm…looks like it was me. Damn.