Some of these were working with the '<flavor>-<subsuite>' mechanism that was
previously being used, but better to be explicit wherever possible.
Depends on D25077
Differential Revision: https://phabricator.services.mozilla.com/D25078
--HG--
extra : moz-landing-system : lando
Mozharness appends -chunked/-coverage to some suites, but the build system/test
resolver don't have any concept of these things. We need to normalize these out
for the purposes of MOZHARNESS_TEST_PATHS.
Differential Revision: https://phabricator.services.mozilla.com/D25015
--HG--
extra : moz-landing-system : lando
It turns out bug 1489100 regressed the ability to specify test paths for most
suites by naively assuming that mozharness uses suite names that look like:
<flavor>-<subsuite>
In reality, there is no consistency to how suite names are generated. This test
does a few things:
1) Patches the moztest.TestResolver to return a list of all possible
suites/subsuites (assuming the lists in moztest.resolve are up to date).
2) Finds all the suites defined in the mozharness configs (e.g
linux_unittest.py), and uses these are parametrized inputs.
3) Checks that for each test suite,
DesktopUnittest._get_mozharness_test_paths() returns something.
I've marked all of the test suites that currently fail as expected. This way I
have a good sense of what needs to be fixed, and can validate my changes as I
move through the list.
Differential Revision: https://phabricator.services.mozilla.com/D25014
--HG--
extra : moz-landing-system : lando
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
