How to find faulty CL by doing bisect onlinux

[Deepak]

Hi,

A regression get introduced between 40.0.2214.115 and 42.0.2304.0. release versions.
I wanted to know which CL is causing it on linux.

Can some one please share the steps and how I will find that CL.

Thanks
Deepak

[Paweł Hajdan, Jr.]

There's not much to it beyond git bisect.

Please make sure to read http://www.chromium.org/developers/how-tos/get-the-code/working-with-release-branches .

Feel free to post more questions if you encounter specific issues trying to perform the bisect.

Paweł

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Primiano Tucci]

src/tools/bisect-builds.py and git-bisect are your friends here.

My suggestion is to first identify the build which introduced the regression using src/tools/bisect-builds.py, this will avoid you a lot of rebuilds.

Once you narrow the range down to two daily branches (say, for instance, GOOD: 2280 BAD:2281) you will have three options

1 Most likely) the regression is in trunk between the 2280 branch-point and the 2281 branch-point. In this case you want to run a git bisect between $(git merge-base origin/master remotes/branch-heads/2280) and $(git merge-base origin/master remotes/branch-heads/2281). Remember to always gclient sync on any step of the bisect.

2) Less likely: the regression was introduced on the 2281 release branch. In which case, it's going be one of the cl in the range $(git merge-base origin/master remotes/branch-heads/2281)..origin/master remotes/branch-heads/2281.

The tricky part here is that you cannot build release branches (so you can't just git bisect there). Hopefully there won't be that many cherry-picked CLs on the release branch, so it should be easy to spot the offending CL by eye. If you really need to build, you will need to take a release tag for 2280 (e.g. 42.0.2280.0), which is buildable, and gradually cherry pick the CLs from remotes/branch-heads/2281 to find the offending one.

3) Extremely unlikely: the regression was fixed only on the 2280 branch and was-re-regressed on trunk after the 2280 branch point. Bisect here will be similar to 2281.

--

[Egor Pasko]

On Wed, Feb 25, 2015 at 12:43 PM, Primiano Tucci <prim...@chromium.org> wrote:

src/tools/bisect-builds.py and git-bisect are your friends here.

My suggestion is to first identify the build which introduced the regression using src/tools/bisect-builds.py, this will avoid you a lot of rebuilds.

Once you narrow the range down to two daily branches (say, for instance, GOOD: 2280 BAD:2281) you will have three options

1 Most likely) the regression is in trunk between the 2280 branch-point and the 2281 branch-point. In this case you want to run a git bisect between $(git merge-base origin/master remotes/branch-heads/2280) and $(git merge-base origin/master remotes/branch-heads/2281). Remember to always gclient sync on any step of the bisect.

2) Less likely: the regression was introduced on the 2281 release branch. In which case, it's going be one of the cl in the range $(git merge-base origin/master remotes/branch-heads/2281)..origin/master remotes/branch-heads/2281.

The tricky part here is that you cannot build release branches (so you can't just git bisect there). Hopefully there won't be that many cherry-picked CLs on the release branch, so it should be easy to spot the offending CL by eye. If you really need to build, you will need to take a release tag for 2280 (e.g. 42.0.2280.0), which is buildable, and gradually cherry pick the CLs from remotes/branch-heads/2281 to find the offending one.

I did not know that release branches are not buildable for linux builds. Why is that?

 

3) Extremely unlikely: the regression was fixed only on the 2280 branch and was-re-regressed on trunk after the 2280 branch point. Bisect here will be similar to 2281.

On Wed, Feb 25, 2015 at 5:19 AM, Deepak <deep...@samsung.com> wrote:

Hi,

A regression get introduced between 40.0.2214.115 and 42.0.2304.0. release versions.
I wanted to know which CL is causing it on linux.

Can some one please share the steps and how I will find that CL.

Thanks
Deepak

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Primiano Tucci]

I did not know that release branches are not buildable for linux builds. Why is that?

The reason lies in the DEPS file and is not platform-specific. There is a strong difference between refs/branch-heads/2311/DEPS (the release branch) and  42.0.2311.0/DEPS (the tag) even if the rest of the code between the release branch and the release tag for the main project is the same.

DEPS in a release branch (branch-heads/NNNN) is just the copy of whatever was the state of DEPS at the time of the branch point. That file is meaningless (actually, misleading), as it doesn't point to the release branches of blink, v8 as you would expect.

The right DEPS for release branches lives into an internal repository. That repo is not accessible outside of Google, that's why I said "you cannot build release branches".

Instead, DEPS in a release tag (e.g. 42.0.2311.0/DEPS) is what you would expect: it contains all the references to the release branches and therefore coherently binds (code for for main project on a release branch) with (code of subprojects on their release branches).

The piece of magic which makes this happen in release tags are those "Publish DEPS for Chromium w.x.y.z" commits which are on the tip of each tag.