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
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
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
This is due to a conflicting name in sys path when called from mozharness,
Which we fix by making this mozharness file use absolute imports, and import
from the codecoverage module directly rather than set that directory as
a search path.
Differential Revision: https://phabricator.services.mozilla.com/D32408
--HG--
extra : moz-landing-system : lando
bouncer_thunderbird.py is now at c-c:mozharness/releases/bouncer_thunderbird.py
Differential Revision: https://phabricator.services.mozilla.com/D31387
--HG--
extra : moz-landing-system : lando
There's a failure case where content processes are crashing but no stack trace
is being printed. Test harnesses often rely on the presence of a minidump to
determine whether or not there was a crash, and so in this failure mode report
success (so tasks are staying green).
This adds a new string to mozharness' error logs to make sure the task turns
orange. Note: it does not fix the lack of stack traces.
Differential Revision: https://phabricator.services.mozilla.com/D31635
--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
A new entry was required to map the subsuite name to the mozharness
config name - simple!
Differential Revision: https://phabricator.services.mozilla.com/D31522
--HG--
extra : moz-landing-system : lando
Enable the existing android mozharness support for retrying a task when the
bogomips are insufficient, for packet.net tests. This has worked well for
Android 4.3.
Differential Revision: https://phabricator.services.mozilla.com/D31528
--HG--
extra : moz-landing-system : lando
