In last year or so it happened that I had to bisect Chrome/Chromium versions multiple times to verify if the issue is actually a browser bug rather than a bug in our product’s code.
That’s why I wanted to write the process down with all relative resources, so I don’t have to look it up all the time.
What is bisecting?
Bisecting means dividing something into two parts. And is exactly what
git bisectand binary search do.
Chromium has a python script for bisecting in the repository. We just need to download it – tools/bisect-build.py. And it requires Python 3 to work.
More info and examples are in this guide: Bisect builds.
2. Finding a version range
For any bisecting we need to have a ref of one good and one bad revision. In most cases the bad one is going to be the current stable version that we or our customers use. We can look it up in chrome://version. For example:
83.0.4103.61. Unfortunately this is not what the tool expects, and we need to convert semver version number into a
Branch Base Position. And we can do that by using another tool, called chromiumdash.
IMPORTANT: Branch Base Position is not a build number.
Once we have a good and a bad
branch base position we can go straight to bisecting:
$ python bisect-builds.py -a platform -g good-revision -b bad-revision --use-local-cache
After running this command
bisect-builds.py will lunch a browser with a picked version. Quit the browser and this script will prompt you about the results of testing this particular browser build.
Once finished bisect script gives a link to a range of commits included in a broken build.
Unfortunately it’s impossible to go to a by commit level of granularity if you are not a Google employee…
All of the links mentioned above: