We need to install a new enough binutils for both of these jobs and
ensure that it's properly found on the linux job.
Differential Revision: https://phabricator.services.mozilla.com/D23678
--HG--
extra : moz-landing-system : lando
History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
Firefox itself has moved on to GCC 6.x; we can move our toolchains along too.
Differential Revision: https://phabricator.services.mozilla.com/D22883
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
(without the dash, because I want *this* push to build)
This filters out all tasks, but that means that several things will still run:
* docker images and tasks they depend on (debian packages)
* always_run tasks (various python-y things)
Differential Revision: https://phabricator.services.mozilla.com/D23020
--HG--
extra : moz-landing-system : lando
Updating clang indicates that 32-bit compilation is substantially longer
than 64-bit compilation, perhaps due to swapping. The compilation
process is hitting the timeout limit shortly before the compilation
process completes (~3681/3695 tasks according to ninja).
We could tweak our clang build process to accommodate this job. But we
don't support building on 32-bit Windows anymore, and we don't produce a
32-bit Windows clang either. So we shouldn't support a 32-bit Windows
clang-tidy job either. Let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D23517
--HG--
extra : moz-landing-system : lando
History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Depends on D22883
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
Firefox itself has moved on to GCC 6.x; we can move our toolchains along too.
Depends on D22882
Differential Revision: https://phabricator.services.mozilla.com/D22883
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Depends on D22881
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
A newer clang may require newer binutils than the system provides, so we
should ensure that we provide just such a binutils.
Differential Revision: https://phabricator.services.mozilla.com/D23393
--HG--
extra : moz-landing-system : lando
Linux64/debug mochitest-dt chunks are increased to 16 to provide more capacity in
reasonable run time. For ccov, mochitest-dt-12 sometimes still runs > 90 minutes,
so ccov max-run-time is increased to 2 hours.
Differential Revision: https://phabricator.services.mozilla.com/D23309
--HG--
extra : moz-landing-system : lando
This will allow to use bash constructs in pre-diff-commands, like
`{a,b}`.
Depends on D23075
Differential Revision: https://phabricator.services.mozilla.com/D23076
--HG--
extra : moz-landing-system : lando
This is due to an incompatability somewhere between JaCoCo and
default interface methods.
Depends on D23016
Differential Revision: https://phabricator.services.mozilla.com/D23017
--HG--
extra : moz-landing-system : lando
This task extracts the binary of geckodriver from the
common test package and stores it into its own artifact.
For now this task is only run after Nightly build tasks
on supported platforms..
Differential Revision: https://phabricator.services.mozilla.com/D23094
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
Reinsert awscli for partials, which is needed for caching. Also update packages and fix the metrics recording
Differential Revision: https://phabricator.services.mozilla.com/D22942
--HG--
extra : moz-landing-system : lando
Reinsert awscli for partials, which is needed for caching. Also update packages and fix the metrics recording
Differential Revision: https://phabricator.services.mozilla.com/D22942
--HG--
extra : moz-landing-system : lando
Most of our builds use libstdc++ compat, so they don't care much what
the custom toolchains we use are compiled with. The plain builds, on
the other hand, attempt to stick as closely as possible to a "local"
developer experience, and so don't set up libstdc++ compat. Since we
want to transition to our clang binaries being compiled with gcc 6, we
need a base system image that contains gcc 6 runtime libraries by
default. Debian 9 is just such a system.
Differential Revision: https://phabricator.services.mozilla.com/D22393
--HG--
extra : moz-landing-system : lando
Bug 1486071 intended to fix this, but while the tasks are setup to
restart on exit status 100, there are multiple failure cases where
snapshot.debian.org doesn't respond and the exit status is not 100.
One is dget, when downloading package sources from snapshot.debian.org.
Eventually, those should move to fetch tasks, but in the meantime, we
bubble up get errors with an exit code 100.
mk-build-deps wraps a call to apt-get install, but doesn't return the
exit code that apt-get returns when apt-get returns one. It makes it
hard to distinguish the error modes, but mk-build-deps is unlikely to
fail on anything else than apt-get. Not all apt-get failures would be
due to snapshot.debian.org availability, but that's a tradeoff we
decided was okay in bug 1486071.
Differential Revision: https://phabricator.services.mozilla.com/D22269
--HG--
extra : moz-landing-system : lando
Currently the scopes are handled in some test-specific code. However, there is
logic not to be in generic code.
Differential Revision: https://phabricator.services.mozilla.com/D22447
--HG--
extra : moz-landing-system : lando
This slightly decreases the amount of code that needs to know how to determine this.
Differential Revision: https://phabricator.services.mozilla.com/D22446
--HG--
extra : moz-landing-system : lando
arthur.iakab
Nathan Froyd
Ionut Goldan
Gian-Carlo Pascutto
Nathan Froyd
Dustin J. Mitchell
Gurzau Raul
Mike Hommey
Tom Prince
Chris Hartjes
Geoff Brown
marian.raiciof
James Willcox
Henrik Skupin
Joel Maher
Jason Laster
alexandru.ionescu
Andreea Pavel
Simon Fraser
Chris Manchester
Csoregi Natalia
Kartikaya Gupta
Narcis Beleuzu