If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
Although we don't use `node` for test except xpcshell, many yml includes `desktop_unittest.py`, which fetches `node` in the last patch.
Hence, expose node path to MOZ_NODE_PATH env variable only if we have fetched node from toolchain.
Differential Revision: https://phabricator.services.mozilla.com/D45108
--HG--
extra : moz-landing-system : lando
Currently, we have no real visibility on the time spent after the build
finished, despite the fact that a large chunk is actually happening via
make check (although thankfully more and more of it is moving out to
separate tasks).
Also, the mozharness machinery for make check dates from when we were
running in buildbot and takes care of turning builds orange instead of
red in case of failure, etc. which doesn't do anything useful anymore.
Differential Revision: https://phabricator.services.mozilla.com/D42806
--HG--
extra : moz-landing-system : lando
The remaining uses all need adjustements to in-tree mozconfigs, so they
all need to be done at once.
However, to make things slightly more intelligible, we do this in two
steps. This is step 1: we modify the use_toolchain transform to take care of
the transformation, while keeping the task definitions intact, so that
we only deal with mozconfig and build script adjustements here.
Differential Revision: https://phabricator.services.mozilla.com/D41890
For esr versions, the category switches from "esr" to "stability" when the next esr branch is started. This breaks
the logic for determining which repository a release was made from. Since we also have code for determining the
type of release from the version number, we can just use that directly instead.
(Note that the logic will not work for Fennec as all releases have transitioned to mozilla-esr68, but Fennec does not
use update-verify.
Differential Revision: https://phabricator.services.mozilla.com/D38437
--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
This adds support for the Android process writing out multiple profraw
files and pulling them all from the device. We currently only generate a
single profraw file, but if that changes in the future we should be able
to get a PGO build using the full set of files now.
Depends on D36840
Differential Revision: https://phabricator.services.mozilla.com/D36841
--HG--
extra : moz-landing-system : lando
If we end up generating multiple profraw files in the future, it will
help to have them all in a separate directory so that we can just 'adb
pull' the whole directory at once.
Depends on D36839
Differential Revision: https://phabricator.services.mozilla.com/D36840
--HG--
extra : moz-landing-system : lando
After execute_script() returns, the Android process may not be fully
shutdown, so the profile data may not exist yet. The initial
implementation waited for this by checking if the profraw file existed
and was non-zero length, but this may be contributing to issues with
getting partial profraw files.
Instead we can wait for the whole process to exit by using
process_exist(), so the profraw file should be completely written out
by then. In the event that the profraw file is truncated for some
reason, the merge step will fail and the process will be retried (per
bug 1560755).
Differential Revision: https://phabricator.services.mozilla.com/D36839
--HG--
extra : moz-landing-system : lando
Android profile runs don't always fully write out the profile data. In
this case, the corrupted profile data is successfully uploaded, but
future profile-use PGO builds try to merge the data and fail. Retrying
the profile-use builds doesn't help, since they all pull from the same
job that published the corrupt data.
We can detect this in the run task by using llvm-profdata merge, and if
the merge fails the task can automatically be retried. Note that the
data gets redundantly merged in the profile-use build, but it may not be
possible to run the merge in the run task on all platforms (eg: OSX), so
we have to keep the merge there as well.
Differential Revision: https://phabricator.services.mozilla.com/D36294
--HG--
extra : moz-landing-system : lando
This is not used yet but will be eventually so I'm just going to
add it now.
As of this patch, all the tests that we currently run on android HW do
accept the --enable-webrender flag and explicitly disable WR if it is
not provided.
Differential Revision: https://phabricator.services.mozilla.com/D35868
--HG--
extra : moz-landing-system : lando
Instead of using --setenv to control WebRender being on or off, just propagate
the --enable-webrender flag to the downstream "remote" test harness. This
is more reliable than passing --setenv because not all harnesses support
the setenv flag, and it's easier to explicitly add support for --enable-webrender
to the harnesses that need it (i.e. the ones we want to run with WR enabled in
automation).
This also drops the --disable-webrender flag and asserts that lack of
enable-webrender implies WR will be disabled.
Differential Revision: https://phabricator.services.mozilla.com/D35867
--HG--
extra : moz-landing-system : lando
Now that all the downstream test harnesses take the --enable-webrender
option and propagate it correctly, the desktop_unittest.py wrapper can
just pass it along to those harnesses.
Differential Revision: https://phabricator.services.mozilla.com/D35866
--HG--
extra : moz-landing-system : lando
AWSY is built on marionette, so it inherits the option by default, we mostly
just need to propagate it properly. This also drops the --disable-webrender
option as it is now implied if --enable-webrender is not provided.
Differential Revision: https://phabricator.services.mozilla.com/D35863
--HG--
extra : moz-landing-system : lando
This is required so that crashes on import don't block updating tests.
It makes that change from 1539449 only apply to non-wpt suites, which is
not ideal but no worse than the previous setup.
Differential Revision: https://phabricator.services.mozilla.com/D35218
This is not used yet but will be eventually so I'm just going to
add it now.
Depends on D34623
Differential Revision: https://phabricator.services.mozilla.com/D34624
--HG--
extra : moz-landing-system : lando
Ensure we force-disable webrender unless it is explicitly enabled
via the --enable-webrender flag. Also add missing env variables for
the telemetry_client.py case which appears to be a copy/paste error
that was not caught because we never run that test with WR enabled.
Depends on D34622
Differential Revision: https://phabricator.services.mozilla.com/D34623
--HG--
extra : moz-landing-system : lando
This drops the --disable-webrender option (which force-disables WR)
and treats the lack of an --enable-webrender as if --disable-webrender
was provided.
Differential Revision: https://phabricator.services.mozilla.com/D34622
--HG--
extra : moz-landing-system : lando
The presence or absence of the DEVICE_SERIAL environment variable
is sufficient to control this.
Differential Revision: https://phabricator.services.mozilla.com/D33407
--HG--
extra : moz-landing-system : lando
This is in preparation for having the same script be used for emulator
and device runs. No functional change in this patch; it just renames
the file and class.
Differential Revision: https://phabricator.services.mozilla.com/D33406
--HG--
rename : testing/mozharness/scripts/android_emulator_wrench.py => testing/mozharness/scripts/android_wrench.py
extra : moz-landing-system : lando
This allows local runs where the emulator stays up between runs to have
a cleaner logcat, because it won't pull historical logcat from the emulator.
Differential Revision: https://phabricator.services.mozilla.com/D33038
--HG--
extra : moz-landing-system : lando
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
For shutdown crashes in wpt wse need to ignore the crashes for now
until we have a way of allowing specific ones. So just have a global
flag that permits this.
Differential Revision: https://phabricator.services.mozilla.com/D16836
The keys in the test_paths dict contain the name of the suite e.g. web-platform-tests-testharness, so specify these
keys rather than the generic web-platform-tests key
Differential Revision: https://phabricator.services.mozilla.com/D14284
--HG--
extra : moz-landing-system : lando
Bug 1491907 changed update-verify-config-creator from spliting the slug from
product-details, to using the version. However, the version doesn't have the
'esr' suffix that the taskgraph code expects. Append `esr` to the version
string to handle this case.
Differential Revision: https://phabricator.services.mozilla.com/D11264
--HG--
extra : moz-landing-system : lando
That variable, and the function that references it is only used by the openh264
code, so move it there.
Differential Revision: https://phabricator.services.mozilla.com/D9967
--HG--
extra : moz-landing-system : lando
This replaces a previous Firefox-only method except on Windows 7 where
it seems that we have some issues with the registry.
Differential Revision: https://phabricator.services.mozilla.com/D9091
This makes enabling DMD at runtime in automation opt-in via a '--dmd' param.
Currently this is enabled via the 'awsy-dmd-e10s' and 'awsy-base-dmd-e10s'
tests.
--HG--
extra : rebase_source : 0371dca4d99197e7f0a37dfcd3763903f807b7b0
The patch makes sure that the correct path to the geckodriver binary
is used for the web-platform-tests script.
Differential Revision: https://phabricator.services.mozilla.com/D7417
--HG--
extra : moz-landing-system : lando
The mozharness scripts have a lot of special case arguments for one off
configurations, stuff like --e10s, --enable-webrender and --gpu-required.
Many of these command line args ultimately only end up setting an extra pref in
the test harnesses. Instead, let's just give mozharness the ability to set
prefs directly via --setpref. This way we can pass them through from taskgraph
without needing to add extra configuration to mozharness when making changes
like this.
Differential Revision: https://phabricator.services.mozilla.com/D7191
--HG--
extra : moz-landing-system : lando
Thunderbird releases come from the comm-esr.* repositories rather than the
comm-release repository. This adds a special case for Thunderbird and sets
the branch URL correctly.
This initial patch is based on the branch_prefix (comm or mozilla).
Differential Revision: https://phabricator.services.mozilla.com/D6509
--HG--
extra : moz-landing-system : lando
This addresses the review comment from https://phabricator.services.mozilla.com/D6171
--HG--
extra : rebase_source : af26bfda433367e78115930be187528a64bbde91
extra : amend_source : 6ab77c4829ebdcb4701d76e5410790a0f760882f
There are two places where it is references:
- The build process generates a `balrog_props.json` that is not used anywhere.
(This is currently generated as part of beetmover).
- The merge day scripts have unused support for locking some rules.
Differential Revision: https://phabricator.services.mozilla.com/D6170
--HG--
extra : moz-landing-system : lando
Currently the BuildScript mozharness base class has an `ensure_upload_path`
action that we run after the build. This patch changes it to no longer be
an action, and instead simply run as part of `preflight_build` so that the
artifact directory will be created before starting the build. This makes
it more straightforward to write things like log files directly into this
directory without worrying about whether it exists.
Differential Revision: https://phabricator.services.mozilla.com/D6186
--HG--
extra : moz-landing-system : lando
Imports the changes to the UpdateVerifyConfig class, and sets --override-certs for staging releases.
Differential Revision: https://phabricator.services.mozilla.com/D5705
--HG--
extra : moz-landing-system : lando
Bug 1484264 made changes to how the repackage tasks is configured.
The package-name field was hard-coded to "firefox". This field is later
used to build the Windows installer, and Thunderbird requires that it
be set to "thunderbird" or the build fails.
This patch changes package-name to be a templated field like the others.
Differential Revision: https://phabricator.services.mozilla.com/D5222
--HG--
extra : moz-landing-system : lando
The script was setting minidump_stackwalk_path, signalling that minidump_stackwalk
is expected to be found pre-installed at that location. When the path is not set,
the executable is downloaded.
Uses the same mozharness structured output parser configuration on Windows as
on Linux and osx, for consistency.
Removes the ineffective "structured_suites" configuration for Windows unit
tests, since that key is ignored in desktop_unittest.py.
Also changes desktop_unittest.py to use structured output by default in
the absence of the expected unstructured_flavors configuration.
There are no instances of --mozbase-suite in either m-c or c-c, which proves this is unused.
Differential Revision: https://phabricator.services.mozilla.com/D2470
--HG--
extra : moz-landing-system : lando
In l10n repacks we run the repackage multiple times, once for each locale. If something low level fails (like compare-locales) we'll abort out and call _add_failure (from _map) which then will set the return code based on the type of failure.
However it, by default, will increment the return code each time it is called in BaseScript, so to preserve expectations here we should disable that from desktop_l10n.py
Differential Revision: https://phabricator.services.mozilla.com/D1971
--HG--
extra : moz-landing-system : lando
Disabling sandboxing seems to cause a memory regression for win32 builds which
affects our AWSY numbers. This switches over to only disabling sandboxing if
using a DMD build so that we can still run without crashing.
--HG--
extra : rebase_source : 9887c19cdd746aec9f6d9e64561f2226cd1ce443
This adds support running AWSY with DMD in automation via mozharness. We use
existence of dmd.py to detect whether or not dmd should be enabled.
Additionally sandboxing has to be disabled in order to avoid crashes on Windows
and OSX.
--HG--
extra : rebase_source : 1576dbb98bc2cff565ea5055daaec5a44aed88a8
Leave support for multil10n uses for now.
for "Cleanup l10n mozharness config files." (Batch 2)
Differential Revision: https://phabricator.services.mozilla.com/D1561
--HG--
extra : source : bb28c2d9d5f51f6e7eb797b892247948f1f7021b
Andrew Halberstadt
Mike Shal
Junior Hsu
Mike Hommey
Bob Clary
Nick Thomas
Aki Sasaki
Tom Prince
Geoff Brown
Byron Campen [:bwc]
Kartikaya Gupta
James Graham
Dorel Luca
Gijs Kruitbosch
Mihai Alexandru Michis
Joel Maher
Daniel Varga
Noemi Erli
Eric Rahm
Oana Pop Rus
Dan Minor
Edwin Gao
Narcis Beleuzu
Mihai Tabara
Sebastian Hengst
Matt Howell
Bobby Holley
Ciure Andrei
Marco Castelluccio
Henrik Skupin
Simon Fraser
Csoregi Natalia
Cosmin Sabou
Justin Wood
Raphael Pierzina
Rok Garbas
Rob Lemley
Ted Mielczarek
Ben Hearsum
Tudor-Gabriel Vîjială
Chris AtLee
Coroiu Cristina
Bogdan Tara
shindli
Tiberius Oros
Julien Cristau
Tom Ritter