We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
They were disabled in bug 1370129 because there were no use cases for them, but
there are use-cases for at least the linux64 ones :)
Let me know if you want me to enable them everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D30797
--HG--
extra : moz-landing-system : lando
Changes:
- set `macosx64-ccov` tests to 8 chunks (unchanged from m-c)
- set windows and linux `ccov` to 6 chunks (from 8)
- set `linux64.*/debug` to 6 chunks (from 10 and 8)
- set `android-em` to 8 chunks (unchanged)
- set default chunks to be 5 (from 8)
Differential Revision: https://phabricator.services.mozilla.com/D29713
--HG--
extra : moz-landing-system : lando
Changes:
- change the default chunk count to 4 (from 6)
- increase `ccov` chunk count to 8 (from 6)
- `qr` and `linux64/debug` are to remain at 6 chunks
- reduce all other `linux` chunks to 3 (from 6)
- `windows/debug` (including `qr`) chunks reduced to 5 (from 6)
Default chunk count of 4 for Windows and macOS are conservative, leading to sub-20 minute runtimes for most chunks.
Differential Revision: https://phabricator.services.mozilla.com/D29875
--HG--
extra : moz-landing-system : lando
Changes:
- reduced `linux64/debug` chunking to 14 (from 16)
- reduced `linux64-ccov/debug` to 14 (from 16)
- increased `windows64-ccov` to 16 (from 10)
- maintain all non-ccov debug to 8
- maintain all asan to 8
- reduce everything else to 5
Differential Revision: https://phabricator.services.mozilla.com/D30303
--HG--
extra : moz-landing-system : lando
Changes:
- reduced `linux64/debug` chunking to 14 (from 16)
- reduced `linux64-ccov/debug` to 14 (from 16)
- increased `windows64-ccov` to 16 (from 10)
- maintain all non-ccov debug to 8
- maintain all asan to 8
- reduce everything else to 5
Differential Revision: https://phabricator.services.mozilla.com/D30303
--HG--
extra : moz-landing-system : lando
when an instance is terminated while it is still running a task, the generic worker process exits with an interrupt exit code. this change treats such exit codes as an exception which triggers a task retry
Differential Revision: https://phabricator.services.mozilla.com/D29417
--HG--
extra : moz-landing-system : lando
Similar to bug 632954, this disables the Android aarch64 tests on opt
except on try, and instead runs the tests on Android aarch64 pgo builds.
Differential Revision: https://phabricator.services.mozilla.com/D29589
--HG--
extra : moz-landing-system : lando
This makes the rust toolchain artifacts contain the rust stdlib as well,
for use by searchfox. It does bring up the size of the toolchain
artifact slightly - rustc.tar.xz file for the Linux/rust 1.34 job for
example goes from 270483672 bytes to 273803148 bytes (1.23% larger) and
the equivalent android tarball goes from 230503888 to 235698736 bytes
(2.25% larger).
Differential Revision: https://phabricator.services.mozilla.com/D28282
--HG--
extra : moz-landing-system : lando
0.1.21 mishandles cargo package renames, which are a required
feature for Rust 2018 support. The latest version fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D29946
--HG--
extra : moz-landing-system : lando
this change comprises the in-tree changes required to make use of sccache in gcp.
specifically:
- a gcp metadata lookup for availability-zone is added to mozconfig, enabling a build to determine its regional gcp sccache bucket
- the sccache cargo build command is modified to include the gcs feature when the environment contains gcs configuration
note that further changes are required on infra to support sccache use. the required changes already [exist](https://github.com/mozilla-releng/OpenCloudConfig/commit/1d515dc) and are enabled for gcp windows infra, including:
- a json credential file on the build instance filesystem, containing credentials valid for the appropriate scm level bucket for the gcp region
- an `SCCACHE_GCS_KEY_PATH` env variable containing the path to the json credential file
- an `SCCACHE_GCS_RW_MODE` env variable containg the text `READ_WRITE`
- sccache buckets must exist for each region and scm levels 1 & 3
- credentials for scm level 1 buckets **must not** be valid for scm level 3 buckets
on gcp systems which do not contain credential files and the above mentioned env variables (eg gecko-[1-3]-b-linux), sccache should fail gracefully without breaking builds.
Differential Revision: https://phabricator.services.mozilla.com/D29622
--HG--
extra : moz-landing-system : lando
Validate taskgraph parameters using a schema.
Previously, parameters were verified using handwritten comparison to a sample set of parameters.
Switch to using an explicit schema instead.
Differential Revision: https://phabricator.services.mozilla.com/D23756
--HG--
extra : moz-landing-system : lando
When a cron task depends on tasks from the on-push build, wait for the on-push
decision task to complete, and fail if it doesn't complete succesfully.
Differential Revision: https://phabricator.services.mozilla.com/D29429
--HG--
extra : moz-landing-system : lando
This allows us to fix a regression where -sw tasks were scheduled on autoland/inbound.
Differential Revision: https://phabricator.services.mozilla.com/D29259
--HG--
extra : moz-landing-system : lando
This also adds an optimization for the case where there is only one result
(Which is common for actions where `times` defaults to 1)
Differential Revision: https://phabricator.services.mozilla.com/D28889
--HG--
extra : moz-landing-system : lando
Some groups of tasks need to share the same profile data. For example,
Android PGO builds and Android Nightly builds both use the
generate-profile-android-api-16/pgo task for profile data. Previously
this was done with a text substitution, but this is a bit hacky and
doesn't easily scale with different build types.
Allowing use_pgo to be a string means we can just directly point to the
generate-profile task that contains the profile data to be used in a PGO
build.
Differential Revision: https://phabricator.services.mozilla.com/D29247
--HG--
extra : moz-landing-system : lando
Changes:
- disable wholesale the `media-source` subsuite within web-platform-test
Attempts were made to isolate the tests that cause the test harness to lock up with a permission issue on `Ahem.ttf` however the attempts were unsuccessful in isolating the tests to a manageable set. It appears the solution is to simply stop running `media-source` tests on windows10-aarch64 as that seems to have solved the problem in a previous try run.
Differential Revision: https://phabricator.services.mozilla.com/D28778
--HG--
extra : moz-landing-system : lando
This uniformizes the artifact name across platforms. We may want to do
the same for other toolchains, but it bears the question whether xz is
reliably available on users' Windows machines, while it doesn't matter
for rust, since mach bootstrap pulls it with rustup rather than from
automation, contrary to other toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D28780
--HG--
extra : moz-landing-system : lando
Currently, all things running via run-task don't really care that the
current directory is set to /. However, on generic-worker, many things
assume the current directory is the task directory, which varies by
task, and wrapping them with run-task fails because it resets the
current directory.
Differential Revision: https://phabricator.services.mozilla.com/D28018
--HG--
extra : moz-landing-system : lando
Analogously to the existing `linux64-clang-8-android-cross` build, this
build is a linux x86-64 build with runtime library support for aarch64.
Depends on D28405
Differential Revision: https://phabricator.services.mozilla.com/D28406
--HG--
extra : moz-landing-system : lando
We need this image for building clang on machines with arm64
sysroots. (Note that this image *is* a linux x86-64 image, just with
some arm64 cross-compilation packages available.)
Differential Revision: https://phabricator.services.mozilla.com/D28404
--HG--
extra : moz-landing-system : lando
This is not strictly required in mozilla-central, as `mach` sets
the encoding of the output to UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D28861
--HG--
extra : moz-landing-system : lando
If we use the downloaded manifest then any bug that leads to an error in the manifest
may be propogated forward. Instead force the manifest to be built from scratch in CI.
Differential Revision: https://phabricator.services.mozilla.com/D28809
- stop mochitest-headless on windows10
- stop mochitest-headless on linux64/debug
- make mochitest-headless tier-2
- make mochitest-headless run on m-c/try
Differential Revision: https://phabricator.services.mozilla.com/D28715
--HG--
extra : moz-landing-system : lando
It was necessary when it was a different version than win64-rust, but
that's not the case anymore.
Differential Revision: https://phabricator.services.mozilla.com/D28761
--HG--
extra : moz-landing-system : lando
These artifacts are "internal" because we can't redistribute them, but
downloading them into an interactive task is not redistribution.
Differential Revision: https://phabricator.services.mozilla.com/D28656
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--HG--
extra : moz-landing-system : lando
Bug 1474897 changed things such that Windows builds ended up in the
linux/macosx branch. That still works somehow, but ends up breaking when
wrapping with run-task. This change restores the originally intended
command line.
Differential Revision: https://phabricator.services.mozilla.com/D28017
--HG--
extra : moz-landing-system : lando
On windows, the generated path will be close to the path length limits, which
causes `mach try` to fail.
Differential Revision: https://phabricator.services.mozilla.com/D28554
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--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
Currently we have the concept of a "suite" and a "flavour" in our task
configuration. Typically, the "suite" refers to the high-level test harness
like "mochitest" or "reftest", whereas the flavour is more specific, e.g
"browser-chrome-instrumentation" or "crashtest". However the line between suite
and flavour is not applied with any semblance of consistency which results in
inconsistent naming throughout the tree.
This patch gets rid of the concept of "flavours" entirely (at least when it
comes to task configuration). A suite is a type of test run, for example:
- mochitest-plain
- mochitest-devtools-chrome
- mochitest-browser-chrome-instrumentation
- jsreftest
- reftest
- firefox-ui-functional-remote
etc
There is no confusion here between suites and flavours because flavours don't
exist. However, there are a couple of places where we *do* need to know what
"test harness" is used to run a suite. These cases are:
1. For SCHEDULES moz.build rules
2. For the desktop_unittest.py mozharness script which takes arguments like
--mochitest-suite=browser (this is not a compelling use of this information
and should be refactored to work more like the android_emulator_unittest.py
script)
So to get this information, this patch introduces a new concept of a "category"
which is the overall "test harness" that runs the suite. For many suites, the
"category" is identical to the suite name. Unlike flavours, "categories" have
no bearing on how we call or refer to the suite.
Differential Revision: https://phabricator.services.mozilla.com/D27554
--HG--
extra : moz-landing-system : lando
Turns out these suites were hardcoded to be non-e10s in the mochitest harness.
So while it looked like they were working with e10s in treeherder, they were
actually still running with it disabled.
Turning e10s on causes both suites to permafail due to timeouts.
Depends on D28386
Differential Revision: https://phabricator.services.mozilla.com/D28387
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--HG--
extra : moz-landing-system : lando
We are starting to spin off more and more "variants" of test suites. These are
usually just duplicates of our pre-existing tasks, except with an additional
pref set.
Currently there are two variants (serviceworker-e10s and socketprocess-e10s),
but a third will be added soon (fission). This change ensures we handle these
types of requests in a consistent and well defined manner. It also splits tasks
in a loop, so we don't accidentally risk combinatorial explosion.
Variants should typically be reserved for very large changes that will impact
the entire codebase (think e10s).
Differential Revision: https://phabricator.services.mozilla.com/D28061
--HG--
extra : moz-landing-system : lando
We only want to append the action TASK_ID to the task dependencies when the taskGroupId doesn't match, otherwise we hit dup dependency errors.
Differential Revision: https://phabricator.services.mozilla.com/D27994
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following android build configurations:
- android-api-16
- opt
- debug
- android-x86
- opt
- android-x86_64
- opt
- debug
- android-aarch64
- opt
- debug
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
Differential Revision: https://phabricator.services.mozilla.com/D26584
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following macosx build configurations:
- macosx64
- debug
- opt
- shippable/opt
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
Differential Revision: https://phabricator.services.mozilla.com/D26594
--HG--
extra : moz-landing-system : lando
Generating partials from betas doesn't work if we check the 'from' mar channel IDs, as we don't know what's valid for those.
Differential Revision: https://phabricator.services.mozilla.com/D27866
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following linux build configurations:
- linux(32)
- opt
- debug
- shippable
- linux64
- opt
- debug
- shippable
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
- gcp builds on linux for all scm levels are built on the only available gcp linux worker type (at the time of this change): gce/gecko-1-b-linux-32
Differential Revision: https://phabricator.services.mozilla.com/D26490
--HG--
extra : moz-landing-system : lando
Many tasks (release tasks and cached tasks, in particular) should be re-run rather
than retriggered. Instead, make the `retrigger-multiple` action re-run them instead.
Differential Revision: https://phabricator.services.mozilla.com/D27208
--HG--
extra : moz-landing-system : lando
In Bug 1519599, treeherder switched to using add-new-jobs to retrigger jobs, since
there wasn't an action to retrigger multiple jobs. This prevents us from adding logic
to rerun some jobs instead of retriggering them.
This adds a new action that takes input like `add-new-jobs`, but that we can add logic
to handle rerun vs. retrigger in. Additionally, the input it takes is designed
to make Bug 1521032 easier to implement.
Differential Revision: https://phabricator.services.mozilla.com/D27207
--HG--
extra : moz-landing-system : lando
Many tasks (release tasks and cached tasks, in particular) should be re-run rather
than retriggered. Disable retrigger action for those tasks by default.
Differential Revision: https://phabricator.services.mozilla.com/D27206
--HG--
extra : moz-landing-system : lando
In order to prevent retriggers for release tasks, we will cause the `retrigger`
action to rerun instead, so move the cdoe togehter.
Differential Revision: https://phabricator.services.mozilla.com/D27205
--HG--
extra : moz-landing-system : lando
Changes:
- added windows10-aarch64 to the filter for fuzzy, to require `--full` in order to trigger jobs
- return False for any test tasks that contain windows10-aarch64 to prevent users using old try syntax from overwhelming the limited number of hardware
Differential Revision: https://phabricator.services.mozilla.com/D27590
--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
Much of this was already reviewed in D21473 (my test change where I developed the payload modifications and that pointed tests at my test queue).
This change keeps the payload changes from D21473, but points at the new 'real' queues we'll be using.
Differential Revision: https://phabricator.services.mozilla.com/D25009
--HG--
extra : moz-landing-system : lando
Now that 3-tier PGO uses a debian9 image to generate the profile data
(bug 1519424), we no longer see the XDG_RUNTIME_DIR failures in the run
task. The frequency of those errors was the primary blocker for enabling
3-tier PGO in the first place. Since we still see those errors
occasionally in 1-tier PGO, we should switch to the 3-tier model for
Linux.
Differential Revision: https://phabricator.services.mozilla.com/D27326
--HG--
extra : moz-landing-system : lando
ensure high_value_tasks has a default value when we fail to get data from treeherder/seta.
Differential Revision: https://phabricator.services.mozilla.com/D27445
--HG--
extra : moz-landing-system : lando
Now that release promotion is using a hook, all the code for non-hook actions
can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D27204
--HG--
extra : moz-landing-system : lando
Reduce chunks from 8 to 3. Each test task has at least a couple of minutes
of overhead, so fewer chunks improves overall efficiency. At 3 chunks, each
one still completes reasonably quickly (less than 20 minutes).
Differential Revision: https://phabricator.services.mozilla.com/D27339
--HG--
extra : moz-landing-system : lando
Stop running Tss(tp6) and T(bcv) on ccov builds on central -- the remaining 2 cases
missed in the previous bug.
Differential Revision: https://phabricator.services.mozilla.com/D27313
--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
So, instead of fetches['by-test-platform']['fetch'], we have
fetches['fetch']['by-test-platform'].
Differential Revision: https://phabricator.services.mozilla.com/D27227
--HG--
extra : moz-landing-system : lando
While we don't have an actual need for those builds at the moment, there
is work in progress to get fuzzing builds for aarch64, and as the
previous change showed, the build were busted by other changes since
they were put in place. So we might as well enable them, so as to be
aware of bustage when it happens rather than while working on getting
the fuzzing builds up.
Depends on D27035
Differential Revision: https://phabricator.services.mozilla.com/D27036
--HG--
extra : moz-landing-system : lando
I must have written the rust 1.33 patch before I landed the
linux64-aarch64 patches, so when that landed, it lacked the aarch64
target. (it's still there on the rust 1.32 toolchain)
Differential Revision: https://phabricator.services.mozilla.com/D27035
--HG--
extra : moz-landing-system : lando
With tasks able to access the hgmointernal config from a Taskcluster
secret, we can now add functionality to `run-task` to support checking
out from the private hg service. Here we add add a `resolve_checkout_url`
function which takes the base/head repository URLs and determines
whether we should clone from the public or private service, returning
the resolved URL. The function pulls down the secret and checks that
the region the task is executing in is in the set of supported regions.
Then we generate a random number and default to the public service if
the number is lower than our "rate". If all the above conditions are
met, we replace `hg.mozilla.org` with the resolved domain name for the
given region.
We add a call to this function to `collect_vcs_options`, and skip
resolving the private URL if we aren't performing a checkout from
within `run-task`.
Differential Revision: https://phabricator.services.mozilla.com/D25002
--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 also switches it to use the generic toolchain build image, as
it is no longer being used exclusively by mingw builds.
Differential Revision: https://phabricator.services.mozilla.com/D24230
--HG--
extra : moz-landing-system : lando
This is a hack to get around Windows ccov build hangs caused by bug 1195299.
Bug 1543149 will track the investigation of the hang and removal of this hack.
Differential Revision: https://phabricator.services.mozilla.com/D26750
--HG--
extra : moz-landing-system : lando
Run checks done in push-apk in promote-phase, instead of the very last task of the pipeline
Differential Revision: https://phabricator.services.mozilla.com/D26328
--HG--
rename : taskcluster/docker/google-play-strings/Dockerfile => taskcluster/docker/mozapkpublisher/Dockerfile
extra : moz-landing-system : lando
Quick fix for python3 mozbase perma-fail on osx: Use python 3.6 explicitly, rather
than the system default 3.7, which appears to be broken currently (lacking ssl support).
Differential Revision: https://phabricator.services.mozilla.com/D26345
--HG--
extra : moz-landing-system : lando
Ship-it v1 is going away soon and we won't need to create new releases in Ship-it v1 in parallel with Ship-it v2. It's time to prep patches to remove this functionality.
Differential Revision: https://phabricator.services.mozilla.com/D26044
--HG--
extra : moz-landing-system : lando
This imports the changes from wheezy-lts (http://deb.freexian.com/extended-lts/)
and creates a package we install in the debian7-based images (with a
modified version number to work around bug #1419577.
This leaves out debian7-raw and debian7-packages as unpatched, because
of the chicken-and-egg problem.
Depends on D26100
Differential Revision: https://phabricator.services.mozilla.com/D26102
--HG--
extra : moz-landing-system : lando
When docker images use setup_packages.sh, they add apt sources. While we
currently do run apt-get update to pick those new sources, if a package
provided by them is already installed and not explicitly listed in
subsequent apt-get install, they're not going to be upgraded.
Differential Revision: https://phabricator.services.mozilla.com/D26100
--HG--
extra : moz-landing-system : lando
