Unlike other parts of the generated Dockerfile,
the start script is evaluated at run time, rather
than at build time. Currently, we assume that the
current working directory is the same at runtime
as build time for the start script. This doesn't
hold true always, and particularly not in JupyterHub
environments where ${HOME} is often overlaid with
a persistent directory.
We change this to always refer to the full path,
using the ${REPO_DIR} environment variable. This
lets people building JupyterHub images to set
REPO_DIR to something like /srv/repo (like hubploy
does), and still have a working start script.
We want to put the repo somewhere other than ${HOME}
so we can mount persistent storage in ${HOME} more easily.
Most of repo2docker assumes current directory is where
the contents are, so we should be able to get most of it
working by setting WORKDIR to ${REPO_PATH} and letting
${REPO_PATH} be configurable.
Unclear what to do for plain Dockerfiles, Legacy Dockerfiles &
nix.
`apt-get install` calls `dpkg` underneath to do the
installation. Unfortunately, `-qq` does not get passed
through, and we end up with a lot of log output even with
`-qq`. Redirecting stdout to /dev/null stops this output.
Errors come out to stderr, so those will be displayed.
When you run repo2docker locally, the uid is usually set
to the current user's uid. However, when we push the content
to Docker, we invariably set the uid of the scripts we
use as part of repo2docker at 1000. This causes a cache bust
every time.
This patch uses the correct uid, and fixes cache busting. Makes
local test runs *much* faster.
Fixes#508
- Creating a new client with 'auto' version causes repeated
unnecessary network requests to discover version of docker daemon.
- Testing is easier this way, since we can inject a mocked docker
client more easily
This lets us explicitly specify images that repo2docker
should try to re-use cached layers from. Docker normally only
looks for layers from images that were *built* locally - if
we want it to look in images that were *pulled* from a registry,
we need to specify it here.
Currently a *lot* of our log info is from apt packages being
installed, and package lists being updated. This is mostly not
very useful information to users. The following outputs are
hidden:
- apt-get update, purge & clean
- apt-get installs for base packages
When there is any error from any of the apt-get steps, they will
be printed. Any packages the user explicitly lists (via apt.txt)
will have their install status messages output.