base: This builds example/base and tags it with a build number. This build number is automatically provided to later pipeline stages as $GO_DEPENDENCY_LABEL_BASE.
app: This takes the example/base version specified in $GO_DEPENDENCY_LABEL_BASE, and uses it to build example/app.
So when we're making official builds, we want:
FROM example/base:$GO_DEPENDENCY_LABEL_BASE
When we're developing locally, it's safe to use:
FROM example/base:latest
One obvious way to implement this would be:
ARG GO_DEPENDENCY_LABEL_BASE=latest
FROM example/base:${GO_DEPENDENCY_LABEL_BASE}
We could then invoke docker build with --build-arg GO_DEPENDENCY_LABEL_BASE=$GO_DEPENDENCY_LABEL_BASE when running under GoCD, allowing us to lock to specified base image.
What we could do in cage
We could support using Handlebars templates in Dockerfile.hbs, as follows:
FROM example/base:{{default env.GO_DEPENDENCY_LABEL_BASE 'latest'}}
We could then automatically pre-process any *.hbs file before building.
What we would like upstream, in a perfect world
Original discussion here. We have two GoCD pipelines:
example/base
and tags it with a build number. This build number is automatically provided to later pipeline stages as$GO_DEPENDENCY_LABEL_BASE
.example/base
version specified in$GO_DEPENDENCY_LABEL_BASE
, and uses it to buildexample/app
.So when we're making official builds, we want:
When we're developing locally, it's safe to use:
One obvious way to implement this would be:
We could then invoke
docker build
with--build-arg GO_DEPENDENCY_LABEL_BASE=$GO_DEPENDENCY_LABEL_BASE
when running under GoCD, allowing us to lock to specified base image.What we could do in
cage
We could support using Handlebars templates in
Dockerfile.hbs
, as follows:We could then automatically pre-process any
*.hbs
file before building.