Skia bots: use deps_os = 'all'

Skia bots: use deps_os = 'all'

BUG=

[borenet, 2016-03-02 16:28:04]

The CQ bit was checked by borenet@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-03-02 16:28:16]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1750853005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1750853005/1

[commit-bot: I haz the power, 2016-03-02 16:31:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-02 16:31:48]

Dry run: This issue passed the CQ dry run.

[borenet, 2016-03-02 16:32:48]

borenet@google.com changed reviewers:
+ bsalomon@google.com, rmistry@google.com

[borenet, 2016-03-02 16:32:49]

Okay, I think this will do it, though I'm not positive since it doesn't match
the syntax I've seen before.

[bsalomon, 2016-03-02 16:35:50]

I think we want deps_os = 'all' not 'llvm'. 'all' is a magic value that matches
all future values we might add (e.g. if we put angle behind deps_os = 'angle').

[mtklein, 2016-03-02 16:38:23]

mtklein@google.com changed reviewers:
+ mtklein@google.com

[mtklein, 2016-03-02 16:38:23]

Can we not get down the same code path that --deps=all does?

  --deps=OS_LIST        override deps for the specified (comma-separated)
                        platform(s); 'all' will process all deps_os references

[bsalomon, 2016-03-02 17:02:05]

On 2016/03/02 16:38:23, mtklein wrote:
> Can we not get down the same code path that --deps=all does?
> 
>   --deps=OS_LIST        override deps for the specified (comma-separated)
>                         platform(s); 'all' will process all deps_os references

Alternatively, maybe just the SAN bots should opt in to deps_os = 'llvm'?

[mtklein, 2016-03-02 17:08:11]

On 2016/03/02 17:02:05, bsalomon wrote:
> On 2016/03/02 16:38:23, mtklein wrote:
> > Can we not get down the same code path that --deps=all does?
> > 
> >   --deps=OS_LIST        override deps for the specified (comma-separated)
> >                         platform(s); 'all' will process all deps_os
references
> 
> Alternatively, maybe just the SAN bots should opt in to deps_os = 'llvm'?

Let's keep it simple until some bot starts complaining about sync times...

[bsalomon, 2016-03-02 17:10:38]

On 2016/03/02 17:08:11, mtklein wrote:
> On 2016/03/02 17:02:05, bsalomon wrote:
> > On 2016/03/02 16:38:23, mtklein wrote:
> > > Can we not get down the same code path that --deps=all does?
> > > 
> > >   --deps=OS_LIST        override deps for the specified (comma-separated)
> > >                         platform(s); 'all' will process all deps_os
> references
> > 
> > Alternatively, maybe just the SAN bots should opt in to deps_os = 'llvm'?
> 
> Let's keep it simple until some bot starts complaining about sync times...

Was just thinking that might be simpler if there is no equiv to 'all' outside of
the command line.

[borenet, 2016-03-02 17:24:15]

On 2016/03/02 17:10:38, bsalomon wrote:
> On 2016/03/02 17:08:11, mtklein wrote:
> > On 2016/03/02 17:02:05, bsalomon wrote:
> > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > Can we not get down the same code path that --deps=all does?
> > > > 
> > > >   --deps=OS_LIST        override deps for the specified
(comma-separated)
> > > >                         platform(s); 'all' will process all deps_os
> > references
> > > 
> > > Alternatively, maybe just the SAN bots should opt in to deps_os = 'llvm'?
> > 
> > Let's keep it simple until some bot starts complaining about sync times...
> 
> Was just thinking that might be simpler if there is no equiv to 'all' outside
of
> the command line.

I can't specify flags directly in the recipe.  I can change this to "all" but
it's hard to test without any deps_os entries in Skia.  If we land your DEPS
change, the worst that happens is that the *SAN bots fail for a while, right?

[mtklein, 2016-03-02 17:26:10]

On 2016/03/02 17:24:15, borenet wrote:
> On 2016/03/02 17:10:38, bsalomon wrote:
> > On 2016/03/02 17:08:11, mtklein wrote:
> > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > Can we not get down the same code path that --deps=all does?
> > > > > 
> > > > >   --deps=OS_LIST        override deps for the specified
> (comma-separated)
> > > > >                         platform(s); 'all' will process all deps_os
> > > references
> > > > 
> > > > Alternatively, maybe just the SAN bots should opt in to deps_os =
'llvm'?
> > > 
> > > Let's keep it simple until some bot starts complaining about sync times...
> > 
> > Was just thinking that might be simpler if there is no equiv to 'all'
outside
> of
> > the command line.
> 
> I can't specify flags directly in the recipe.  I can change this to "all" but
> it's hard to test without any deps_os entries in Skia.  If we land your DEPS
> change, the worst that happens is that the *SAN bots fail for a while, right?

Yep.  We'd want to watch the gclient sync logs very carefully though... most
(probably all) of the *SAN bots already have LLVM+co checked out, so if we fail
here it may look like we succeeded.

[borenet, 2016-03-02 17:31:52]

On 2016/03/02 17:26:10, mtklein wrote:
> On 2016/03/02 17:24:15, borenet wrote:
> > On 2016/03/02 17:10:38, bsalomon wrote:
> > > On 2016/03/02 17:08:11, mtklein wrote:
> > > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > > Can we not get down the same code path that --deps=all does?
> > > > > > 
> > > > > >   --deps=OS_LIST        override deps for the specified
> > (comma-separated)
> > > > > >                         platform(s); 'all' will process all deps_os
> > > > references
> > > > > 
> > > > > Alternatively, maybe just the SAN bots should opt in to deps_os =
> 'llvm'?
> > > > 
> > > > Let's keep it simple until some bot starts complaining about sync
times...
> > > 
> > > Was just thinking that might be simpler if there is no equiv to 'all'
> outside
> > of
> > > the command line.
> > 
> > I can't specify flags directly in the recipe.  I can change this to "all"
but
> > it's hard to test without any deps_os entries in Skia.  If we land your DEPS
> > change, the worst that happens is that the *SAN bots fail for a while,
right?
> 
> Yep.  We'd want to watch the gclient sync logs very carefully though... most
> (probably all) of the *SAN bots already have LLVM+co checked out, so if we
fail
> here it may look like we succeeded.

Agreed, although I *think* gclient auto-deletes no-longer-used DEPS.

[borenet, 2016-03-02 17:32:09]

On 2016/03/02 17:31:52, borenet wrote:
> On 2016/03/02 17:26:10, mtklein wrote:
> > On 2016/03/02 17:24:15, borenet wrote:
> > > On 2016/03/02 17:10:38, bsalomon wrote:
> > > > On 2016/03/02 17:08:11, mtklein wrote:
> > > > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > > > Can we not get down the same code path that --deps=all does?
> > > > > > > 
> > > > > > >   --deps=OS_LIST        override deps for the specified
> > > (comma-separated)
> > > > > > >                         platform(s); 'all' will process all
deps_os
> > > > > references
> > > > > > 
> > > > > > Alternatively, maybe just the SAN bots should opt in to deps_os =
> > 'llvm'?
> > > > > 
> > > > > Let's keep it simple until some bot starts complaining about sync
> times...
> > > > 
> > > > Was just thinking that might be simpler if there is no equiv to 'all'
> > outside
> > > of
> > > > the command line.
> > > 
> > > I can't specify flags directly in the recipe.  I can change this to "all"
> but
> > > it's hard to test without any deps_os entries in Skia.  If we land your
DEPS
> > > change, the worst that happens is that the *SAN bots fail for a while,
> right?
> > 
> > Yep.  We'd want to watch the gclient sync logs very carefully though... most
> > (probably all) of the *SAN bots already have LLVM+co checked out, so if we
> fail
> > here it may look like we succeeded.
> 
> Agreed, although I *think* gclient auto-deletes no-longer-used DEPS.

Want to just land the other change and see what happens?

[mtklein, 2016-03-02 17:37:36]

On 2016/03/02 17:32:09, borenet wrote:
> On 2016/03/02 17:31:52, borenet wrote:
> > On 2016/03/02 17:26:10, mtklein wrote:
> > > On 2016/03/02 17:24:15, borenet wrote:
> > > > On 2016/03/02 17:10:38, bsalomon wrote:
> > > > > On 2016/03/02 17:08:11, mtklein wrote:
> > > > > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > > > > Can we not get down the same code path that --deps=all does?
> > > > > > > > 
> > > > > > > >   --deps=OS_LIST        override deps for the specified
> > > > (comma-separated)
> > > > > > > >                         platform(s); 'all' will process all
> deps_os
> > > > > > references
> > > > > > > 
> > > > > > > Alternatively, maybe just the SAN bots should opt in to deps_os =
> > > 'llvm'?
> > > > > > 
> > > > > > Let's keep it simple until some bot starts complaining about sync
> > times...
> > > > > 
> > > > > Was just thinking that might be simpler if there is no equiv to 'all'
> > > outside
> > > > of
> > > > > the command line.
> > > > 
> > > > I can't specify flags directly in the recipe.  I can change this to
"all"
> > but
> > > > it's hard to test without any deps_os entries in Skia.  If we land your
> DEPS
> > > > change, the worst that happens is that the *SAN bots fail for a while,
> > right?
> > > 
> > > Yep.  We'd want to watch the gclient sync logs very carefully though...
most
> > > (probably all) of the *SAN bots already have LLVM+co checked out, so if we
> > fail
> > > here it may look like we succeeded.
> > 
> > Agreed, although I *think* gclient auto-deletes no-longer-used DEPS.
> 
> Want to just land the other change and see what happens?

So,
   1) land other change
   2) hope it breaks *SAN bots
   3) land this change with 'all'
   4) hope it fixes *SAN bots
If not,
   5) reland this change with 'llvm'
   6) be a little sad
?

[borenet, 2016-03-02 17:38:26]

On 2016/03/02 17:37:36, mtklein wrote:
> On 2016/03/02 17:32:09, borenet wrote:
> > On 2016/03/02 17:31:52, borenet wrote:
> > > On 2016/03/02 17:26:10, mtklein wrote:
> > > > On 2016/03/02 17:24:15, borenet wrote:
> > > > > On 2016/03/02 17:10:38, bsalomon wrote:
> > > > > > On 2016/03/02 17:08:11, mtklein wrote:
> > > > > > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > > > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > > > > > Can we not get down the same code path that --deps=all does?
> > > > > > > > > 
> > > > > > > > >   --deps=OS_LIST        override deps for the specified
> > > > > (comma-separated)
> > > > > > > > >                         platform(s); 'all' will process all
> > deps_os
> > > > > > > references
> > > > > > > > 
> > > > > > > > Alternatively, maybe just the SAN bots should opt in to deps_os
=
> > > > 'llvm'?
> > > > > > > 
> > > > > > > Let's keep it simple until some bot starts complaining about sync
> > > times...
> > > > > > 
> > > > > > Was just thinking that might be simpler if there is no equiv to
'all'
> > > > outside
> > > > > of
> > > > > > the command line.
> > > > > 
> > > > > I can't specify flags directly in the recipe.  I can change this to
> "all"
> > > but
> > > > > it's hard to test without any deps_os entries in Skia.  If we land
your
> > DEPS
> > > > > change, the worst that happens is that the *SAN bots fail for a while,
> > > right?
> > > > 
> > > > Yep.  We'd want to watch the gclient sync logs very carefully though...
> most
> > > > (probably all) of the *SAN bots already have LLVM+co checked out, so if
we
> > > fail
> > > > here it may look like we succeeded.
> > > 
> > > Agreed, although I *think* gclient auto-deletes no-longer-used DEPS.
> > 
> > Want to just land the other change and see what happens?
> 
> So,
>    1) land other change
>    2) hope it breaks *SAN bots
>    3) land this change with 'all'
>    4) hope it fixes *SAN bots
> If not,
>    5) reland this change with 'llvm'
>    6) be a little sad
> ?

Yeah, pretty much.

[mtklein, 2016-03-02 17:39:45]

On 2016/03/02 17:38:26, borenet wrote:
> On 2016/03/02 17:37:36, mtklein wrote:
> > On 2016/03/02 17:32:09, borenet wrote:
> > > On 2016/03/02 17:31:52, borenet wrote:
> > > > On 2016/03/02 17:26:10, mtklein wrote:
> > > > > On 2016/03/02 17:24:15, borenet wrote:
> > > > > > On 2016/03/02 17:10:38, bsalomon wrote:
> > > > > > > On 2016/03/02 17:08:11, mtklein wrote:
> > > > > > > > On 2016/03/02 17:02:05, bsalomon wrote:
> > > > > > > > > On 2016/03/02 16:38:23, mtklein wrote:
> > > > > > > > > > Can we not get down the same code path that --deps=all does?
> > > > > > > > > > 
> > > > > > > > > >   --deps=OS_LIST        override deps for the specified
> > > > > > (comma-separated)
> > > > > > > > > >                         platform(s); 'all' will process all
> > > deps_os
> > > > > > > > references
> > > > > > > > > 
> > > > > > > > > Alternatively, maybe just the SAN bots should opt in to
deps_os
> =
> > > > > 'llvm'?
> > > > > > > > 
> > > > > > > > Let's keep it simple until some bot starts complaining about
sync
> > > > times...
> > > > > > > 
> > > > > > > Was just thinking that might be simpler if there is no equiv to
> 'all'
> > > > > outside
> > > > > > of
> > > > > > > the command line.
> > > > > > 
> > > > > > I can't specify flags directly in the recipe.  I can change this to
> > "all"
> > > > but
> > > > > > it's hard to test without any deps_os entries in Skia.  If we land
> your
> > > DEPS
> > > > > > change, the worst that happens is that the *SAN bots fail for a
while,
> > > > right?
> > > > > 
> > > > > Yep.  We'd want to watch the gclient sync logs very carefully
though...
> > most
> > > > > (probably all) of the *SAN bots already have LLVM+co checked out, so
if
> we
> > > > fail
> > > > > here it may look like we succeeded.
> > > > 
> > > > Agreed, although I *think* gclient auto-deletes no-longer-used DEPS.
> > > 
> > > Want to just land the other change and see what happens?
> > 
> > So,
> >    1) land other change
> >    2) hope it breaks *SAN bots
> >    3) land this change with 'all'
> >    4) hope it fixes *SAN bots
> > If not,
> >    5) reland this change with 'llvm'
> >    6) be a little sad
> > ?
> 
> Yeah, pretty much.

sgtm

[borenet, 2016-03-02 17:39:56]

The CQ bit was checked by borenet@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-03-02 17:40:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1750853005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1750853005/20001

[borenet, 2016-03-02 17:40:38]

Description was changed from

==========
Skia bots: use deps_os = 'llvm'

BUG=
==========

to

==========
Skia bots: use deps_os = 'all'

BUG=
==========

[commit-bot: I haz the power, 2016-03-02 17:46:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-02 17:46:35]

Dry run: This issue passed the CQ dry run.

[bsalomon, 2016-03-02 18:16:16]

On 2016/03/02 17:46:35, commit-bot: I haz the power wrote:
> Dry run: This issue passed the CQ dry run.

Eric, I'll leave it to you to commit the other one when you're ready.

[bsalomon, 2016-03-09 21:07:45]

On 2016/03/02 18:16:16, bsalomon wrote:
> On 2016/03/02 17:46:35, commit-bot: I haz the power wrote:
> > Dry run: This issue passed the CQ dry run.
> 
> Eric, I'll leave it to you to commit the other one when you're ready.

Can we attempt this soon?

[borenet, 2016-03-10 13:18:16]

On 2016/03/09 21:07:45, bsalomon wrote:
> On 2016/03/02 18:16:16, bsalomon wrote:
> > On 2016/03/02 17:46:35, commit-bot: I haz the power wrote:
> > > Dry run: This issue passed the CQ dry run.
> > 
> > Eric, I'll leave it to you to commit the other one when you're ready.
> 
> Can we attempt this soon?

I'm sorry - I just saw your comment.  I was waiting for you to commit the CL. 
I'll land it this morning.

[borenet, 2016-03-10 14:08:18]

The CQ bit was checked by borenet@google.com

[commit-bot: I haz the power, 2016-03-10 14:08:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1750853005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1750853005/20001

[commit-bot: I haz the power, 2016-03-10 14:08:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-10 14:08:25]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
Committers are members of the group "project-infra-committers".
Note that this has nothing to do with OWNERS files.

[borenet2, 2016-03-10 14:10:16]

On 2016/03/10 14:08:25, commit-bot: I haz the power wrote:
> No L-G-T-M from a valid reviewer yet. 
> CQ run can only be started by full committers or once the patch has
> received an L-G-T-M from a full committer.
> Even if an L-G-T-M may have been provided, it was from a non-committer,
> _not_ a full super star committer.
> Committers are members of the group "project-infra-committers".
> Note that this has nothing to do with OWNERS files.

LGTM

[borenet2, 2016-03-10 14:10:23]

The CQ bit was checked by borenet@chromium.org

[commit-bot: I haz the power, 2016-03-10 14:10:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1750853005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1750853005/20001

[commit-bot: I haz the power, 2016-03-10 14:11:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-10 14:11:43]

Try jobs failed on following builders:
  Build Presubmit on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Build%20Presubmit/build...)
  Build Try Recipe Test Mac on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Build%20Try%20Recipe%20...)
  Build Try Recipe Test Trusty64 on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Build%20Try%20Recipe%20...)

[borenet, 2016-03-10 14:23:00]

On 2016/03/10 14:11:43, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   Build Presubmit on tryserver.infra (JOB_FAILED,
>
https://build.chromium.org/p/tryserver.infra/builders/Build%20Presubmit/build...)
>   Build Try Recipe Test Mac on tryserver.infra (JOB_FAILED,
>
https://build.chromium.org/p/tryserver.infra/builders/Build%20Try%20Recipe%20...)
>   Build Try Recipe Test Trusty64 on tryserver.infra (JOB_FAILED,
>
https://build.chromium.org/p/tryserver.infra/builders/Build%20Try%20Recipe%20...)

Re-uploaded as https://codereview.chromium.org/1777303002/