scripts: add helper script to use Docker containers

This adds a script that can be used to do builds easily within the
defined containers under the automation directory. These containers live
in the public GitLab registry under the xen-project namespace. The
script can be executed a number of ways but the default is to drop you
at a bash shell within a Debian Stretch container at the top level of
the source tree.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>

automation/build/README.md

@@ -5,9 +5,12 @@ These Docker containers should make it possible to build Xen in
 any of the available environments on any system that supports
 running Docker. They are organized by distro and tagged with
 the version of that distro. They are available from the GitLab
-Container Registry under the Xen project at:
+Container Registry under the Xen project at the [registry] and
+can be pulled with Docker from the following path:
 
-registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
+docker pull registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
 
 To see the list of available containers run `make` in this
 directory. You will have to replace the `/` with a `:` to use
@@ -19,16 +22,50 @@ Building Xen
 From the top level of the source tree it should be possible to
 run the following:
 
-docker run --rm -it -v $(PWD):/build -u $(id -u) -e CC=gcc $(CONTAINER) make
+```
+./automation/scripts/containerize make
+```
 
-There are other modifications that can be made but this will run
-the `make` command inside the specified container. It will use your
-currently checked out source tree to build with, ensure that file
-permissions remain consistent and clean up after itself.
+Which will cause the top level `make` to execute within the default
+container, which is currently defined as Debian Stretch. Any arguments
+specified to the script will be executed within the container from
+the default shell.
+
+There are several environment variables which the containerize script
+understands.
+
+- CONTAINER: This overrides the container to use. For CentOS 7.2, use:
+
+  ```
+  CONTAINER=centos72 ./automation/scripts/containerize make
+  ```
+
+- WORKDIR: This overrides the path that will be available under the
+  `/build` directory in the container, which is the default path.
+
+  ```
+  WORKDIR=/some/other/path ./automation/scripts/containerize ls
+  ```
+
+- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
+  automatically passed through to the container.
+
+- CONTAINER_NAME: By default the container name is set based on the
+  container itself so that its easy to attach other terminals to your
+  container. This however prevents you from running multiple containers
+  of the same version. Override the name value to cause it to name
+  the container differently on start.
+
+- EXTRA_CONTAINER_ARGS: Allows you to pass extra arguments to Docker
+  when starting the container.
 
 Building a container
 --------------------
 
 There is a makefile to make this process easier. You should be
 able to run `make DISTRO/VERSION` to have Docker build the container
-for you.
+for you. If you define the `PUSH` environment variable when running the
+former `make` command, it will push the container to the [registry] if
+you have access to do so.
+
+[registry]: https://gitlab.com/xen-project/xen/container_registry

automation/scripts/containerize

@@ -0,0 +1,93 @@
+#!/bin/bash
+
+einfo() {
+	echo "$*" >&2
+}
+
+die() {
+    echo "$*" >&2
+    exit 1
+}
+
+#
+# The caller is expected to override the CONTAINER environment
+# variable with the container they wish to launch.
+#
+BASE="registry.gitlab.com/xen-project/xen"
+case "_${CONTAINER}" in
+    _centos72) CONTAINER="${BASE}/centos:7.2" ;;
+    _trusty) CONTAINER="${BASE}/ubuntu:trusty" ;;
+    _xenial) CONTAINER="${BASE}/ubuntu:xenial" ;;
+    _jessie) CONTAINER="${BASE}/debian:jessie" ;;
+    _stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
+esac
+
+# get our container name and version
+containid=${CONTAINER%:*}
+containver=${CONTAINER#*:}
+
+# Save the commands for future use
+cmd=$@
+
+# If no command was specified, just drop us into a shell if we're interactive
+[ $# -eq 0 ] && tty -s && cmd="/bin/bash"
+
+# Are we in an interactive terminal?
+tty -s && termint=t
+
+#
+# Fetch the latest version of the container in hub.docker.com,
+# unless it's a newly created local copy.
+#
+einfo "*** Ensuring ${CONTAINER} is up to date"
+docker pull ${CONTAINER} > /dev/null ||     \
+    die "Failed to update docker container"
+
+if hash greadlink > /dev/null 2>&1; then
+    READLINK=greadlink
+elif [[ $(uname -s) == "Darwin" ]]; then
+    echo "Unable to forward SSH agent without coreutils installed"
+    unset SSH_AUTH_SOCK
+else
+    READLINK=readlink
+fi
+
+# Ensure we've got what we need for SSH_AUTH_SOCK
+if [[ -n ${SSH_AUTH_SOCK} ]]; then
+	fullpath_sock=$(${READLINK} -f ${SSH_AUTH_SOCK} 2> /dev/null)
+	if [ $? -ne 0 ]; then
+        echo "Invalid SSH_AUTH_SOCK: ${SSH_AUTH_SOCK}"
+        unset SSH_AUTH_SOCK
+    else
+        SSH_AUTH_DIR=$(dirname ${fullpath_sock})
+        SSH_AUTH_NAME=$(basename ${fullpath_sock})
+    fi
+fi
+
+# if we got the CONTAINER_NAME env variable then use that for our name
+if [[ -n ${CONTAINER_NAME} ]]; then
+    name="--name ${CONTAINER_NAME}"
+fi
+
+# Figure out the base of what we want as our sources
+# by using the top of the git repo
+if [[ -n ${WORKDIR} ]]; then
+    WORKDIR="${WORKDIR}"
+else
+    WORKDIR=$(git rev-parse --show-toplevel)
+fi
+
+# Kick off Docker
+einfo "*** Launching container ..."
+exec docker run \
+    ${DOCKER_ARGS} \
+    ${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
+    -v "${WORKDIR}":/build:rw \
+    -v "${HOME}/.ssh":/root/.ssh:ro \
+    ${SSH_AUTH_DIR:+-v "${SSH_AUTH_DIR}":/tmp/ssh-agent} \
+    ${XEN_CONFIG_EXPERT:+-e XEN_CONFIG_EXPERT=${XEN_CONFIG_EXPERT}} \
+    ${EXTRA_CONTAINER_ARGS} ${name} \
+    -${termint}i --rm -- \
+    ${CONTAINER} \
+    ${cmd}
+