Stop running all Raptor tests that run against Fennec. Raptor tests running
against geckoview and geckoview products continues.
Differential Revision: https://phabricator.services.mozilla.com/D44511
--HG--
extra : moz-landing-system : lando
The recent increase was not quite enough: Allow another 30 minutes for linux64
ccov browser-chrome.
Differential Revision: https://phabricator.services.mozilla.com/D46787
--HG--
extra : moz-landing-system : lando
Our build toolchains don't contain libstdc++ headers for aarch64, so our
aarch64 builds rely on whatever libstdc++ headers the system has
installed. To bring in newer headers on our aarch64 builds, then, we
need to update the system images for those builds, which this patch does.
Depends on D45861
Differential Revision: https://phabricator.services.mozilla.com/D45862
--HG--
extra : moz-landing-system : lando
On older Debian versions, `libstdc++-$VERSION-dev` is implicitly brought
in by other development packages. On newer versions, this dependency
has been removed. Let's go ahead and explicitly declare which version
we want to install for each Debian version.
Differential Revision: https://phabricator.services.mozilla.com/D45861
--HG--
extra : moz-landing-system : lando
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
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
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
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
The `./mach try {fuzzy,chooser}` commands now support a `--visual-metrics-jobs`
option which can be used to pass the job descriptions to the visual-metrics
task.
Differential Revision: https://phabricator.services.mozilla.com/D41878
--HG--
extra : moz-landing-system : lando
This new task fetches the visualmetrics.py script from the
github.com/mozilla/browsertime repository and runs it in parallel for the
specified jobs. Jobs are specified in a JSON blob passed through to the task in
an environment variable. A follow up patch specifies a command line argument to
make this configuration available to `./mach try {fuzzy|chooser}`
Differential Revision: https://phabricator.services.mozilla.com/D41052
--HG--
extra : moz-landing-system : lando
The `./mach try {fuzzy,chooser}` commands now support a `--visual-metrics-jobs`
option which can be used to pass the job descriptions to the visual-metrics
task.
Differential Revision: https://phabricator.services.mozilla.com/D41878
--HG--
extra : moz-landing-system : lando
This new task fetches the visualmetrics.py script from the
github.com/mozilla/browsertime repository and runs it in parallel for the
specified jobs. Jobs are specified in a JSON blob passed through to the task in
an environment variable. A follow up patch specifies a command line argument to
make this configuration available to `./mach try {fuzzy|chooser}`
Differential Revision: https://phabricator.services.mozilla.com/D41052
--HG--
extra : moz-landing-system : lando
This picks up 0a1d495478d8ed1a94fc77b9dbb428b7e0372588 needed by
Tor for the updater.
Differential Revision: https://phabricator.services.mozilla.com/D44535
--HG--
extra : moz-landing-system : lando
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.
Differential Revision: https://phabricator.services.mozilla.com/D41251
--HG--
extra : moz-landing-system : lando
Major changes:
- add new directory under `taskcluster/docker` named `linux-test` that will supersede `desktop1604-test` when the appropriate time comes
- add new job to support building this docker image in `kind.yml`
- create a setup script similar to `ubuntu1604-test-system-setup.sh` tailored to debian 10
- modify `test-linux.sh` to support switching based on detected distribution; this is important due to differences in how pulseaudio is handled
Minor changes:
- modify logic in the mochitest harness in order to support gstreamer0.1, 0.10 and 1.0 notations (varies slightly from ubuntu1604)
Goal:
- this patch will place all the necessary piping to enable debian 10 when needed
- with the required debian 10 files and scripts recorded in tree, it is easier to have other developers quickly enable debian 10 to run tests on try
Differential Revision: https://phabricator.services.mozilla.com/D42597
--HG--
extra : moz-landing-system : lando
The mar utility stores MOZ_APP_VERSION as the default Product Version for mar creation. So mar should be rebuilt whenever the milestone changes.
Differential Revision: https://phabricator.services.mozilla.com/D44089
--HG--
extra : moz-landing-system : lando
The mar utility stores MOZ_APP_VERSION as the default Product Version for mar creation. So mar should be rebuilt whenever the milestone changes.
Differential Revision: https://phabricator.services.mozilla.com/D44089
--HG--
extra : moz-landing-system : lando
This causes the unit tests in browser/components/newtab to be run by Phabricator each time someone uploads a patch that touches those directories. Once they've run (it can often take an hour or so to do the required Linux PGO build first), they will be visible as node(newtab) in the page linked to by "Treeherder Jobs" on the main review page.
Differential Revision: https://phabricator.services.mozilla.com/D43983
--HG--
extra : moz-landing-system : lando
Adds unit tests for the Home page code and Messaging System code in browser/component/newtab into treeherder/try automation. Currently at Tier 2, should move to Tier 1 before long.
Differential Revision: https://phabricator.services.mozilla.com/D43562
--HG--
extra : moz-landing-system : lando
Changes:
- run `awsy` related tests on all platforms except for `mozilla-esr.*`.
Differential Revision: https://phabricator.services.mozilla.com/D43133
--HG--
extra : moz-landing-system : lando
There was quite a bit of discussion of this in `#build` on IRC,
and the consensus was that geckodriver should be built as a
stand-alone Rust crate and not as part of Firefox/Gecko (say, as a new
--enable-project target). This follows that approach, and the
expression, modeled off of cbindgen but updated to cross compile from
a Linux host to all targets, is pretty straight-forward.
A sparse profile would be nice, but the way that the Gecko Cargo
workspace works means that the profile must accumulate Rust code from
many locations.
If we want to, eventually testing/geckodriver can be removed from the
top-level Rust workspace, the geckodriver-signing tasks migrated to
these toolchain tasks, consumers migrated to the signing tasks, and
geckodriver removed from the "common" test archive.
Differential Revision: https://phabricator.services.mozilla.com/D43646
--HG--
rename : taskcluster/scripts/misc/vs-setup.sh => taskcluster/scripts/misc/vs-setup32.sh
extra : moz-landing-system : lando
