The last use of scm level in mozharness is in `mozharness.mozilla.secrets` which
uses the `MOZ_SCM_LEVEL` environment variable directy.
Differential Revision: https://phabricator.services.mozilla.com/D20897
--HG--
extra : moz-landing-system : lando
This adds an android_emulator_wrench.py script that uses mozharness to
control the Android emulator, and run the wrench reftests. It has an
associated wrench.py config script which is similar to existing android
config scripts.
The android_emulator_wrench script is structured a little differently
from other android mozharness scripts, mostly for two reasons:
1) I tried hard to make it locally runnable by developers, using
./mach python. This allows develpers to more easily reproduce the
setup that runs in automation, and does so without duplicating a lot
of code.
2) I also tried to make the script use fewer of what I consider to be
"opaque" mozharness features, like the actions list which can run
hard-to-find preflight and postflight functions. Instead of treating
mozharness like a framework and filling in some functions for it to
invoke as part of it's grand plan, I treat it more like a library and
specifically the functions I want in the order that I want, which
makes it easier for novice developers to debug problems.
As part of writing this script I extracted a few helper functions and made
some minor changes to existing android/adb mozharness machinery, but these
are all simple refactorings and should introduce no functional change.
Differential Revision: https://phabricator.services.mozilla.com/D32014
--HG--
extra : moz-landing-system : lando
It turns out there are several places where the change to suite 'jittest-chunked'
causes problem. I am abandoning that approach.
Desktop uses this trick, and this returns android '-chunked' handling to a state
similar to what it was before I started messing around!
Differential Revision: https://phabricator.services.mozilla.com/D28897
--HG--
extra : moz-landing-system : lando
This officially makes 'moztest.resolve' the source of truth when it comes to
suite names. It aligns that file with the names used in both the
desktop_unittest and android_emulator_unittest scripts.
Differential Revision: https://phabricator.services.mozilla.com/D27555
--HG--
extra : moz-landing-system : lando
Since e10s is the default configuration, we shouldn't explicitly mark things
with the "-e10s" suffix. Instead we should mark things that *don't* run with
'e10s. This patch removes '-e10s' from all treeherder group symbols and task
labels, adds the "-1proc" suffix to tasks that are non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D25958
--HG--
extra : moz-landing-system : lando
Add Android 7.0 gtests, opt and debug, running against the geckoview
TestRunnerActivity.
Differential Revision: https://phabricator.services.mozilla.com/D27016
--HG--
extra : moz-landing-system : lando
This disables GLES3 in the android emulator unless WebRender is
explicitly enabled, because for now the half-baked ES3 support in the
emulator causes some WebGL tests to fail.
Differential Revision: https://phabricator.services.mozilla.com/D26940
--HG--
extra : moz-landing-system : lando
This only uses cross-platform tools, so switch to running these on linux, which
cuts the runtime down from ~20m to ~3m.
Differential Revision: https://phabricator.services.mozilla.com/D1080
--HG--
extra : moz-landing-system : lando
In automation, the script is run with `mach python`, and all the dependencies
are vendored, so just use them directly.
Differential Revision: https://phabricator.services.mozilla.com/D25839
--HG--
extra : moz-landing-system : lando
These existed for when bouncer was updated via mozharness, and they are unused in bouncer-check.
By removing the paths, we make the configuration easier to read and update.
Differential Revision: https://phabricator.services.mozilla.com/D25838
--HG--
extra : moz-landing-system : lando
When adding a new platform, the first release will be at the watershed, and
there will be no update paths. Rather than failing in this case (requiring the
update-verify setup happen after the first release), generate an empty config
which will allow the later tasks to turn green.
Differential Revision: https://phabricator.services.mozilla.com/D25833
--HG--
extra : moz-landing-system : lando
This functionality has been replaced by beetmover. Also remove `mozharness.mozilla.aws`,
of which this was the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D25676
--HG--
extra : moz-landing-system : lando
There used to be various values that were substituted into the mozharness
configuration for L10n jobs. All those substitutions have been removed, but the
code to support them is still around. This removes that code.
Differential Revision: https://phabricator.services.mozilla.com/D25143
--HG--
extra : moz-landing-system : lando
An `sy-tp6` variant is added to the AWSY test suite that runs against the tp6 pageset.
Differential Revision: https://phabricator.services.mozilla.com/D24585
--HG--
extra : moz-landing-system : lando
There used to be various values that were substituted into the mozharness
configuration for L10n jobs. All those substitutions have been removed, but the
code to support them is still around. This removes that code.
Differential Revision: https://phabricator.services.mozilla.com/D25143
--HG--
extra : moz-landing-system : lando
This only uses cross-platform tools, so switch to running these on linux, which
cuts the runtime down from ~20m to ~3m.
Differential Revision: https://phabricator.services.mozilla.com/D1080
--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
This introduces a mozharness script, android_emulator_pgo.py, to run the
profileserver suite with the PGO-instrumented Android build, and collect
the profile data and jarlog.
The mozharness script contains some redundancy with
build/pgo/profileserver.py, but the additional requirements for Android
to use adb and existing mozharness classes to control the emulator made
it difficult to share the desktop profileserver implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22825
--HG--
extra : source : c151ebf303cad175e24bcc0965c800a9d12ecb3b
This introduces a mozharness script, android_emulator_pgo.py, to run the
profileserver suite with the PGO-instrumented Android build, and collect
the profile data and jarlog.
The mozharness script contains some redundancy with
build/pgo/profileserver.py, but the additional requirements for Android
to use adb and existing mozharness classes to control the emulator made
it difficult to share the desktop profileserver implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22825
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
While try syntax is approaching its EOL, the fact that using it to do
artifact builds does some things subtly differently from using try
config is not helpful.
Depends on D22055
Differential Revision: https://phabricator.services.mozilla.com/D21312
--HG--
extra : moz-landing-system : lando
Changes:
- modified the criteria for using 1 as the successful return code by using a combination of factors; is it Windows, is it 32bit, and is it Reftest.
Differential Revision: https://phabricator.services.mozilla.com/D21596
--HG--
extra : moz-landing-system : lando
Bug 1120644 will be used to look into why Windows 7 reftests are still returning 1.
Differential Revision: https://phabricator.services.mozilla.com/D20665
--HG--
extra : moz-landing-system : lando
Mars are now generated by separate repackage tasks, so we don't need mar tools
in L10n builds.
Differential Revision: https://phabricator.services.mozilla.com/D17161
--HG--
extra : moz-landing-system : lando
Mihai Alexandru Michis
Gijs Kruitbosch
Tom Prince
Kartikaya Gupta
Geoff Brown
Joel Maher
Andrew Halberstadt
Daniel Varga
Noemi Erli
Eric Rahm
Oana Pop Rus
Mike Shal
Mike Hommey
Dan Minor
Edwin Gao
Narcis Beleuzu
Mihai Tabara
Sebastian Hengst
Matt Howell