Allow a single trybot to mirror multiple waterfall bots.

Allow a single trybot to mirror multiple waterfall bots.

This formalizes a mastername/buildername pair into a "bot
description" (bot_desc), and allows multiple such descriptions to be
passed in to key APIs in api.chromium_tests.

For these APIs, the "mastername" and "buildername" arguments have been
replaced with a "bot_desc" argument. For most callers of
api.chromium_tests, the appropriate argument is created by calling
api.chromium_tests.create_bot_desc, passing in the mastername and
buildername.

The chromium_trybot recipe, however, now allows a trybot to refer to a
list of dictionaries containing these properties, not just a single
dictionary.

New tests have been added which currently work with an imaginary builder
and tester. This is required during the transition of the GPU bots to
the Chromium recipe to avoid accidentally picking up tests out of the
src-side test specs before we're ready. After the transition is
complete, the fake names will replaced with real ones.

BUG=542370

[Ken Russell (switch to Gerrit), 2016-01-09 06:46:05]

kbr@chromium.org changed reviewers:
+ iannucci@chromium.org, luqui@chromium.org, phajdan.jr@chromium.org,
sergeyberezin@chromium.org, sergiyb@chromium.org, tandrii@chromium.org

[Ken Russell (switch to Gerrit), 2016-01-09 06:46:06]

Hi all,

Here is a revised version of the earlier CL allowing a single trybot to mirror
multiple waterfall bots (from different waterfalls). It uses Sergey's suggestion
to just support lists of bots in trybots.py. See the modification there for the
new syntax.

I've done more testing on it than the earlier CL and am pretty sure it is
working as expected.

This depends on the BotConfigAndTestDB CL. I'll hold off landing that until you
all have a chance to look at this and comment.

Thanks. Not necessary to review this over the weekend or anything; we can resume
on Monday.

[Paweł Hajdan Jr., 2016-01-11 18:41:11]

Just a high-level review: I haven't reviewed every line yet.

I could finish rewriting this to a production-ready state if you prefer.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:85: def
normalize_bot_descs(self, bot_descs):
Why do we need this? It's not a very strong preference, but in general I dislike
APIs that accept different formats and "guess" things or try to provide
convenience. WDYT?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:127:
bot_configs[0].get('buildspec_version'))
Shouldn't we check that 'buildspec_version' is consistent across bot configs?

Here's an idea: we can do that while getting the value, i.e. instead of
verifying things and then manually dereferencing [0], have the getter also
verify consistency. Example: get_property_from_bot_configs(bot_configs,
'buildspec_version'), and it'd also internally verify consistency. WDYT?

Main rationale is to make it difficult to forget verifying consistency.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:157: # This code path hasn't
been generalized yet for a trybot that
Why not a TODO? Also applies to other places which haven't been converted.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:182: master_dict =
self.builders.get(bot_desc[0]['mastername'], {})
Why don't we also ensure consistency here?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:450: # The incoming
'override_tests' must be reset during the second
Why don't we override tests at the end?

The current logic doesn't seem to _add_ tests, but _replace_ them.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/trybots.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/trybots.py:266:
'linux_chromium_rel_ng': [
Whoa - can we experiment with an experimental builder, not main production
builder?

[Ken Russell (switch to Gerrit), 2016-01-11 22:54:01]

Pawel, yes, I would really appreciate it if you would pick up this CL and get it
landed in the form you think is appropriate. Please see below for a couple of
replies to your review feedback.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:85: def
normalize_bot_descs(self, bot_descs):
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Why do we need this? It's not a very strong preference, but in general I
dislike
> APIs that accept different formats and "guess" things or try to provide
> convenience. WDYT?

chromium_trybot.py fetches the entry for a tryserver from trybots.py's
dictionaries, and that entry might be either a dictionary containing
"mastername" and "buildername" properties, or a list of such dictionaries.

We could of course change the required syntax in trybots.py, but that seems like
a fairly "noisy" change not adding a lot of value. It seems to me that if both
syntaxes have to be required, then we might as well add a helper function which
takes care of it. I don't have a strong opinion though.

(There's also an issue when trybots.py's data structures are frozen, and needing
to discover that the lists/dictionaries are still valid inputs.)

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:127:
bot_configs[0].get('buildspec_version'))
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Shouldn't we check that 'buildspec_version' is consistent across bot configs?

Probably, or at least possibly. I didn't know what buildspec_version did.

> Here's an idea: we can do that while getting the value, i.e. instead of
> verifying things and then manually dereferencing [0], have the getter also
> verify consistency. Example: get_property_from_bot_configs(bot_configs,
> 'buildspec_version'), and it'd also internally verify consistency. WDYT?
> 
> Main rationale is to make it difficult to forget verifying consistency.

That sounds like a good idea.

When doing this, though, keep in mind that not all of the properties will be the
same across all of the bot_configs. chromium_apply_config and
gclient_apply_config are two that are important to accumulate across the
bot_configs.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:157: # This code path hasn't
been generalized yet for a trybot that
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Why not a TODO? Also applies to other places which haven't been converted.

Yes, these should have TODOs.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:182: master_dict =
self.builders.get(bot_desc[0]['mastername'], {})
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Why don't we also ensure consistency here?

No good reason not to. This query would be a little different from the others,
since it'd be ensuring consistency across the master_dictionaries, rather than
the bot_configs.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:450: # The incoming
'override_tests' must be reset during the second
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Why don't we override tests at the end?
> 
> The current logic doesn't seem to _add_ tests, but _replace_ them.

Good point; that's probably the correct thing to do according to how this code
works.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/trybots.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/trybots.py:266:
'linux_chromium_rel_ng': [
On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> Whoa - can we experiment with an experimental builder, not main production
> builder?

Sure, that'd be fine, though I think some test expectation suppressions in the
masters_recipe_test would still be needed. I don't know how to set up a new
tryserver from scratch and don't have the time to do so -- to be honest I think
this change to linux_chromium_rel_ng is not that intrusive and that it isn't
worth the extra day or so to bring up a new tryserver to experiment with.

The planned steps for this conversion were:

1. Get this CL working and landed.
2. Finish converting the chromium.gpu.fyi waterfall to the Chromium recipe.
(Working on this now)
3. Switch the chromium.gpu waterfall to the Chromium recipe. This should be easy
once (2) is done because all of the test targets will already have been tested
on all of the platforms.
4. Make a tiny change to both trybots.py and chromium_trybot.py to stop manually
adding the GPU tests to the bots with enable_gpu_tests set, and instead pick up
the tests from this file (and the associated src-side JSON files.)

I expect that (4) might need to be reverted and re-landed a couple of times, but
hopefully not.

Once (4) has stuck, the GPU recipe will be deleted.

I was hoping to have all of this done this week.

[Sergey Berezin, 2016-01-12 01:44:23]

Overall it looks good modulo some nits and comments. My biggest concern is
touching linux_chromium_rel_ng - let's use a test trybot for that.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (left):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:21: 
nit: please keep 2 blank lines: we separate most top-level entries in Python
files by 2 blank lines.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:85: def
normalize_bot_descs(self, bot_descs):
On 2016/01/11 22:54:01, Ken Russell wrote:
> On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> > Why do we need this? It's not a very strong preference, but in general I
> dislike
> > APIs that accept different formats and "guess" things or try to provide
> > convenience. WDYT?
> 
> chromium_trybot.py fetches the entry for a tryserver from trybots.py's
> dictionaries, and that entry might be either a dictionary containing
> "mastername" and "buildername" properties, or a list of such dictionaries.
> 
> We could of course change the required syntax in trybots.py, but that seems
like
> a fairly "noisy" change not adding a lot of value. It seems to me that if both
> syntaxes have to be required, then we might as well add a helper function
which
> takes care of it. I don't have a strong opinion though.
> 
> (There's also an issue when trybots.py's data structures are frozen, and
needing
> to discover that the lists/dictionaries are still valid inputs.)

This is per my request in the original CL to keep the API backwards compatible.
This code would allow keeping all the 1.5 gazillion configs as they are.
Migrating them all to the new format can be delayed to later CLs, if at all
necessary.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:116: will be pulled from
multiple testers.
The docstring doesnt' make sense to me. It appears you are describing the return
result options, but it doesn't really apply to this method.

Also, if we are standardizing on a list of dicts, why not return a normalized
form?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:151:
**bot_configs[0].get('gclient_config_kwargs', {}))
Should *_kwargs properties also be checked for being the same, since you'd get
them only from configs[0]?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:153: if 'android_config' in
bot_configs[0]:
nit: perhaps, more generally:

  if any('android_config' in bc for bc in bot_configs):
    # Move this up, since 'android_config' may not be present in [0].
    assert len(bot_configs) == 1
    # the rest of the code

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:161: if 'amp_config' in
bot_configs[0]:
nit: same generalization as above.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:186: if
bot_configs[0].get('goma_canary'):
nit: same generalization as above.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:192: bot_type =
override_bot_type or bot_configs[0].get('bot_type',
nit: move inside the 'if'. This var is only used inside the conditional, and now
it also doesn't make sense outside without the check for len(bot_configs) == 1.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:195: if
bot_configs[0].get('set_component_rev'):
nit: same generalization as above.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:308: and
bot_configs[0].get('bot_type') == 'builder'
nit: perhaps, also generalize as above?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:530:
bot_desc[0]['mastername'], bot_desc[0]['buildername'],
Shouldn't we compile for all bot_descs? E.g. this would miss GPU builder,
wouldn't it?

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/trybots.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/trybots.py:266:
'linux_chromium_rel_ng': [
On 2016/01/11 22:54:01, Ken Russell wrote:
> On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> > Whoa - can we experiment with an experimental builder, not main production
> > builder?
> 
> Sure, that'd be fine, though I think some test expectation suppressions in the
> masters_recipe_test would still be needed. I don't know how to set up a new
> tryserver from scratch and don't have the time to do so -- to be honest I
think
> this change to linux_chromium_rel_ng is not that intrusive and that it isn't
> worth the extra day or so to bring up a new tryserver to experiment with.
> 
> The planned steps for this conversion were:
> 
> 1. Get this CL working and landed.
> 2. Finish converting the chromium.gpu.fyi waterfall to the Chromium recipe.
> (Working on this now)
> 3. Switch the chromium.gpu waterfall to the Chromium recipe. This should be
easy
> once (2) is done because all of the test targets will already have been tested
> on all of the platforms.
> 4. Make a tiny change to both trybots.py and chromium_trybot.py to stop
manually
> adding the GPU tests to the bots with enable_gpu_tests set, and instead pick
up
> the tests from this file (and the associated src-side JSON files.)
> 
> I expect that (4) might need to be reverted and re-landed a couple of times,
but
> hopefully not.
> 
> Once (4) has stuck, the GPU recipe will be deleted.
> 
> I was hoping to have all of this done this week.

+1 to Pawel's concern - let's not mess with a production builder. A single
mistake will make all 1K devs suffer.

What you can do easily instead is to create a new trybot which is a duplicate of
linux_chromium_rel_ng, but is not run by CQ. Add GPU builder/tester to it, and
add the builder to 10% CQ. This way, you'll have all the pieces tested
end-to-end, and have a steady stream of builds going without disrupting anybody
else's work.

You can add a new builder config to the master right away, and request the
master restart tonight. The builder will not be functional until this CL lands,
but it's OK, and will unblock your further testing. No new tryserver setup
needed.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipes/chrom...
File scripts/slave/recipes/chromium_trybot.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipes/chrom...
scripts/slave/recipes/chromium_trybot.py:321: if
bot_descs[0].get('analyze_mode') == 'compile':
nit: this makes the [0]'th configuration "special", supplying extra parameters
for the trybot as a whole. Is this intentional?

[Ken Russell (switch to Gerrit), 2016-01-12 05:35:51]

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (left):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:21: 
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: please keep 2 blank lines: we separate most top-level entries in Python
> files by 2 blank lines.

Sorry, that was an accident.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/api.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:116: will be pulled from
multiple testers.
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> The docstring doesnt' make sense to me. It appears you are describing the
return
> result options, but it doesn't really apply to this method.

That's true. I should have documented the "bot_desc" argument in the subsequent
APIs instead; however, several of them didn't have docs in the first place and I
wasn't sure how to document them.

> Also, if we are standardizing on a list of dicts, why not return a normalized
> form?

That's a fair point.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:151:
**bot_configs[0].get('gclient_config_kwargs', {}))
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> Should *_kwargs properties also be checked for being the same, since you'd get
> them only from configs[0]?

Good point. Yes, I think so. (Is this property even used any more? It doesn't
show up in code search.)

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:153: if 'android_config' in
bot_configs[0]:
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: perhaps, more generally:
> 
>   if any('android_config' in bc for bc in bot_configs):
>     # Move this up, since 'android_config' may not be present in [0].
>     assert len(bot_configs) == 1
>     # the rest of the code

Good point.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:161: if 'amp_config' in
bot_configs[0]:
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: same generalization as above.

Agree.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:186: if
bot_configs[0].get('goma_canary'):
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: same generalization as above.

Acknowledged.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:192: bot_type =
override_bot_type or bot_configs[0].get('bot_type',
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: move inside the 'if'. This var is only used inside the conditional, and
now
> it also doesn't make sense outside without the check for len(bot_configs) ==
1. 

Good point.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:195: if
bot_configs[0].get('set_component_rev'):
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: same generalization as above.

Acknowledged.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:308: and
bot_configs[0].get('bot_type') == 'builder'
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: perhaps, also generalize as above?

Maybe. Since this is a hack it might be best to touch it as little as possible.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/api.py:530:
bot_desc[0]['mastername'], bot_desc[0]['buildername'],
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> Shouldn't we compile for all bot_descs? E.g. this would miss GPU builder,
> wouldn't it?

At first glance it didn't seem necessary to generalize compile_specific_targets
in that way -- the compile_targets have already been assembled, and it looked
like the only thing the mastername and buildername were being used for was
constructing the URL for archiving the build. I might be wrong about that,
though.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
File scripts/slave/recipe_modules/chromium_tests/trybots.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipe_module...
scripts/slave/recipe_modules/chromium_tests/trybots.py:266:
'linux_chromium_rel_ng': [
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> On 2016/01/11 22:54:01, Ken Russell wrote:
> > On 2016/01/11 18:41:11, Paweł Hajdan Jr. wrote:
> > > Whoa - can we experiment with an experimental builder, not main production
> > > builder?
> > 
> > Sure, that'd be fine, though I think some test expectation suppressions in
the
> > masters_recipe_test would still be needed. I don't know how to set up a new
> > tryserver from scratch and don't have the time to do so -- to be honest I
> think
> > this change to linux_chromium_rel_ng is not that intrusive and that it isn't
> > worth the extra day or so to bring up a new tryserver to experiment with.
> > 
> > The planned steps for this conversion were:
> > 
> > 1. Get this CL working and landed.
> > 2. Finish converting the chromium.gpu.fyi waterfall to the Chromium recipe.
> > (Working on this now)
> > 3. Switch the chromium.gpu waterfall to the Chromium recipe. This should be
> easy
> > once (2) is done because all of the test targets will already have been
tested
> > on all of the platforms.
> > 4. Make a tiny change to both trybots.py and chromium_trybot.py to stop
> manually
> > adding the GPU tests to the bots with enable_gpu_tests set, and instead pick
> up
> > the tests from this file (and the associated src-side JSON files.)
> > 
> > I expect that (4) might need to be reverted and re-landed a couple of times,
> but
> > hopefully not.
> > 
> > Once (4) has stuck, the GPU recipe will be deleted.
> > 
> > I was hoping to have all of this done this week.
> 
> +1 to Pawel's concern - let's not mess with a production builder. A single
> mistake will make all 1K devs suffer.
> 
> What you can do easily instead is to create a new trybot which is a duplicate
of
> linux_chromium_rel_ng, but is not run by CQ. Add GPU builder/tester to it, and
> add the builder to 10% CQ. This way, you'll have all the pieces tested
> end-to-end, and have a steady stream of builds going without disrupting
anybody
> else's work.
> 
> You can add a new builder config to the master right away, and request the
> master restart tonight. The builder will not be functional until this CL
lands,
> but it's OK, and will unblock your further testing. No new tryserver setup
> needed.

OK. Agree it's much better to get the entire system running end-to-end. The new
trybot would have the advantage that it wouldn't be listed in the
CHROMIUM_GPU_DIMENSION_SETS in chromium_trybot.py.

I would really appreciate help getting all of this set up. Since Pawel
volunteered to carry forward this CL I'd appreciate it if the experimental setup
could also be handled by him and the rest of the CQ team.

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipes/chrom...
File scripts/slave/recipes/chromium_trybot.py (right):

https://codereview.chromium.org/1574433004/diff/1/scripts/slave/recipes/chrom...
scripts/slave/recipes/chromium_trybot.py:321: if
bot_descs[0].get('analyze_mode') == 'compile':
On 2016/01/12 01:44:23, Sergey Berezin wrote:
> nit: this makes the [0]'th configuration "special", supplying extra parameters
> for the trybot as a whole. Is this intentional?

I didn't understand this code nor the ramifications of making it iterate over
all the bot_descs so leaving it checking the 0'th one seemed safest. I probably
should have added an assert.

Looking more deeply, this zaps all of the tests, and is used only on the
compile-only tryservers. I guess it makes sense to take the union of the
settings in all of the bot_descs.

[Paweł Hajdan Jr., 2016-01-12 12:25:08]

Uploaded initial CL: https://codereview.chromium.org/1575393002

[Ken Russell (switch to Gerrit), 2016-01-12 18:50:03]

I'm going to close this to make it clear I'm not pursuing it -- Pawel and I
talked offline and he's going to independently land a series of CLs to get to
this sort of functionality, but in a more robust manner.

[Ken Russell (switch to Gerrit), 2016-01-12 18:50:07]

Description was changed from

==========
Allow a single trybot to mirror multiple waterfall bots.

This formalizes a mastername/buildername pair into a "bot
description" (bot_desc), and allows multiple such descriptions to be
passed in to key APIs in api.chromium_tests.

For these APIs, the "mastername" and "buildername" arguments have been
replaced with a "bot_desc" argument. For most callers of
api.chromium_tests, the appropriate argument is created by calling
api.chromium_tests.create_bot_desc, passing in the mastername and
buildername.

The chromium_trybot recipe, however, now allows a trybot to refer to a
list of dictionaries containing these properties, not just a single
dictionary.

New tests have been added which currently work with an imaginary builder
and tester. This is required during the transition of the GPU bots to
the Chromium recipe to avoid accidentally picking up tests out of the
src-side test specs before we're ready. After the transition is
complete, the fake names will replaced with real ones.

BUG=542370
==========

to

==========
Allow a single trybot to mirror multiple waterfall bots.

This formalizes a mastername/buildername pair into a "bot
description" (bot_desc), and allows multiple such descriptions to be
passed in to key APIs in api.chromium_tests.

For these APIs, the "mastername" and "buildername" arguments have been
replaced with a "bot_desc" argument. For most callers of
api.chromium_tests, the appropriate argument is created by calling
api.chromium_tests.create_bot_desc, passing in the mastername and
buildername.

The chromium_trybot recipe, however, now allows a trybot to refer to a
list of dictionaries containing these properties, not just a single
dictionary.

New tests have been added which currently work with an imaginary builder
and tester. This is required during the transition of the GPU bots to
the Chromium recipe to avoid accidentally picking up tests out of the
src-side test specs before we're ready. After the transition is
complete, the fake names will replaced with real ones.

BUG=542370
==========