This patch changes the browsertime archive built as a toolchain from a .zip archive to a .tar.bz2 archive to prevent the large amount of verbose unpacking output we currently see.
Differential Revision: https://phabricator.services.mozilla.com/D50995
--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
Check the return code of write() to determine if the output line has actually been written completely; if not, write the remainder.
Tests suggest that incomplete writes are possible when the buffer exceeds a few thousand bytes. Very long log lines are unusual but this is important for cases like reftest failures where an encoded screenshot is dumped to the log.
Differential Revision: https://phabricator.services.mozilla.com/D48218
--HG--
extra : moz-landing-system : lando
This patch enables the iris test suite to run in CI against Windows and Linux shippable builds on mozilla-central and try. The framework is in place for Iris to run against MacOS in CI, but it is currently disabled while bootstrapping issues are sorted out.
Linux uses a new docker image based on the debian10-test parent image that installs preinstalls most of Iris's dependencies. Windows installs a few dependencies using the scoop package manager. Both then install the rest of the python dependencies via pip.
This adds a new toolchain artifact to fetch the iris_firefox git repo without touching the outside network.
Differential Revision: https://phabricator.services.mozilla.com/D41638
--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
Using git-archive for the fetch task means that we don't get the
submodules of a git repository included in the archive. There isn't a
straightforward way to get submodules from a bare repo included with
git-archive, so instead we can simply clone & checkout with
--recurse-submodules and then use a standard tar command to bundle up
the tree.
Adding --recurse-submodules to the commands has no effect on a repo
without submodules, so we can add it to all invocations for simplicity.
Differential Revision: https://phabricator.services.mozilla.com/D46827
--HG--
extra : moz-landing-system : lando
python's `urllib.request.urlopen(url)` can fail when a system doesn't know how to verify a ca certificate. this patch makes use of the cafile provided by the `certifi` module, if/when it is installed, to verify certificates.
Differential Revision: https://phabricator.services.mozilla.com/D47044
--HG--
extra : source : 92b9ffc8f37ddd16ca3f426d64df059eea38d5fa
python's `urllib.request.urlopen(url)` can fail when a system doesn't know how to verify a ca certificate. this patch makes use of the cafile provided by the `certifi` module, if/when it is installed, to verify certificates.
Differential Revision: https://phabricator.services.mozilla.com/D47044
--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
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
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
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
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
Maybe back when .cargo/config.in was added, the directory indicated for
vendored crates needed to be absolute. That is at least not the case
with the current supported versions of rust.
The current setup has a few caveats:
- .cargo/config.in has shown to become stale (it currently contains
multiple unused entries)
- non-gecko build tasks have to generate a .cargo/config on their own if
they want to use vendored crates
- in turn, non-gecko build tasks that don't, may unknowingly get their
dependencies from crates.io (see the recent attempt at moving
geckodriver builds to a separate task).
By checking in a .cargo/config file, we can alleviate the last two, but
that comes at the price of `cargo update` not wanting to act when
.cargo/config exists, because of the source replacement configuration.
But rust vendor gently generates a suitable configuration on its own, so
we can use that to generate a .cargo/config automatically. Which
addresses the first caveat of the current setup. That leaves us with
`cargo update` not working out of the box, but that just requires people
running it to manually remove .cargo/config first. Which is arguably
what rust wants you to do in the first place. It's kind of incidental
that we started with a .cargo/config.in rather than .cargo/config.
Now, while a simple .cargo/config works, that's not enough for the case
where the objdir doesn't live inside the source directory. In that case
cargo looks for the configuration from the objdir, and fails to find it.
So we still need a .cargo/config.in, which we generate with a little
trick.
Differential Revision: https://phabricator.services.mozilla.com/D43012
--HG--
rename : .cargo/config.in => .cargo/config
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
MANUAL PUSH: to allow docker images to build without closing autoland
Differential Revision: https://phabricator.services.mozilla.com/D41038
--HG--
extra : rebase_source : 60ae00549917411d1839b6e3f8e6ae962d217470
extra : amend_source : a2531b115f5732345f8c34c88669428510d100a4
Gregory Mierzwinski
Matt Brandt
Daniel Varga
Andi-Bogdan Postelnicu
Edwin Takahashi
Geoff Brown
David Major
Wes Kocher
Steve Fink
Nick Alexander
Jamie Nicol
Brindusan Cristian
Mike Shal
Rob Thijssen
Noemi Erli
Mike Hommey
Chris Manchester
Dustin J. Mitchell
Razvan Maries