Our normal ubuntu 16.04 test image is suitable for hosting an Android x86
emulator with these minor updates: Install kvm and make sure /dev/kvm
rw permissions are open for everyone. Note that /dev/kvm is generally
only visible when running docker with --privileged; its permissions
cannot be modified in the Dockerfile, only at run-time: run-task is the
first opportunity.
download-and-compress isn't very complicated and should work on Python 3
with minimal effort. So let's switch it to use Python 3.
MozReview-Commit-ID: 9G1WfcbbKEY
--HG--
extra : rebase_source : 3a6bab06c8500a90413e8b7642a7bf7bdff04a46
Version 0.9.0 bundles a newer version of the zstandard library, which
is a little faster and has a few minor bug fixes (none that we were
likely hitting, however).
MozReview-Commit-ID: 9YgSZ0G41eg
--HG--
extra : rebase_source : 8f5a68323b1e1fe7e9f1dd1a92e132434972d21d
We want Python 3 available everywhere because it is 2018.
MozReview-Commit-ID: L3wufNXKdnp
--HG--
extra : rebase_source : c260923e3c13f8b28e30eaaf6e1bd38f79500052
The python3-minimal package provides /usr/bin/python3 on Debian.
This commit installs this package so a `python3` executable is
provided.
This required backporting the package to wheezy. The final patch
is trivial. But I wasted a bit of time figuring out why `mk-build-deps`
wasn't working. It would no-op and exit 0 and then the build would
complain about missing dependencies!
glandium's theory is that the ":any" multiarch support on wheezy
isn't complete. Removing ":any" seems to make things "just work."
MozReview-Commit-ID: FBicpK4SmkQ
--HG--
extra : rebase_source : a28ce731024e8ed6a43fb30e2ed57da2abb50d0f
This Dockerfile downloads non-deterministic remote content (by cloning a
Git repo) and then executes code from it. Part of that code is
executing Python package installs.
Since this Docker image was generated, it appears the remote code
requires new build dependencies. This commit adds those package
dependencies.
Not having deterministic Docker image builds is a bug. I'll file a
follow-up so we pin the Git commit used for building so this type
of failure doesn't occur again.
--HG--
extra : amend_source : 533a95abeb7cf7ddc9a1329549f5d294baf983f5
In preparation for making it usable on Windows, after which point
having it in a directory with "docker" in it doesn't make much sense.
MozReview-Commit-ID: Hgu0buFyJwF
--HG--
rename : taskcluster/docker/recipes/run-task => taskcluster/scripts/run-task
extra : rebase_source : 3c0b502d28b5aad54bd04069efbfda88e25bbb20
Previously, we installed the latest version of pip and virtualenv.
This commit pins the pip and virtualenv version so we install known
working versions (pip 10 breaks the image build for some reason).
MozReview-Commit-ID: hOAMencdcr
--HG--
extra : rebase_source : 2cb44c2ef55e29c55cf3d1b354e90d6fb5414cce
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
The big win comes from removing the APT lists. We also reduce the
number of layers while we're here.
This makes the image 162 MB instead of 202 MB.
MozReview-Commit-ID: K2ic4zcr31j
--HG--
extra : rebase_source : afda144f1a1319971842642b58460de169e245fa
Summary:
a difference in behaviours between awks meant the original didn't work in-situ,
although the task didn't fail due to the pipe chain.
Reviewers: jlorenzo
Reviewed By: jlorenzo
Bug #: 1452159
Differential Revision: https://phabricator.services.mozilla.com/D899
--HG--
extra : rebase_source : b31b7ceeb59c79aeecf206c079b8ea436967e7c7
Summary:
the periodic file updates keep adding new reviews, and it's easy to fall behind.
This adjusts the script so it clears out any previous submissions that are still awaiting review.
Reviewers: jlorenzo
Reviewed By: jlorenzo
Bug #: 1452159
Differential Revision: https://phabricator.services.mozilla.com/D872
--HG--
extra : rebase_source : 4a36ddd91bf7e971fd6b424d02117bd4739a91ed
We want Python 3.5+ to be available everywhere so various processes
can start using it.
The debian-base Dockerfile is shared by Debian 7 and 9 images.
Debian 9 ships with Python 3.5 and after the previous commit, we
have a Python 3.5 package for Debian 7. So we simply install the
"python3.5" package to get Python on all the Debian images.
MozReview-Commit-ID: 9ZmoSxtHWTZ
--HG--
extra : rebase_source : be4e62e7d731a3c39ee9ce205d75f1e525192acc
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
Summary: This doesn't solve the download timeouts, but does ensure that retries are happening as they should.
Reviewers: rail
Reviewed By: rail
Bug #: 1430600
Differential Revision: https://phabricator.services.mozilla.com/D821
--HG--
extra : rebase_source : ba2e30cb7f190f5ee2ef06dadd80d7fe9bc61d54
