On 15/09/17 00:53, Dustin Mitchell wrote:
2017-09-14 18:32 GMT-04:00 Botond Ballo <bba...@mozilla.com>:
I think "-p all" is still useful for "T pushes" (and it sounds like
build jobs aren't the main concern resource-wise).
Correct -- all builds are in AWS.
I'd like to steer this away from "What legacy syntax should we use
instead?" and "How should we tweak the legacy try syntax?" to:
How can we use the modern tryselect functionality to achieve more
precise try pushes?
I think that's a good discussion to have, but the original motivation
for this thread aiui are recent incidents where there have been 12+ hour
backclogs on try, causing problems across the org. In general we ought
to solve this by being smarter about what's run automatically, but we
aren't there yet. We also don't have full uptake of |mach try fuzzy| and
in any case, people likely to be impacted by this all know try syntax.
So a discussion in those terms seems meaningful.
I think there are some fairly simple rules people can apply to help with
the observed, recurring, problem. These are not official, I'm not in a
position of authority here, but I assume people will correct anything
that's wrong or controversial:
* -p all is generally OK because builds are on cloud machines and we
aren't hardware constrained there. Obviously any unnecessary job,
including builds, does cost money.
* Bare -p all -u all generally isn't OK. In particular it shouldn't be
seen as the default "check before landing" try push. Of course, if you
have a large cross-cutting change that genuinely could affect any test
on any platform, it might be the right choice.
* A combination of selecting specific relevant suites and representative
platforms using -u <suite|all>[platform] is generally a good choice.
|mach try fuzzy| is a better way to schedule this kind of push.
* mach try allows specifying specific paths or directories. This allows
even finer grained test selection where you are interested in specific
tests.
* In general running tests on mac should be avoided if possible. This is
our most hardware constrained regression test platform. People only
using it when they think that their change will affect mac differently
to linux and windows will help a lot.
* If you know your try push failed before all jobs complete, or you land
a patch with jobs still pending, please take a moment to cancel all
pending jobs from treeherder. That is disproportionately helpful for
freeing up resources on backlogged platforms.
* I have no idea about performance tests.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
