Changes:
Run `isort` and `autopep8` for automatic fixes of import and code formatting.
Replace deprecated imports with updated imports for python3 and wrap the attempt in a `try/except` clause for backwards compatibility.
Wherever possible, directly import the object with same name between python2/python3 versions to simplify the main code (eg. HTTPError).
Differential Revision: https://phabricator.services.mozilla.com/D52791
--HG--
extra : moz-landing-system : lando
Avoid intermittent failures: "AttributeError: 'RaptorOutputParser' object has no attribute 'tbpl_status'".
All mozharness OutputParser-derived classes normally initialize these variables; I neglected to do
so in bug 1592681.
Differential Revision: https://phabricator.services.mozilla.com/D52675
--HG--
extra : moz-landing-system : lando
Most mozdevice access in mozharness was already encapsulated in try blocks, with only the
shell_output() case neglected, consistent with the observed intermittent failures.
Differential Revision: https://phabricator.services.mozilla.com/D52879
--HG--
extra : moz-landing-system : lando
Slightly reorganize file structure to make copying files over easier. Needs to land in conjunction with https://github.com/mozilla/geckoview/pull/94, which should land first.
Differential Revision: https://phabricator.services.mozilla.com/D48564
--HG--
rename : mobile/android/docs/geckoview/Gemfile => mobile/android/docs/Gemfile
rename : mobile/android/docs/geckoview/_config.yml => mobile/android/docs/_config.yml
extra : moz-landing-system : lando
Slightly reorganize file structure to make copying files over easier. Needs to land in conjunction with https://github.com/mozilla/geckoview/pull/94, which should land first.
Differential Revision: https://phabricator.services.mozilla.com/D48564
--HG--
rename : mobile/android/docs/geckoview/Gemfile => mobile/android/docs/Gemfile
rename : mobile/android/docs/geckoview/_config.yml => mobile/android/docs/_config.yml
extra : moz-landing-system : lando
Upgrade the emulator used by xpcshell tests to 29.2.1, the same version used
by all other android tests.
We have delayed this upgrade because of intermittent failures seen on the new
emulator not seen previously - bug 1568063. After the packet.net upgrade to
Ubuntu 18.04, try runs with the new emulator show that bug 1568063 persists
but has less impact than the intermittent failures it resolves: More tests
pass consistently with the new emulator than with the old.
Differential Revision: https://phabricator.services.mozilla.com/D52851
--HG--
extra : moz-landing-system : lando
Replace the existing regex-based hack for recognizing reftest reference files
with a reliable method based on the reftest manifest.
Differential Revision: https://phabricator.services.mozilla.com/D51172
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: (a) This patch will cause a ton of toolchain rebuilds, and might as well do that on central right now rather than autoland, and (b) We want to test the new Taskcluster instance today, and will be testing THAT on m-c, so we'll need this patch on m-c before we can test the new cluster as well.
tooltool at present needs to support production (legacy cluster) but its auth system is tied to that cluster.
Which means that using tooltool in the new cluster ahead of TCW is harder. We have swapped the credentials for the tooltool staging deployment to use the new tc cluster, so when we're using the taskcluster proxy we need to have it swap between legacy and new tooltool url's depending on which cluster (ROOT_URL) we're using.
This patch is intended to be ok to land on production code today, and could be backed out after the TCW when production tooltool will be configured to work with the firefox-ci cluster itself.
Differential Revision: https://phabricator.services.mozilla.com/D52089
Replace the existing regex-based hack for recognizing reftest reference files
with a reliable method based on the reftest manifest.
Differential Revision: https://phabricator.services.mozilla.com/D51172
--HG--
extra : moz-landing-system : lando
This is the first part of a patch that adds chrome support to raptor-browsertime.
In this patch, a get_browser_meta function is added which returns the name and version of the browser being tested. This version will then be used (in part 3) in the variable passed in through --browsertime-chromedriver (only when running not locally, or if we find {} in the string).
Differential Revision: https://phabricator.services.mozilla.com/D48895
--HG--
extra : moz-landing-system : lando
This minor optimization is easily implemented: If there are no tests to verify, call fatal(0).
However, I encountered a minor obstacle: If the task exits before creating the upload directory,
the task fails, regardless of exit value; the remaining changes overcome this by creating the
upload directory earlier.
Differential Revision: https://phabricator.services.mozilla.com/D51684
--HG--
extra : moz-landing-system : lando
Having a distinction between -chunked and not adds unnecessary complexity. It's
possible to simply remove them because:
1. The mozharness definitions for 'jittest' and 'jittest-chunked' are
identical, so it is literally not serving any purpose.
2. The definitions for 'mochitest' only add either '--chunk-by-dir' or
'--chunk-by-runtime'. Both of these are no-ops in the mochitest harness
unless '--total-chunks' is also supplied. Therefore, if we ever use these
suites without chunking (which I don't think we do anyway), then it'll
still work fine as those options won't have any affect.
Differential Revision: https://phabricator.services.mozilla.com/D51173
--HG--
extra : moz-landing-system : lando
Android TV has appropriate configuration, so updating these defaults makes
no practical difference, but I think it looks a little more modern.
Differential Revision: https://phabricator.services.mozilla.com/D50986
--HG--
extra : moz-landing-system : lando
On android-hw, if it looks like the app to be installed is already installed, uninstall it
first. I don't think this is a possibility on android-em, so I am only changing the hardware
script.
Differential Revision: https://phabricator.services.mozilla.com/D50224
--HG--
extra : moz-landing-system : lando
Changes:
- for Debian platforms, do not initialize pulseaudio in `test-linux.sh`; instead initialize pulseaudio if required in the `desktop_unittest.py` mozharness script
Differential Revision: https://phabricator.services.mozilla.com/D45768
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
This fixes several bugs, in particular the GL_INVALID_OPERATION when blitting
between 3d textures, so will allow us to enable some tests.
Differential Revision: https://phabricator.services.mozilla.com/D47628
--HG--
extra : moz-landing-system : lando
To support NDK r20, wrench needs to be built with a more recent, upstream
(though still unpublished) version of cargo-apk. This has some consequences
which have been adjusted for:
* Gradle is no longer required to build wrench.
* The output apk file paths have changed.
* The apks are now signed automatically.
* The default activity name has changed.
* Android permissions must be explicitly requested.
* We must ensure winit is built with a matching version of android_glue.
Differential Revision: https://phabricator.services.mozilla.com/D47129
--HG--
extra : moz-landing-system : lando
This patch adds google chrome release tests for windows10-64, windows7-32, linux64, and macosx. It will run anywhere chromium is currently running, and uses the same settings as chromium for tier, max-run-time, etc.. All chromium test tasks will remain as they are - they will be run in a cron task in the future.
Differential Revision: https://phabricator.services.mozilla.com/D45385
--HG--
extra : moz-landing-system : lando
Removes all the robocop test files and most robocop support. @RobocopTarget annotations and some build configuration is intentionally left untouched at this time, in case there is additional risk involved; a good task for follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D45671
--HG--
extra : moz-landing-system : lando
Mozharness no longer drives building with PGO; it is all handled in
Taskcluster and the build system.
Depends on D46070
Differential Revision: https://phabricator.services.mozilla.com/D46071
--HG--
extra : moz-landing-system : lando
We no longer run robocop, marionette, or mochitest-chrome on Android and can remove
the associated support.
Incidentally, removal of mochitest-chrome support fixes bug 1578256.
Differential Revision: https://phabricator.services.mozilla.com/D46073
--HG--
extra : moz-landing-system : lando
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
This commit prepares the decks for turning specific Raptor tasks into
Raptor + browsertime tasks. The `--browsertime` flag to `mach try
...` flips the switch; eventually, the Raptor harness will recognize
the `--browsertime` flag and use browsertime to perform the pageload
measurements.
To run browsertime, we need:
1) Node.js
2) the browsertime `node_modules` (provided by the
`toolchain-browsertime` task)
3) ffmpeg (for producing videos from captured frames)
4) chromedriver (in the future, when targeting Chrome/Chromium)
5) geckodriver (provided by the `toolchain-*-geckodriver` tasks)
6) `PATH` configured
This commit arranges those things.
Since the configuration varies by test platform, and eventually we
expect the changes implemented by the flag to be moved into YAML task
definitions, we elect to use `by-test-platform` conditionals as much
as possible. The end expression is pleasant, thanks to
`evaluate_keyed_by`.
Handling PATH, however, is a rabbit hole. At this time, it's not
possible to use `fetch` task repackaging, because `releng-hardware`
doesn't support `zstandard` (Bug 1576244) and there's no appetite to
avoid `zstandard` entirely (Bug 1576698). Generally PATH is
configured using `mozharness` configuration files, which can execute
arbitrary Python and configure the PATH only for browsertime jobs.
However, the Raptor mozharness script itself runs the Raptor harness
in a stripped down environment, throwing away modifications to PATH.
It's not clear what impacts changing that has, so we leave it alone,
and add a `--browsertime-ffmpeg` flag and custom handling in the
Raptor harness. This can transition smoothly into a browsertime flag
(so that the PATH doesn't need to be set at all) and into a unified
interface for Raptor and `mach browsertime` to configure the
browsertime execution environment.
Differential Revision: https://phabricator.services.mozilla.com/D38781
--HG--
extra : moz-landing-system : lando
Stop running all Fennec functional (non-performance) tests:
- stop running all Android 4.3 tests
- switch android-em-7 cppunit and android-hw jittest from the Fennec apk to the
geckoview apk (no difference in behavior expected)
- stop running Android 7.0 marionette tests, since they also run against Fennec
- remove android-em-4.* references from taskcluster configs
- remove android instance: extra-large references from taskcluster configs,
since they only affect aws, which is no longer used for Android
Android-hw raptor tests running against Fennec remain; I will prepare a separate
patch for those.
Differential Revision: https://phabricator.services.mozilla.com/D43684
--HG--
extra : moz-landing-system : lando
This requires generalizing the existing flags from paths to possibly
being paths. The `os.path.expandvars` allows to refer to
`MOZ_FETCHES_DIR` symbolically in the build scripts (which aren't
invoked by the shell before execution, leaving us to expand shell
variables).
Differential Revision: https://phabricator.services.mozilla.com/D41604
--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
Android artifacts (GeckoView AARs, GeckoViewExample (and Fennec) APKs)
require native libraries (`libxul.so`) and an omnijar (`omni.ja`).
These are produced by `mach package` (really, the `stage-package`
target). Engineers essentially never want a build without a package
for mobile/android. This adds mobile/android-only tiers that run
`mach package` and then `mach android assemble-app`. The latter
consumes `libxul.so` and `omni.ja` to produce _all the things_
relevant to GeckoView engineers.
Differential Revision: https://phabricator.services.mozilla.com/D41450
--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
Changes:
- if an error is raised in the vendored `shutil` when copying/moving a file to the target, log that error as a `WARNING`, not an `ERROR`
Differential Revision: https://phabricator.services.mozilla.com/D40914
--HG--
extra : moz-landing-system : lando
Build metrics where the instance type matters, like build times, are
important to keep track of per instance type, but sccache stats are hit
rates, number of non-cacheable requests, and number of write errors to
the cache, none of which are dependent on the instance type.
Differential Revision: https://phabricator.services.mozilla.com/D41143
--HG--
extra : moz-landing-system : lando
This patch fixes four things at once:
(1) Consolidate supporting raptor measurements into one PERFHERDER_DATA output per type. For example, with this change, all power data will be grouped into one PERFHERDER_DATA output.
(2) Output perfherder-data-<DATA_TYPE>.json for each supporting measurement instead of overwriting perfherder-data.json which contains the regular raptor test results.
(3) Take an average of the supporting measurements when particular unit's are specified. In this case, the '%' unit makes us take the average instead of the sum of the measurements.
(4) Remove the redundant test name entry that prefixes all power subtest entries.
Differential Revision: https://phabricator.services.mozilla.com/D40667
--HG--
extra : moz-landing-system : lando
API lint is arguably the most valuable lint of all, but it's also hard
to fit into the Phab ecosystem, since there's no place to hang the
"API hash not correct" message in the case when the hash hasn't been
updated at all. Therefore, this commit doesn't convert it. See also
https://github.com/mozilla-mobile/gradle-apilint/issues/61 for adding
file/line information to API lint.
Differential Revision: https://phabricator.services.mozilla.com/D35277
--HG--
rename : mobile/android/config/mozconfigs/android-api-16-frontend/nightly => mobile/android/config/mozconfigs/android-api-16/nightly-android-lints
extra : moz-landing-system : lando
Add functionality for being able to send extra parameters for the test_url query of a test, directly from a taskcluster config.
Also, the PR adds logic in the `setup-raptor` taskgraph transform for dynamically changing the subset of youtube-playback tests based on the platform and project
Differential Revision: https://phabricator.services.mozilla.com/D39006
--HG--
extra : moz-landing-system : lando
The goal is to configure browsertime in Raptor in two ways:
1) locally, just like `mach browsertime` does;
2) in automation, at taskgraph creation time, using fetches and
mozharness suite artifacts (for geckodriver).
It's possible for this to be done using mozharness config settings but
using command line options is more explicit and more likely to be easy
to remove later if and when we transition to a browsertime-specific
mozharness script.
Differential Revision: https://phabricator.services.mozilla.com/D38776
--HG--
extra : moz-landing-system : lando
The existing code parses an argument with 'chrome' in its name
incorrectly. That is, `--arg-with-chrome value` will make the old
code think the `--app` is 'chrome', which is not correct.
Argument parsing is subtle enough that we rely on `argparse` (which is
already imported and thus known to be available).
Differential Revision: https://phabricator.services.mozilla.com/D39415
--HG--
extra : moz-landing-system : lando
With all mozharness-based jobs now using run-task (except aarch64
windows, see bug 1557614), and thus fetch-content, the FetchesMixin
mixin should not be required anymore.
Differential Revision: https://phabricator.services.mozilla.com/D39108
--HG--
extra : moz-landing-system : lando
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
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
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--HG--
extra : moz-landing-system : lando
Previously we would silently change the value of "e10s" from False to True.
This can cause confusion and lead people to falsely think mochitest-chrome/a11y
work with e10s (they do not).
Now we explicitly error out in this case. This might be slightly less
convenient for the developer (e.g they might need to re-run the command), but
the downside of needing to rerun a test command is less than the risk of
misunderstanding what is being tested.
Note: when running |mach test| or |mach mochitest| on a directory that contains
both chrome/a11y and another suite, we'll still do the right thing and
implicitly set "e10s=False".
Differential Revision: https://phabricator.services.mozilla.com/D28538
--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
I still haven't managed to verify this on try, but it seems like the best
explanation for the timeouts.
Differential Revision: https://phabricator.services.mozilla.com/D28762
--HG--
extra : moz-landing-system : lando
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--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
Edwin Takahashi
Geoff Brown
Stephen Donner
Mihai Alexandru Michis
Emily Toop
Andreea Pavel
Marian Raiciof
Tom Prince
Dorel Luca
octavian.negru
Justin Wood
Gregory Mierzwinski
Ionut Goldan
Andrew Halberstadt
Sebastian Hengst
Tarek Ziadé
Sylvestre Ledru
Wes Kocher
Brian Grinstead
ShantanuVerma
Nick Alexander
Mike Conley
Jamie Nicol
Andrew Erickson
Geoff Lankow
Mike Shal
Junior Hsu
Mike Hommey
Hamzah
Alexandru Irimovici
Cosmin Sabou
Bob Clary
Nick Thomas
Aki Sasaki
Byron Campen [:bwc]
Maja Frydrychowicz
Kartikaya Gupta
Rok Garbas
Alexandre Poirot
James Graham
Nikki Sharpley
Johan Lorenzo
Chris Hartjes
Gijs Kruitbosch
Florin Strugariu
Noemi Erli
Rob Lemley
Chris Manchester
alexandru.ionescu
Csoregi Natalia
Aaron Klotz
Joel Maher
Henrik Skupin
Ben Hearsum
Rob Wood
Daniel Varga
Bogdan Tara