For some reason, the locales package is not installed anymore during the
docker image build, which leads to the locale-gen command failing, since
it's not there.
--HG--
extra : rebase_source : 0a152499c623a00d27d8b916c472e5d5980d8193
The cctools-port build scripts were pulling and building the master branch
of the cctools-port repo, which means they'd build whatever was there
when they get triggered. I think this was copied from my build-cctools
script which did the same thing, so it's my fault in the end! This patch
pins a revision in the script so we'll build the same thing until we
explicitly update.
I also fixed the scripts to use git instead of tc-vcs, since tc-vcs prints
misleading error messages, and nothing else uses that anymore.
Finally, I removed the build-cctools script, since all the builds are using
cctools-port now so it doesn't serve any useful purpose.
MozReview-Commit-ID: 5myqHS4duor
--HG--
extra : rebase_source : 11231cbe49c7ba830a880bfa4600f0a24d61471d
Mercurial uses the latest version of TLS that is both supported by
Python and the server.
In automation, the servers we care about should all support TLS 1.2.
The Python side is trickier. Modern versions of Python (typically 2.7.9+)
support TLS 1.1 and 1.2. Mercurial will default to allowing TLS 1.1+ -
explicitly disallowing TLS 1.0. However, legacy versions of Python
don't support TLS 1.1+, so Mercurial will allow TLS 1.0+ rather than
prevent connections at all.
TLS 1.0 is borderline secure these days. I think it is a bug for TLS
1.0 to be used anywhere in the Firefox release process. This simple
patch changes our default Mercurial config in TaskCluster to require
TLS 1.2+ for all https:// communications. For modern Python versions,
this effectively prevents potential downgrade attacks to TLS 1.1
(connections before should have negotiated the use of TLS 1.2).
I expect this change to break things. Finding and fixing automation
that isn't capable of speaking TLS 1.1+ should be encouraged.
MozReview-Commit-ID: 876YpL5vB3T
--HG--
extra : rebase_source : 69c33c195f736a98b67d771e7364b6db28900ff4
Automation is now largely using Mercurial 4.1 with some lagging
components still on 3.9 and a very small sliver of random parts
still on 3.7.3. Let's update the mozharness tests to match what
automation is using.
FWIW, the Mercurial tests still pass on 3.9.
MozReview-Commit-ID: BgZVDcx29mf
--HG--
extra : rebase_source : edb8516491fe9ef616b1ad797be2fc02a89c2829
This is a pretty straightforward change. Just bumping package versions
and hashes. Behavior should be almost identical to the previous 4.1.1+
packages.
MozReview-Commit-ID: CaVjM0JHYKi
--HG--
extra : rebase_source : dcd0ee2661fd088daf3b5c6709c4c6f2f95bd410
Use "MOZ_LOG", which reminds people that mozlog is available.
MozReview-Commit-ID: 3h6ARVEUVhT
--HG--
extra : rebase_source : 816e50af750454f458628b4401646f0378b43246
The TASKCLUSTER_WORKER_GROUP environment variable used to contain the full
AWS availability zone, but a recent docker-worker change changed it to
be simply the AWS region, which broke sccache in taskcluster because we
were using it as part of the S3 bucket name.
MozReview-Commit-ID: 1KsfWpB4PoY
--HG--
extra : rebase_source : bdc61f180bf079eb0ad2cdbbd25e3e3a0deb62e6
The latest upstream version produces .dmg files that have fsck errors,
and some versions of OSX complain that the image is corrupted. The
previous version of libdmg-hfsplus that we were using (1d72dd62a)
doesn't have fsck errors, but it also doesn't preserve file permissions.
Our fork is based on the older version and backports the file permission
commits.
MozReview-Commit-ID: Bjwy6MJ98Ud
--HG--
extra : rebase_source : 5ecb3a3bbe9d8fe655fda7c1ce615bac91dc26fb
Editors generally look for configurations at the top level of a project. For ESLint, they also look for the specific binary in node_modules before defaulting to the system binary. Whilst you can override the location, generally it doesn't work well when switching between projects.
The custom in-tree libraries make setup of a system ESLint more difficult as well.
Therefore to make it simple for developers to pick up the ESLint integrations with Editors, by moving the package.json and associated node_modules to the top-level directory.
MozReview-Commit-ID: 1pQpd7hTQ61
--HG--
rename : tools/lint/eslint/npm-shrinkwrap.json => npm-shrinkwrap.json
rename : tools/lint/eslint/package.json => package.json
extra : rebase_source : 9d69d791f86b5c55b1fcd5f6449f0ab84e56b05c
In short shouldn't call err.stack(), it's a property.
MozReview-Commit-ID: 2HpPgsdctTv
--HG--
extra : rebase_source : 1769c125b4d720991c810f5c9460b2161ecbc8a8
Docker-worker's `command` field is actually not required, as it will run a
docker image's default command when command is not specified.
MozReview-Commit-ID: I3vBHeixlxW
--HG--
extra : rebase_source : a5d02c3131dd6ffb307c37e827d58aa8686ccaf8
A few commits ago, we bumped up the default zstandard compression level
from 3 to 10 when we switched to multi-threaded compression. Even with
multiple threads, this was a bit slower.
For images that will be built once and read multiple times, it is
worthwhile to burn extra CPU once and produce a small image. However,
for other tasks where the number of reads is limited, it isn't
worth it to use this extra CPU. This commit uses the SCM level as
a proxy for "optimize for speed." If the task is associated with level
1 (a try push), we lower the compression level and optimize for
speed. Otherwise, we keep the higher compression level and
optimize for image size.
Credit goes to Jonas for this terrific idea.
MozReview-Commit-ID: Hui97KsZpgw
--HG--
extra : rebase_source : 5a98e554166b51b8caa62b38d82e91c7b9fcb7ab
Using --no-install-recommends prevents installation of unwanted
packages and helps reduce image bloat. Using it in image_builder
reduces the image size from ~212.5 MB to ~203.6 MB. Not the
biggest savings. But savings nonetheless.
I kept python-pip separate because using --no-install-recommends with
it fails to pull in setuptools, gcc, and other packages required for
building Python packages. Since these packages are only needed
for generating the Docker image, I didn't feel like teasing out
the actual dependencies. It takes a little longer to install
temporary packages and build the image. But the end result should
mostly be the same.
MozReview-Commit-ID: EVURGKFuWzb
--HG--
extra : rebase_source : e1f953079480c6d898569dc7e14dc97890d4f41e
The goal of this change is to switch to python-zstandard for Docker
image compression so we can employ multi-threaded compression. This will
cut down the wall time it takes to compress images, decreasing end-to-end
times.
In order to use python-zstandard, I needed to write a Python script
for doing the compression. Since I was writing a Python script, I
figured I'd move Docker image downloading to that script as well.
This way, the raw Docker image never hits disk: it is streamed straight
from Docker into a zstandard compressor and that output is written to
disk. For large images, this will eliminate a few gigabytes of disk
writes.
The one extra complication about this I don't care for is you need a
special Python package to teach the "requests" package how to download
from UNIX domain sockets.
MozReview-Commit-ID: EufaRzR6A4Y
--HG--
extra : rebase_source : 2143bfee729bdc075c3a87a1e607eff2f0c164d2
Update rust-build docker image source to v0.4.3. This includes
some recent to how verification and taskcluster work to maintain
working scripts, and some changes for the newer cargo-building-
cargo build system, which aren't sufficient for bootstrapping.
MozReview-Commit-ID: 4IdbKVvco8m
--HG--
extra : rebase_source : f3cd2b7e8429648072ac02df5e8d4659c675f2ae
We recently changed how image compression works (bug 1350447) and
upgraded to Mercurial 4.1.1 (this bug). It's time to roll a new
image_builder Docker image.
This commit updates the version and hash of the image. The image
is already pushed to Docker Hub/Cloud. We just need to whitelist
it and deploy this change.
MozReview-Commit-ID: KQwJZ2OSGlt
--HG--
extra : rebase_source : 23f2686cd85256178b5d89c452aaeabe4e4198db
We've been running Mercurial 3.9 in automation for a while. Mercurial
4.1 is out. It has the usual performance improvements and bug fixes,
making it an attractive upgrade. But what really makes it enticing
is support for zstandard compression over the wire protocol. This will
reduce server-side CPU load and make transfers between 4.1+ servers
faster.
So, let's upgrade to Mercurial 4.1.1.
The produced packages are built from the current tip of the
stable Mercurial branch, not exactly 4.1.1. Specifically, they
correspond to revision ed5b25874d99. I did this because there is
a patch in the stable branch that drastically improves performance
on repos with many heads. When 4.1.2 is released in a few days, we
can upgrade to it and do away with the one-off.
MozReview-Commit-ID: 6BPhVheHQXI
--HG--
extra : rebase_source : d72452708fa0397272b79247d9d4844b35e5ee26
b2gtest uses *.xlarge instances, so it seems a reasonable substitution.
MozReview-Commit-ID: Ev6tnNpx13c
--HG--
extra : rebase_source : 87184b182d1428f041a5ae36e465d72dee6f7621
(For "Integrate and fully support OSX Signing in taskcluster")
Written as a mozharness script rather than using bare ./mach command because we need to download the upstream artifact
and because we need to download artifacts from tooltool to do the packing back into a .dmg. Future ideal would be to get
rid of the mozharness script and use JUST ./mach.
This is using the ./mach repackage code being created in Bug 1347576. Taking a signed tarball from a dmg supported with
Bug 1346015, and the taskgraph work to schedule this is in Bug 1318505.
MozReview-Commit-ID: rv9l285HKC
--HG--
extra : rebase_source : 054219511419b8bf44b1f57a8d834a12c13710e3
extra : intermediate-source : a52bc37e08efbf4d6c68cc0f4e2d4b76f79b192a
extra : source : 6ad7468a590f5a2779ffdc3713c1f6f74ce23731