New issue
Advanced search Search tips

Issue 855177 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Feature



Sign in to add a comment

[iOS Ops] Reorganize the upstream ios-* bot configs for LUCI

Project Member Reported by sergeybe...@chromium.org, Jun 21 2018

Issue description

Filed using go/ios-ops-ticket.

Many of the ios-* builders upstream have been migrated to LUCI, where the concept of a "master" is no longer relevant, and in fact, may be downright confusing. The production (sheriffed) and FYI consoles are now defined by luci-milo.cfg, and are completely independent on the legacy "master" property in the recipe. The consoles IMHO should be defined in a single place, which is luci-milo.cfg; no need to replicate this information by placing builder configs in separate directories.

The proposal in this issue, therefore, is to set the "master" property to a constant value for all the LUCI builders, e.g. to "luci.chromium.ci" (to be consistent with the bucket / pool they run in), and move all the configs to the directory "luci.chromium.ci".

The builders still on buildbot will remain in their corresponding <master-name> directory. In particular, it will be clearer which builders are on LUCI and which are not.

 
I'm wary of doing this on ios and not on other platforms; I don't want us to further diverge here.
This may slightly complicate the cr-buildbucket.cfg builder configs while we're migrating the remaining builders to LUCI, since those should keep their "master" setting consistent with buildbot. Or, we can replicate their configs into luci.chromium.ci and let the LUCI bots always read their configs from that directory. Then, once migrated, the corresponding buildbot master directories can be safely deleted.
Re: #c1 - The ios configs are so different from chromium anyway, I don't really see how it would diverge any more than that. This is simply bringing the existing organization closer to the new reality and reduce the config duplication.

In other words, I don't see divergence as a problem here (it already exists, and this will not have any impact on it - unless I'm missing something, please correct me then). The problem I'm trying to solve here is the unnecessary config duplication, which in a medium-to-long term will result in mismatching configs and a possible confusion.

ios-simulator-cronet is a good living example: its 2 configs already diverged, and it's an "FYI" bot that is also a partially required CQ bot.

Sign in to add a comment