…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.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now