New issue
Advanced search Search tips

Issue 911152 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

CQ should set Code-Review +1 or -1 in Gerrit

Project Member Reported by bore...@google.com, Dec 3

Issue description

CQ should set Code-Review +1 or -1 in Gerrit

It'd be nice to have a straightforward way for automated processes (eg. autorollers) to know whether the CQ succeeded or failed.  In the past, we parsed the comments added to the CL by the CQ, but that proved to be very fragile.  Currently, we see that the CQ+1 label has been removed, then load all of the tryjobs for the CL and derive success/failure based on tryjob results.  This is fairly complicated, because of the potential presence of experimental tryjobs, trivial patchsets being appended to the CL, etc.  Other projects (eg. Android) have their CI system simply post a label to the CL.  Is there any reason we couldn't do this?
 
Cc: tandrii@chromium.org

I am not sure about setting CR+1/CR-1 but cq.proto has a way to set the name of a cq_verified_label: https://chrome-internal.googlesource.com/infra/infra_internal/+/master/infra_internal/services/cq/cq_client/cq.proto#66

Does not look like this label was ever added to Chromium though.

Also, looks like the support for this label is going away: https://bugs.chromium.org/p/chromium/issues/detail?id=906576 ('deprecate CQ verified label feature')

I suspect this feature can be added once CQ stops using Gerrit labels and has it's own server, which I believe was the long-term plan, Andrii?
Owner: tandrii@chromium.org
Status: Assigned (was: Untriaged)
Exactly what Ravi said. 
What I can add is:
 * CQ server with API isn't as long term any more :) I expect to be working on it in Q1.
 * As for CQ-Verified label, indeed  issue 906576  deleted it (waiting only on release to prod). In 2 years, only 1 project used it, and even then it was me who configured it. However, I may need to bring it back for ChromeOS.

I'll let this bug hang open while we decide the ChromeOS case.

Sign in to add a comment