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

Issue 919124 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Blocking:
issue 905028



Sign in to add a comment

Filter tryjobs from Gerrit that were terminated because there were no relevant changes

Project Member Reported by shapiroc@chromium.org, Jan 4

Issue description

In the ChromeOS CQ builder model, all individual builders will be instantiated for a given change; however, many builds will be terminated when we realized there are no relevant changes.

These builders should not show up in gerrit under the given cl.

We need some builder status code that triggers this behavior.
 
Components: -Infra>Client>ChromeOS>CI Infra>Client>ChromeOS>CI>Platform
Labels: Pri-1
Status: Available (was: Untriaged)
Cc: tandrii@chromium.org hinoka@chromium.org
Components: Infra>Platform>Buildbucket
Status: Assigned (was: Available)
is it only gerrit, or does it apply to any UI, e.g. CL-centric View on Milo? We can add "hidden" field to go/build.proto or update UIs to respect it.

I assume you'd want to created builds hidden initially, but then builds would unhide themselves. Otherwise devs would be confused by appearing and disappearing builds.
Cc: dpranke@chromium.org jbudorick@chromium.org
John, Dirk, what do you think about this behavior in Chromium case? i.e. for builds where analyze step decided that there is nothing to do
I'm interpreting this as two different things.

First, there's some idea of "terminating" builds and hiding builds that are terminated.  For Chromium (browser), we don't do that and we're not suggesting starting, right?

Second, there's the idea that if we decided that a build had nothing to do (for either browser or OS), we would hide it, right?

In the latter case, I think it seems reasonable to hide the build by default, but to me that seems like a variant of "hide all green builds by default". I'm more comfortable with the latter than I am with "hide builds that didn't do anything". I do agree that "hide builds that didn't do anything" might be useful, though.
i believe terminating here means "early exit": analyze whether a given CL is relevant for the given builder, if not exit. 
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/ios-simulator-cronet/15041
seems to match this description: it has decided that the builder is irrelevant for this CL. I am talking about hiding these builds from Gerrit CL page. So I think what Chromium does and what ChromeOS plans to do is close enough to match a common definition. Then we can map the common definition to the this common feature.

Charles, how many Chrome OS builders we are talking about? Would a more compact/dense presentation of boxes on Gerrit CL solve the problem? Current presentation is admittedly verbose and it is a problem for Chromium too
90+ and growing .... it will be pretty terrible if we can't filter out the irrelevant builds
"Hide all green builds by default" seems like a subset of "hide all irrelevant builds by default" if you allow builds to determine whether or not they're relevant and expose that as a buildbucket property (or however you'd describe it). I tend to agree with Dirk that browser would use "hide all green by default" and wouldn't typically worry about analyze in determining relevancy.

Sign in to add a comment