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

Issue 595091 link

Starred by 1 user
Status: Archived
Owner: ----
Closed: Jul 2017
Cc:
akes...@chromium.org
█ sosa@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

CQ runs don't show when a new chrome has been picked up in list of CLs

Reported by olofj@chromium.org, Mar 15 2016 
The recent introduced failure on an internal CQ was harder to spot where it might have come from due to the fact that the chrome pfq uprevs aren't really listed in the list of CLs (CommitQueueSync stage) that are new in a particular CQ run.

It'd be useful if those were listed in the list of CLs, even if they're not the patched in CLs on that run -- they are a known difference from the run before.

Comment 1 by akes...@chromium.org, Mar 15 2016 

This is somewhat hard to do. Currently, the pfq uprev commits aren't even given gerrit #s. I suppose we could link to the underlying commits on gitles, if we had logic in the master to figure this out.

Using cidb, it should be doable to a master to figure out that the chrome version it was building is different from the one built by the prior cq master, and emit some sort of link. That would only happen on the first build after an uprev though.

Comment 2 by benhenry@chromium.org, Jul 29 2016

Components: -Build Infra>Client>ChromeOS
Project Member

Comment 3 by sheriffbot@chromium.org, Jul 31 2017

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
►

Sign in to add a comment