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
Taskgraph needs to know the correct mar-channel, so allow it to pass it into the build,
rather than keying off the update-channel in configure. This will allow using a `mar`
binary that doesn't have the mar-channel configured in.
Differential Revision: https://phabricator.services.mozilla.com/D37480
--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
For the Raptor 'scenario' test type, this patch prevents PERFHERDER_DATA from being output when `--power-test`, `--cpu-test`, or `--memory-test` are not used.
Differential Revision: https://phabricator.services.mozilla.com/D31665
--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
Upgrade to version 29.0.11 of the emulator and use '-gpu on' rather than
swiftshader_indirect, for most Android 7.0 tests. The upgrade appears to
finally resolve bug 1534732, improves reftest performance dramatically, and
allows us to reduce reftest "fuzz" for many tests.
marionette tests are excluded because they intermittently fail with network
errors (address in use); these tests are near end-of-life, so I don't think
this issue is worth investigating, but I'll file a follow-up bug to record
the issue.
web-platform tests are excluded because they are not very stable on the
existing emulator, making it difficult to compare results. I will file a
follow-up and work with :maja_zf to see if they can be upgraded soon.
Differential Revision: https://phabricator.services.mozilla.com/D36256
--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
This patch adds a `known_intermittent_statuses` attribute to the `StatusHandler`
class, allowing it to keep a count of expected intermittents for future use.
Additionally, known intermittents are not recorded as `unexpected_statuses` but
are recorded as `expected_statuses`.
testing/mozharness/mozharness/mozilla/structuredlog.py is directly affected by
this change and has been updated to also reflect `known_intermittent_statuses`.
However, it may require a test to be written to check this addition.
The `StatusHandler` test has been added to, ensuring this patch works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D33086
--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
RaptorErrorList now includes HarnessErrorList and regular expressions for Error and Critical log levels.
Differential Revision: https://phabricator.services.mozilla.com/D32983
--HG--
extra : moz-landing-system : lando
The bogomips check is now catching and rejecting instances in the range 3000-4000,
which were not seen earlier. I think the difference is that they are being run in
powersave mode now. At any rate, these instances have normal MHz, so I think they
probably provide normal performance over the long run, and need not be rejected:
adjusting the threshold accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D33646
--HG--
extra : moz-landing-system : lando