The graph contains some extra things like toolchains, fetches and packaging
tasks that people will almost never want to run on their own. This change gets
them out of the default fuzzy selection interface, and makes it so --full is
needed to schedule them.
Differential Revision: https://phabricator.services.mozilla.com/D24187
--HG--
extra : moz-landing-system : lando
Not only is it best practice to pin dependencies and check hashes, but this
will allow tests to install these dependencies as well.
Depends on D22784
Differential Revision: https://phabricator.services.mozilla.com/D22785
--HG--
extra : moz-landing-system : lando
This forces us to be more strict with what gets passed into the try selector.
This change means test_preset.py will error if someone makes a typo in an
in-tree preset.
Differential Revision: https://phabricator.services.mozilla.com/D22024
--HG--
extra : moz-landing-system : lando
When we parse template arguments, we stuff them all in kwargs['templates'],
however we don't delete the old argument. This results in all kinds of unused
variables lying around in kwargs. E.g we would have both
kwargs['templates']['env'] and kwargs['env'] (the latter being unused). This is
the main reason why all the selector's run functions need to have a **kwargs at
the end of them.
Depends on D22022
Differential Revision: https://phabricator.services.mozilla.com/D22023
--HG--
extra : moz-landing-system : lando
This was previously only in the cli parser because that was the only shared
place that ran for all selectors. Now that we have the 'self.run' function in
mach_commands.py, we can move it there. This move is also needed to allow us to
remove 'templates' from kwargs (which happens in the next commit).
Depends on D22021
Differential Revision: https://phabricator.services.mozilla.com/D22022
--HG--
extra : moz-landing-system : lando
This allows us to refactor mach_commands.py so we can call self.handle_presets
implicitly. This in turn gives us a future place to add shared code and makes
adding new selectors easier.
Differential Revision: https://phabricator.services.mozilla.com/D22021
--HG--
extra : moz-landing-system : lando
This creates a global preset file at:
tools/tryselect/try_presets.yml
Any presets defined here will be available for everyone to use.
Differential Revision: https://phabricator.services.mozilla.com/D21435
--HG--
extra : moz-landing-system : lando
This will make it possible to have multiple instances of PresetHandler to
support multiple preset files.
Differential Revision: https://phabricator.services.mozilla.com/D21429
--HG--
extra : moz-landing-system : lando
I forgot to remove this after re-implementing without this dependency.
Depends on D20521
Differential Revision: https://phabricator.services.mozilla.com/D20522
--HG--
extra : moz-landing-system : lando
I'm not really sure why Flask isn't printing this for us, but it's not worth
investigating when the alternative is so easy.
Differential Revision: https://phabricator.services.mozilla.com/D20712
--HG--
extra : moz-landing-system : lando
Previously, this code looked parameters under `gecko.v2`, but that doesn't work
for projects using the out-of-tree taskgraph code, or Thunderbird. This moves
the parameter loading slightly later to vary the index used based on trust domain.
Differential Revision: https://phabricator.services.mozilla.com/D19028
--HG--
extra : moz-landing-system : lando
This fixes a regression from bug 1483228. It started printing a message to
stdout whenever the local state dir was generated. This caused a failure in
these cramtests since they depend on the stdout of the shell process being
identical.
To fix, make sure we trigger state dir creation in the setup script and
redirect to /dev/null.
Differential Revision: https://phabricator.services.mozilla.com/D19155
--HG--
extra : moz-landing-system : lando
This was previously implemented by creating the local state dir within the
global state dir (using a hash of the path in the name). This moves the
|mach try again| history state to the new local state dir.
It also updates the migration code to be a little more robust, ensuring we
don't accidentally lose people's history. This migration should be removed
at some point in the future (2020 seemed like a safe enough window).
Differential Revision: https://phabricator.services.mozilla.com/D15725
--HG--
extra : moz-landing-system : lando
mozboot.util.get_state_dir() returns a tuple of (<path>, <bool). The bool
denotes whether or not the state dir came from an environment variable.
But this value is only used in a single place, and is very easy to test for
anyway. It's not worth the added complexity it imposes on all other consumers
of this function. Let's just make this function return the path.
Differential Revision: https://phabricator.services.mozilla.com/D15723
--HG--
extra : moz-landing-system : lando
Passing in --exact reverses the behaviour of the ' operator. For example,
take the query "foo 'bar".
By default: foo is a fuzzy match and bar is an exact match.
With --exact: foo is an exact match and bar is a fuzzy match
Differential Revision: https://phabricator.services.mozilla.com/D16734
--HG--
extra : moz-landing-system : lando
Usage:
$ ./mach try chooser
Will start a local flask server and server a "trychooser-like" page
that is dynamically generated from the taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D14903
--HG--
extra : moz-landing-system : lando
Usage:
$ ./mach try chooser
Will start a local flask server and server a "trychooser-like" page
that is dynamically generated from the taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D14903
--HG--
extra : moz-landing-system : lando
Eventually, workers will provide these variables directly
(https://bugzilla.mozilla.org/show_bug.cgi?id=1460015). But for now, this
ensures that TASKCLUSTER_ROOT_URL is set everywhere, and TASKCLUSTER_PROXY_URL
is set wherever the proxy is active.
The setup for the mach commands defaults to https://taskcluster.net for user
convenience. When the production instance's URL changes, we can simply change
that default.
This changes the docker build process propagate TASKCLUSTER_ROOT_URL into the
docker images where necessary (using %ARG), specifically to create URLs for
debian repo paths.
--HG--
extra : rebase_source : 0626ebdb66a9f4078cb75ab71be256c334297363
Eventually, workers will provide these variables directly
(https://bugzilla.mozilla.org/show_bug.cgi?id=1460015). But for now, this
ensures that TASKCLUSTER_ROOT_URL is set everywhere, and TASKCLUSTER_PROXY_URL
is set wherever the proxy is active.
The setup for the mach commands defaults to https://taskcluster.net for user
convenience. When the production instance's URL changes, we can simply change
that default.
This changes the docker build process to propagate TASKCLUSTER_ROOT_URL into
the docker images, and for good measure includes some code to use that value to
generate debian repo paths.
Differential Revision: https://phabricator.services.mozilla.com/D14196
--HG--
extra : moz-landing-system : lando
Currently selectors that generate the taskgraph receive a list of task labels
back. While this works, it isn't very robust and limits the selectors in what
they can accomplish.
For example, it means we need to use regexes to map test suites to tasks. If
we had the full taskgraph, we could use filter functions instead.
There are also new selectors in the works which will need this (like ./mach
try chooser). Finally the try syntax selector would also need this if we
ever migrate it to use the 'try_task_config.json' format.
Differential Revision: https://phabricator.services.mozilla.com/D12570
--HG--
extra : moz-landing-system : lando
Now that `mach try release` also supports simulating release and esr, rename
the option to `release-sim`.
Differential Revision: https://phabricator.services.mozilla.com/D11516
--HG--
extra : moz-landing-system : lando
We only use `include_nigthly` where we are also using
`filter_beta_release_tasks`, so just change the later to include nightly.
Differential Revision: https://phabricator.services.mozilla.com/D9687
--HG--
extra : moz-landing-system : lando
This adds `mach try release` which adds temporary changes to enable staging
release to run.
Differential Revision: https://phabricator.services.mozilla.com/D8625
--HG--
extra : moz-landing-system : lando
Usually people don't mean to schedule code coverage tasks on try. But e.g |mach
try fuzzy -q "'mochitest"|, will cause them to be scheduled as a side effect.
This results in wasted resources and superfluous data in ActiveData.
This patch makes it so you need to explicitly pass --full to select ccov tasks
(even though they're technically part of the target task graph).
Differential Revision: https://phabricator.services.mozilla.com/D3917
--HG--
extra : moz-landing-system : lando
Currently, `mach try fuzzy` generates a taskgraph that is configured exactly
like the most recent push to mozilla-central. This isn't always desirabe, so
pass some configuration down, to allow the taskgraph to behave differently.
Differential Revision: https://phabricator.services.mozilla.com/D2729
--HG--
extra : rebase_source : 99d6958b33211697227e65df17edc1eb337f63a4
extra : histedit_source : 69b5ff6805bc8409340eb71323a1f6fc637259d7
One of the big downsides to |mach try fuzzy| is that if you use the interactive
finder, there's no way to repeat your last action. If you want to run the same
push again, you have to manually re-select all the same tasks a second time.
It is possible to save presets, but this is fairly heavy-weight and (more)
permanent. Sometimes you just want to re-run a push a few times and forget
about it. It's also possible to craft the query on the command line with -q,
but then you don't get the immediate visual feedback, so you can't be sure that
you typed out the right things without actually pushing.
With |mach try again|, everytime you generate a try_task_config.json via
'fuzzy', 'empty' or any other subcommands that may exist in the future, it'll
get stored in a history file under ~/.mozbuild. Then running |mach try again|
will simply re-run the most recent try_task_config.json.
You'll also be able to view the whole history via |mach try again --list| and
select a specific try_task_config.json (i.e not the most recent one) via
|mach try again --index <index>|.
Example usage will be:
$ ./mach try fuzzy
<select a bunch of tasks>
$ ./mach try again
<re-pushes exact same set of tasks>
MozReview-Commit-ID: 3EZjVCy08uq
Depends on D1808.
Differential Revision: https://phabricator.services.mozilla.com/D1867
--HG--
extra : moz-landing-system : lando
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Currently it's possible to specify a single query and take the union of terms with the '|'
symbol. However if you want to craft anything more complicated (i.e linux mochitest and
xpcshell, but windows reftest), it becomes really difficult. This allows developers to union
the result of multiple queries.
For example:
./mach try fuzzy -q "'linux 'mochitest | 'xpschell" -q "'windows 'reftest"
Differential Revision: https://phabricator.services.mozilla.com/D1838
Enables |./mach try fuzzy --talos-profile|. This template only applies to talos
tasks. It also provides --geckoProfile for consistency with |mach try syntax|,
but I don't like this name so it's hidden from the help.
The 'talos-profile.yml' template is also very specific (only applies to Talos
tasks). Ideally I'd like a general 'command.yml' template that just appends
arguments to the command for any arbitrary tasks. But then we'd need to invent
an expression syntax in try_task_config.json so we could make sure it only
applies to Talos. Then I thought rather than implement it for a specific
template, we should have a general way of doing this which could apply to any
and all of the templates.
Needless to say, it's a rabbit hole and something that's best left to a
follow-up so we don't delay this bug.
MozReview-Commit-ID: GhllZ7sr0ar
--HG--
extra : rebase_source : 1de4deecc2f73130904d7c95d4ff12f85883cd91
This is gated by the `--chemspill-prio` flag, which should at least make anyone
abusing it to get faster results feel sorry for what they've done.
MozReview-Commit-ID: J4EwH45IkMX
--HG--
extra : rebase_source : 1bfbfafd7de914aaab52f48f0e37c09c0df05dd7
You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
The end goal here is to be able to use |mach try fuzzy <path>| with tests that
belong to a subsuite. To do this, we need a unique 'task_regex' value for each
subsuite so that we can map a test path back to a set of tasks.
This removes the TEST_FLAVORS dict (which was mostly just a redefinition of the
data in TEST_SUITES), and instead provides two new private mappings:
<flavor> -> suite definition
(<flavor>, <subsuite>) -> suite definition
To retrieve a suite definition given a flavor/subsuite, consumers can now call
get_suite_definition.
MozReview-Commit-ID: 2pe1v1IHUVy
--HG--
extra : rebase_source : 6fff947ba214112ccf16c894174a6a0e2487111a
This enables the syntax like:
./mach try fuzzy dom/indexedDB
This will open up the fzf interface like normal, except only tasks
that have tests under dom/indexedDB will be selectable (and there
will only be one chunk per configuration).
This can be combined with -q/--query like normal:
./mach try fuzzy dom/indexedDB -q "!pgo !cov !asan"
When the tasks get scheduled, only the tests under the specified
path(s) will run within the harness.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 8a89f255591e6dfa31b1420196c4698f2015d10c
This simply groups arguments related to generating the list of
tasks from taskgraph into their own argument group.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6c746f0cb8d93f957f50ba12f77d63edb04b6d1e
This sets the MOZHARNESS_TEST_PATHS environment variables for all tasks.
When specifying paths, this will cause many test tasks to only run the
tests under that directory as opposed to the normal default.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : e7132311641f4d36a5bff56424988fbb3ae87238
This changes templates so they return an entire context dict instead of
only returning context based on their name. For example, now the 'path'
template can set context for 'env'.
A side effect of this is that there is no longer a 1-to-1 mapping of templates
in tryselect and taskgraph.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 4d7e398e60598a5de7961fb126f1d05a0b983681
This makes use of pytest's generation feature. To add a new
template test, just add a new entry containing the input and
expected output to the dict in test_templates.py
MozReview-Commit-ID: 4qMefYHMjAp
--HG--
extra : rebase_source : ba3049885d1a2485048e1ff9913be43317559376
This adds some basic documentation for |mach try| and its various subcommands.
This was a bit hastily made for the Austin all-hands, but at least provides a
place to link to and can be improved upon in the future.
MozReview-Commit-ID: 8N6LZO5kTlL
--HG--
extra : rebase_source : c7e215703426f6cfb03b044d188a53d1ba878a75
This speeds up taskgraph generation by ~6 seconds on my machine. Future
improvements are also planned for 'fast' mode.
MozReview-Commit-ID: CLORvLXuV8y
--HG--
extra : rebase_source : a59dc5f166eff15e5031f5736eadac41dcd46ffe
This is a new module that will provide a place to store some common
abstractions around the 'blessings' module. The main entrypoint is:
from mozterm import Terminal
term = Terminal()
If blessings is available, this will return a blessings.Terminal()
object. If it isn't available, or something went wrong on import,
this will return a NullTerminal() object, which is a drop-in
replacement that does no formatting.
MozReview-Commit-ID: 6c63svm4tM5
--HG--
extra : rebase_source : 9ab221774d92a418d9b098d79bb2c88f75d937f8
`mach try` pushes the repository containing the current directory. When this is
a comm-central checkout, the taskcluster configuration should also come from that
repository.
MozReview-Commit-ID: KWbNAe4jrHT
--HG--
extra : rebase_source : e40f5038bdd190fb4cb801ba817c31a3e4031354
extra : source : 7164b051c965280aeb3083e47a93c6d4ac44e2ed
This is a minor cleanup around finding and importing subcommand parser in |mach try|.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6b05b6f3fafed607992b9427225fd43165c4102f
This allows rebuilding all selected tasks. This defines an upper limit of
20 rebuilds per push. If more are needed, developers can either change it
in code or push multiple times.
MozReview-Commit-ID: I0XtMP5yEEq
--HG--
extra : rebase_source : 2583bed5dd33df72a4d7f1cd0ce012e412418c5e
The code in |mach test| for test resolving, should get merged with the TestResolver
class in moztest.resolve. This way it can be shared with other modules and we'll
have a single canonical place for all our test resolving logic.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6f96d06412ab8fa152ac5d9bdd15acbcdc9695c4
The TestMetadata and TestResolver classes aren't technically part of the build
system. The only connection is that they consume some build system output.
The next patch in this series is going to be merging in a bunch of other test
resolving logic from other parts of the tree. Moving this out first allows us
to keep that extra logic out of mozbuild.
MozReview-Commit-ID: 1eq4SjFVCyW
--HG--
rename : python/mozbuild/mozbuild/test/test_testing.py => testing/mozbase/moztest/tests/test_resolve.py
extra : rebase_source : 7ff11f9ec455547533082d20cb5371845f7a4f21
Currently the prompts don't make it clear enough that running fzf will mess with your
shell settings. This means users could install it without realizing, forget and get
confused later on.
Rather than try to address this, it's simpler to always skip the shell extensions as
|mach try fuzzy| doesn't need them anyway. The extensions are useful, but are better
installed via something like |mach bootstrap| which can be tackled in a separate bug.
MozReview-Commit-ID: 2kx7UGO5LJ0
--HG--
extra : rebase_source : 64474626aeab9f2f04f491afc65ca7cadd717296