Build the latest tup master branch with the LD_PRELOAD dependency
checker.
MozReview-Commit-ID: ALfnnmOZrky
--HG--
extra : rebase_source : 529d4392ef73e03f66fb76f089f8b88f45b44972
We don't have docs for how to upgrade Mercurial in CI. A lot of it
is organic institutional knowledge that lives in various people's
heads. That's not good for continuity of business.
This commit starts to establish documentation for how to upgrade
Mercurial in Firefox CI.
The documentation for updating things in-tree is pretty robust
(because I've done it a handful of times and know what is involved).
But the docs for OpenCloudConfig and Puppet could certainly be
improved. I'll poke the respective maintainers of these systems
to help improve these docs as a follow-up.
MozReview-Commit-ID: Aruh3N8Llls
--HG--
extra : rebase_source : 5d82ffd1d2b808082d824274db33586f71899599
We bump the version of Mercurial for Debian packages and for Ubuntu
Docker images.
MozReview-Commit-ID: KYmG4rOm3TQ
--HG--
extra : rebase_source : cbb817a9ee4c27f0bc59f4fa1e2a708fac1cb093
All in-tree Docker images should be installing Mercurial via
install-mercurial.sh so that the Mercurial install is consistent
across all Docker images.
I noticed this image wasn't using install-mercurial.sh because
attempting to rebuild the image currently fails due to
mercurial-4.3.1-2 not being available in the upstream package repo.
install-mercurial.sh has been taught to handle Ubuntu 18.04 and the
Docker image building process has been taught to use
install-mercurial.sh. install-mercurial.sh uses tooltool and behavior
should work and be deterministic over all of time.
As part of this, we had to establish a standalone shell script for
building the image. That's because install-mercurial.sh requires a
"tooltool_fetch" alias. Meaningful image building code has been
moved into the new setup.sh. This also means things run as a single
RUN statement. So we don't need to hack around minimizing RUN
invocations.
I also discovered that the pinned curl version is no longer available.
So I removed the version pinning. FWIW we can't rely on version
pinning unless the Apt repository is snapshotted. Packages do get
yanked from time to time. Unless we absolutely require a specific
version of a specific package, we can probably get away without pinning
- at least for this Docker image. But that can be a follow-up.
MozReview-Commit-ID: As7Hq470QcK
--HG--
extra : rebase_source : e5868ff1dfd6a14a12d3df08aca2954d1d9ea99f
Android jit tests are not ready to run yet: They may not run green, there are concerns about
capacity, etc. I am adding this support now to make it more convenient to debug on try.
--HG--
extra : rebase_source : 00bc5bf21fec3c130133b0de322b1f37250893c3
This updates the existing entries to use the 'trunk' shorthand notation,
and adds missing entries for mochitests, reftests, jsreftests, and the
three categories of web-platform-tests.
MozReview-Commit-ID: KTgfidGFPNu
--HG--
extra : rebase_source : 3287477c1c9846c4d3a00275e0cb8ae422c48262
In Bug 1447414 we're going to break the MinGW build. In this commit we
disable it pre-emptively but leave it available for people to run manually.
MozReview-Commit-ID: 9G9RSjYRn5z
--HG--
extra : histedit_source : 8c55f22d61268e56b8b55747dd23c95f286538dc
This keeps --disable-stylo working and --enable-stylo=build with the same
semantics, but it makes also --enable-stylo / and the default to not build the
old style system at all.
This also removes the stylo-only platforms, since they're now the default.
MozReview-Commit-ID: DL2eZZn9suE
You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
In 605111b6f51f, we removed a bunch of unused actions. However, now that we're recreating the source tarball, some of those are no longer unused. This patch brings them back.
MozReview-Commit-ID: 5WZMEeuatup
--HG--
extra : rebase_source : f725e6cacd692357bc8e4194afb052e2c29b99b1
If tasks still exist before the optimization phase, then any tasks these depend
on will also be scheduled. In particular for devedition on m-r, that means that
although the builds were being excluded from the target tasks due to the
build's run-on-projects settings, the upload-symbols and
upload-generated-sources tasks did exist in the target tasks, and so the builds
got re-added to the target tasks during graph optimization.
MozReview-Commit-ID: 1AWJuafULEE
--HG--
extra : rebase_source : 153653733e01433ae894a0ba4fd99228e0936024
Increases the max-run-time for all test tasks on ccov builds.
MozReview-Commit-ID: KtArHMWKgbH
--HG--
extra : rebase_source : 61b6831ba39f005992ce3ec5db5568ad9ce95a36
Android browser tests have a 90 minute application timeout which will produce
better diagnostics than the taskcluster timeout, so the max-run-time should
be >90 minutes. That's true for all other Android browser tests, but, perhaps
from an oversight, not for these.