There are a few external repos that hold copies of robustcheckout
in various places, mainly on release engineering infrastructure
that has been moved to GitHub. We should document those locations
in the same place we document the upgrade steps for Mercurial in
CI.
Differential Revision: https://phabricator.services.mozilla.com/D6989
--HG--
extra : moz-landing-system : lando
about:buildconfig on Thunderbird shows an incorrect mercurial source URL
that's a comm- repo, but a mozilla- changeset revision.
For Taskcluster builds at least, MOZ_SOURCE_CHANGESET is set as an environment
variable by mozharness. During the build, build/variables.py writes out
source-repo.h with a few defines, including MOZ_SOURCE_URL that gets picked
up by buildconfig.html.
Differential Revision: https://phabricator.services.mozilla.com/D7151
--HG--
extra : moz-landing-system : lando
The cctools-port linker links against libraries from clang (for LTO),
which have different SONAMEs depending on the clang version. Which means
the linker needs to be used along the same version of clang it was built
against. Thus we also make it depend on linux64-clang-7.
But changing the dependency is not enough, cf. bug 1471905, so also
touch its build script, which it turns out, we need to do anyways
because llvm-dsymutil was renamed to dsymutil.
Relatedly, all toolchains that are built using cctools-port need to use
linux64-clang-7 too.
Building compiler-rt 7 with the OSX 10.11 SDK fails because of some
newer APIs being used in compiler-rt for xray, but this is not a feature
we use, so disable that.
Differential Revision: https://phabricator.services.mozilla.com/D6766
--HG--
rename : build/build-clang/clang-6-macosx64.json => build/build-clang/clang-7-macosx64.json
rename : taskcluster/scripts/misc/build-clang-6-linux-macosx-cross.sh => taskcluster/scripts/misc/build-clang-7-linux-macosx-cross.sh
extra : moz-landing-system : lando
The release-update-verify-config task requires that the versions passed
to it match up with what's been released. The version of Thunderbird
does not necessarily match the Gecko version it's based on.
Depends on D6509
Differential Revision: https://phabricator.services.mozilla.com/D6510
--HG--
extra : moz-landing-system : lando
This incorporates some fixes for ccache, icecream, and a better display
output (decreasing count instead of an increasing count). It may also
let us experiment with incremental rust support, though I think that
feature still needs some more work.
MozReview-Commit-ID: 7zPGiL9Ob6N
Differential Revision: https://phabricator.services.mozilla.com/D7152
--HG--
extra : moz-landing-system : lando
This extracts the current logic for finding nodejs into its own module in mozbuild. Configure and ESLint then use it.
For ESLint, this will change the first location it looks for nodejs to be the .mozbuild directory.
Differential Revision: https://phabricator.services.mozilla.com/D6430
--HG--
extra : moz-landing-system : lando
This patch prevents the test-coverage task from running on builds that are not related to code coverage.
Differential Revision: https://phabricator.services.mozilla.com/D6444
--HG--
extra : moz-landing-system : lando
Not quite sure why this dependency ever existed. These builds never use clang-tidy,
so this dependency was probably never needed in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D6493
--HG--
extra : moz-landing-system : lando
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
Changes the wpt manifest path to the topobjdir instead so it can be moved out of tree.
Other changes so that the manifest download and update, and |mach wpt| and |mach test <wpt-test>| work with the new path.
The manifest is also downloaded and updated when creating the tests-archive to ensure that it exists when we run tests on TC.
MozReview-Commit-ID: Fp6UsKJjhTU
Differential Revision: https://phabricator.services.mozilla.com/D5312
--HG--
extra : moz-landing-system : lando
Bump the timeout for pulling the automationrelevance json. For very large merges, this can take awhile. For example, 7ecef4cf18 takes ~22 seconds.
Differential Revision: https://phabricator.services.mozilla.com/D6274
--HG--
extra : moz-landing-system : lando
This provides a modicum of assurance that, for example, a non-generic action is
not being run with generic scopes. While scopes would prevent any serious
damage from such an action, this provides an extra layer of security to prevent
such abuse.
Differential Revision: https://phabricator.services.mozilla.com/D6271
--HG--
extra : moz-landing-system : lando
Connor Sheehan
Henrik Skupin
Joel Maher
Tom Prince
Brindusan Cristian
Rob Wood
Rob Lemley
ffxbld
Coroiu Cristina
Mike Hommey
arthur.iakab
Chris Manchester
Marco Castelluccio
Ciure Andrei
Mike Shal
Dustin J. Mitchell
Mark Banner
Gregory Mierzwinski
Simon Fraser
Ehsan Akhgari
Tom Ritter
Gurzau Raul
Nick Thomas
Kartikaya Gupta
Margareta Eliza Balazs
Ahilya Sinha
Noemi Erli
Ben Hearsum