It was added in bug 1575760 and turns out to be causing a lot more
problems than anticipated.
However, the previous status quo is also not ideal, so we do
auto-generate .cargo/config.in instead, with a little trick that allows
to just copy it to .cargo/config instead of how individual scripts would
previously manually preprocess it.
Differential Revision: https://phabricator.services.mozilla.com/D46138
--HG--
extra : moz-landing-system : lando
Increase max-run-time for linux and windows ccov browser-chrome tasks to avoid
frequent task timeouts. (linux platform name was incorrect in existing configuration).
I would prefer to see shorter max-run-time but there may be no alternative for
these tasks.
Differential Revision: https://phabricator.services.mozilla.com/D46486
--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
This task has been added to create all the missing cold tests for mobile websites.
Differential Revision: https://phabricator.services.mozilla.com/D45634
--HG--
extra : moz-landing-system : lando
ML now means Machine Learning for most people, we should be more explicit for new comers
Differential Revision: https://phabricator.services.mozilla.com/D45488
--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
The aarch64 cross toolchain is unused otherwise. The aarch64-linux
builds also exist for the express purpose of eventually standing up some
kind of fuzzing/ccov build, so we might as well start using a toolchain
that supports those use cases.
Differential Revision: https://phabricator.services.mozilla.com/D45210
--HG--
extra : moz-landing-system : lando
This includes a fix for the dist server people will need to efficiently
distribute builds. The version required by configure is not bumped with this
change, as this difference is crucial to the server but not relevant to the
client.
Differential Revision: https://phabricator.services.mozilla.com/D45230
--HG--
extra : moz-landing-system : lando
With the migration from AWS to GCP, we also need to migrate sccache
buckets from S3 to Google Storage.
The problem is how we deal with regions, since there isn't an exact
correspondence on the region names between the two cloud providers.
To make the transition smoother, docker-worker (and soon generic-worker)
provides a new environment variable called TASKCLUSTER_WORKER_LOCATION,
with information about the cloud provider the task is running on. Using
this new variable, we configure sccache to use the corresponding storage
service of the cloud provider where the task runs.
The bucket names in Google Storage are shorter because GCS imposes a
limit of 30 characteres for the names.
Ref: https://github.com/taskcluster/taskcluster-rfcs/pull/148/files
Differential Revision: https://phabricator.services.mozilla.com/D44845
--HG--
extra : moz-landing-system : lando
I found that I did not restore the `set -e` flag after temporarily disabling it in the debian10-specific piece of experimental code in `test-linux.sh`, and this caused a bunch of my try pushes to register as successful despite having multiple unexpected failures.
Differential Revision: https://phabricator.services.mozilla.com/D44774
--HG--
extra : moz-landing-system : lando
Increase max-run-time to avoid intermittent failures due to variance in robustcheckout
performance.
Differential Revision: https://phabricator.services.mozilla.com/D45200
--HG--
extra : moz-landing-system : lando
Adds command line option for developers to run tests against experimental debian 10 image (from D42597).
This is an experimental flag and will be removed once debian 10 image is used for production CI tests.
Differential Revision: https://phabricator.services.mozilla.com/D44236
--HG--
extra : moz-landing-system : lando
Without these scopes, we can't build Android configs from interactive
tasks, because we can't fetch the NDK and SDK from their toolchain tasks.
Differential Revision: https://phabricator.services.mozilla.com/D45048
--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
Browsertime needs these to produce videos, and to invoke Chrome, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D43698
--HG--
extra : moz-landing-system : lando
This patch prevents the job-defaults run-on-projects setting from overriding the task-specific run-on-projects setting. It also fixes a minor error in raptor-fennec.yml.
Differential Revision: https://phabricator.services.mozilla.com/D44877
--HG--
extra : moz-landing-system : lando
