gecko-dev/testing/docker
Wes Kocher 706c4b1fa2 Backed out changeset 3cc789ec2bf0 (bug 1204800)
--HG--
extra : commitid : DGLBcIgjfBC
2015-10-27 21:02:32 -07:00
..
b2g-build Bug 1177190: Update libcurl in docker images. r=selenamarie 2015-07-01 00:51:05 -03:00
base-build Bug 1122598: Refactor testing/docker to support Android; r=wcosta 2015-01-21 10:45:34 -05:00
base-test Bug 1176031: fix up image versions, registries; r=ahal 2015-10-07 16:59:23 -04:00
builder Bug 1203965 - Update images to use taskcluster-vcs 2.3.12 r=wcosta 2015-09-11 08:23:01 -05:00
centos6-build Bug 1213627 - Add ninja to the desktop-build image to support building clang 3.7; r=dustin 2015-10-13 16:46:07 -04:00
centos6-build-upd Bug 1213627: update Dockerfile FROM lines to match; r=ehsan 2015-10-14 09:52:13 -04:00
decision Bug 1119387 part 5: Update docker images. 2015-03-25 14:25:27 -03:00
desktop-build Bug 1213627: update Dockerfile FROM lines to match; r=ehsan 2015-10-14 09:52:13 -04:00
desktop-test Bug 1217396: put worker in the video group for access to /dev/video0; r=ted.mielczarek 2015-10-22 11:55:32 -04:00
phone-builder Backed out changeset 3cc789ec2bf0 (bug 1204800) 2015-10-27 21:02:32 -07:00
tester Bug 1176031: fix up image versions, registries; r=ahal 2015-10-07 16:59:23 -04:00
tester-device Bug 1203965 - Update images to use taskcluster-vcs 2.3.12 r=wcosta 2015-09-11 08:23:01 -05:00
ubuntu1204-test Bug 1213325: refactor desktop-test to use an in-tree script; r=ahal 2015-10-13 14:20:34 -04:00
ubuntu1204-test-upd Bug 1213325: refactor desktop-test to use an in-tree script; r=ahal 2015-10-13 14:20:34 -04:00
build.sh Bug 1212877: improve build.sh to run from any directory; r=wcosta DONTBUILD 2015-10-08 10:43:20 -04:00
README.md Bug 1122598: Refactor testing/docker to support Android; r=wcosta 2015-01-21 10:45:34 -05:00
REGISTRY

Docker Images for use in TaskCluster

This folder contains various docker images used in taskcluster as well as other misc docker images which may be useful for hacking on gecko.

Organization

Each folder describes a single docker image. These images depend on one another, as described in the FROM line at the top of the Dockerfile in each folder. Each image has a version, given by its VERSION file. This should be bumped when any changes are made that will be deployed into taskcluster. Then, older tasks which were designed to run on an older version of the image can still be executed in taskcluster, while new tasks can use the new version.

Each image also has a REGISTRY, defaulting to the REGISTRY in this directory, and specifying the image registry to which the completed image should be uploaded.

Building images

Generally images can be pulled from the registry rather then build locally, but for developing new images its often helpful to hack on them locally.

To build an image, invoke build.sh with the name of the folder (without a trailing slash):

./build.sh base

This is a tiny wrapper around building the docker images via docker build -t $REGISTRY/$FOLDER:$FOLDER_VERSION

On completion, build.sh gives a command to upload the image to the registry, but this is not necessary until the image is ready for production usage. Docker will successfully find the local, tagged image while you continue to hack on the image definitions.

Adding a new image

The docker image primitives are very basic building block for constructing an "image" but generally don't help much with tagging it for deployment so we have a wrapper (./build.sh) which adds some sugar to help with tagging/versioning... Each folder should look something like this:

  - your_amazing_image/
    - your_amazing_image/Dockerfile: Standard docker file syntax
    - your_amazing_image/VERSION: The version of the docker file
      (required* used during tagging)
    - your_amazing_image/REGISTRY: Override default registry
      (useful for secret registries)

Conventions

In some image folders you will see .env files these can be used in conjunction with the --env-file flag in docker to provide a environment with the given environment variables. These are primarily for convenience when manually hacking on the images.

You will also see a system-setup.sh script used to build the image. Do not replicate this technique - prefer to include the commands and options directly in the Dockerfile.