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

Issue 695105 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Blocked on:
issue 833946



Sign in to add a comment

be able to trigger tryjobs corresponding to all main waterfall builders everywhere

Project Member Reported by primiano@chromium.org, Feb 22 2017

Issue description

Copy/pasting from: [infra-dev] Can we haz optional git cl try argument to match our waterfalls?

Background story:
I submitted recently a change to fix CHECK(s) in base/logging.h here to improve crash reporting accuracy ( crbug.com/664209 ) while avoiding perf and binary regressions.

I found myself spending 2+ eng days to deal with the fallout after the CL landed because of the various bot not matched by the CQ. Concrete examples:
1. https://codereview.chromium.org/2706453004/  reverted because broke NaCl build in CrOS bots *
2.  crbug.com/694655  -> broke base_unittests on iOS
3.  crbug.com/694652  -> broke sandbox_tests on CrOS bots *
And something tells that more will come from official builders in a while.

* In both cases, the breakage also affected Linux desktop builds with is_official_build = true. I guess there are just no bots, neither in CQ or on the main waterfall, that build with is_official other than those CrOS ones.

Now, I understand perfectly that:
- this sort of CL is objectively an outlier in terms of breakage risk w.r.t. the average CLs we have in our project.
- we can't match all the bots config on the CQ because there are resource constraints and we can't make CQ too slow for these issues

Proposal:
my life would have been way easier if I could have run something like git cl try --all, where --all triggers try jobs that match all the bots that we have out there, even if that takes forever.
I would have been way happier to wait 24 hours for the try --all results and deal with all the failures in one go, rather than having to deal with a different fallout every day.

 
Cc: aga...@chromium.org andyb...@chromium.org
Components: Infra>Codereview>Gerrit
Cc: tansell@chromium.org mcgreevy@chromium.org

Comment 4 by aga...@chromium.org, Feb 27 2017

Components: -Infra>Client -Infra>Codereview>Gerrit Infra>Platform>Buildbot>TryServer
Summary: be able to trigger tryjobs corresponding to all main waterfall builders everywhere (was: add optional --all arg to git cl try to match coverage of the various waterfalls)
Adding this option would require that we uniformly have trybots that match our waterfalls. This does not exist, no matter how much I wish it did. This isn't so much a feature request for git-cl as it is for the tryservers themselves.
@agable - it seems like one way we could do this would be to just curate a list somewhere, like we do with the CQ ones. Another way to do this would be to do something like wildcard tryserver.chromium.*:* or some such. However, it seems like maybe you have something else in mind that led to your comment?

Comment 6 by aga...@chromium.org, Feb 28 2017

The issue is that we don't *have* trybots corresponding to all continuous bots. There's a centi-bug on file for that somewhere that I think is assigned to Pawel.

For example, in this particular bug, the breakage was on bots with is_official_build = true. It's not that we don't have a flag for triggering trybots that do official builds; it's that we don't have trybots that pass is_official_build=true at all.

I think we fundamentally need to get away from the distinction between "trybots" and "waterfall bots". They need to be exactly the same thing, all the time, always. They just need to be in 3 network-isolated pools: 1 for untrusted code (try jobs), one for trusted code (CI), and one for releases. But all the same configurations should be available in all of them, and all configurations should know how to check out a gerrit patch ref instead of tip-of-tree.
It's possible to interpret this request different ways.

I'm interpreting this request to be "please give me a way to trigger all of the existing trybots", which is of course doable today.

You're pointing out that you could interpret this differently, to be "please trigger a tryjob to match every CI builder", which we can't do today since we don't have matching tryjob builders for every CI builder.

It seems to me that we can get what we want by breaking things into two different tasks (and fixing  bug 663060 ) and that wouldn't require agables's fundamental changes, even if they might be a good idea.

But I'll let primiano decide what he's asking for :).
Oops, just realized that my "--all" might have been misleading here.

> I'm interpreting this request to be "please give me a way to trigger all of the existing trybots", which is of course doable today.
> You're pointing out that you could interpret this differently, to be "please trigger a tryjob to match every CI builder"

Agable@ is spot on, I meant definitely the latter. Sorry for the confusion.
Essentially I would like some confidence that a given CL won't be reverted once it lands.
I was assuming that we have matching trybots for every CI config and it was just a matter of picking them, but looks like we don't :(

In lack of this, can we have at least some trybots that builds like official (AFAIK official doesn't require any internal code). That would be a nice approximation.
Components: Infra>Client>Chrome
Somewhat related:  issue 682529  .
Cc: -andyb...@chromium.org iannucci@chromium.org
Status: Available (was: Untriaged)
I think iannucci's led command gets us closer to having this in a generic way.
Issue 681946 has been merged into this issue.

Comment 13 by no...@chromium.org, Jun 17 2018

Components: -Infra>Platform>Buildbot>TryServer Infra>Platform
Labels: -Type-Bug Type-Feature
on the foundation side, we need to ensure that it is easy to define CI-TRY builder pairs. I believe high-level config (issue 833946) addresses that. See https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/1069928/1/lucicfg/test/LUCI.sky#66
that function could also define a try builder (for each CI builder).

another part of work is in recipes, of course.

Comment 14 by no...@chromium.org, Jun 17 2018

Blockedon: 833946
Cc: -iannucci@chromium.org iannu...@google.com

Sign in to add a comment