New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 844409 link

Starred by 8 users
Status: Fixed
Owner:
mmoss@chromium.org
Closed: Jul 20
Cc:
█ abdulsyed@chromium.org
ajha@chromium.org
gov...@chromium.org
rsesek@chromium.org
█ amineer@chromium.org
nyerramilli@chromium.org
█ bustamante@chromium.org
ligim...@chromium.org
dpranke@chromium.org
jbudorick@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Branch Base position of chrome versions no longer shows revision number instead shows only 1

Project Member Reported by ajha@chromium.org, May 18 2018 
Chrome Version: 68.0.3434.0
OS: Windows,Mac,Linux

What steps will reproduce the problem?
(1) Launch chrome and go to chrome://version or go to https://omahaproxy.appspot.com/
(2) Check the Revision under chrome version or check the Branch Base Position.

What is the expected result?
> Revision should show up as : Revision	222512a0ce7deab81dad3af945bad2196e8a8838-refs/heads/master@{#555962} or
> Branch Base Position should show up as : 555962

What happens instead?
> Revision shown as : Revision 7adbe707dcd63cd1cdf412180a23dee5abc39a4d-refs/branch-heads/3420@{#1}
> Branch Base Position shown as : 1 


Note:
=====
1. Behavior seems to have changed b/w 68.0.3419.0 and 68.0.3420.0.
2. Running the per revision bisect for this range, weirdly invokes all the old i.e. M-53/M-54 builds.
3. This creates hassle in CL verification as we rely on canary revision number to compare with the bugdroid revision and verify whether build contains the fix or not. Workaround of checking revisions from the omhaproxy changelog takes more time than directly checking revision under chrome://version or under Version Information of the Omahaproxy page.

4. Looks like all the canary versions since 68.0.3420.0 are branching the canary version as seeing "Update DEPS for 3420 branching" in the omaha changelog.

Michael@: Could you please take a look at this and confirm whether something changed recently and this is WAI?

Based on the timeframe of first time this showed up i.e. May 4th suspecting this could be rooted to work in Issue 825063.

Comment 1 by mmoss@chromium.org, May 18 2018

Cc: rsesek@chromium.org
From email discussion:

On Wed, May 16, 2018 at 2:21 PM, Robert Sesek <rsesek@google.com> wrote:
I think this is related to the new buildspec changes that +Michael Moss made. Looking at the branch_base_commit for today's canary, for example, points to https://chromium.googlesource.com/chromium/src/+/3ea42fd0c5a16abfa161147ccd459345055c479a. The parent of that commit is https://chromium.googlesource.com/chromium/src/+/689c2c26c46f3dfb040f465f09189b6e8da49261, which has a branch position of refs/branch-heads/3432@{#1}. I think previously that "Update DEPS for 3432 branching" commit didn't exist, so we probably fell back to the parent revision's position.

----

Yeah, the "Update DEPS" commit is new, although note that it might go away again at some point, once we have the branch autorollers working. I'm not sure exactly what the code is doing, but what it probably should do is something like:

Grab the release commit and
1) If it has "Cr-Branched-From", use that.
2) if it has "Cr-Commit-Position", use that.
3) if it has neither, grab the parent commit and return to step 1).

That should work for both the current and previous branch configs, as well as the ideal future config where the .0 release is just a tag on an existing trunk commit (because no DEPS need to be modified because they are already fully pinned by autorollers on trunk and branches).

Comment 2 by rsesek@chromium.org, May 18 2018

Components: Infra>OmahaProxy

Comment 3 by rsesek@chromium.org, May 18 2018

Components: -Infra>Client>Chrome>Release

Comment 4 by rsesek@chromium.org, Jun 8 2018

Cc: jbudorick@chromium.org dpranke@chromium.org amineer@chromium.org
 Issue 851145  has been merged into this issue.

Comment 5 by rsesek@chromium.org, Jun 8 2018

Labels: -Restrict-View-Google

Comment 6 by dmazz...@chromium.org, Jun 20 2018 

Issue 854670 has been merged into this issue.

Comment 7 by joshbruning@google.com, Jul 10 

FYI: Looking forward to seeing a fix here prior to Chrome 68 stable (I think ~2 weeks?); web test automation validating Google products relies upon https://omahaproxy.appspot.com/all.json for accurate information.

Comment 8 by mmoss@chromium.org, Jul 12 

Issue 640274 has been merged into this issue.
Project Member

Comment 9 by bugdroid1@chromium.org, Jul 20 

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/9ed80b1c7bbb29fbac1c5f1ff4134a451fdccc87

commit 9ed80b1c7bbb29fbac1c5f1ff4134a451fdccc87
Author: Michael Moss <mmoss@google.com>
Date: Fri Jul 20 18:58:47 2018

Comment 10 by mmoss@chromium.org, Jul 20

Status: Fixed (was: Assigned)
►

Sign in to add a comment