Docker build-arg for BALENA_MACHINE_NAME instead of using Dockerfile.template

I’m developing an application that spans multiple device types / architectures.

I’m using a Dockerfile.template like this:

FROM wlisac/%%BALENA_MACHINE_NAME%%-swift:5.0

# do stuff

This works great with BalenaCloud, but one downside to this approach is that this template won’t build locally via docker build:

$ docker build -f Dockerfile.template .
Step 1/8 : FROM wlisac/%%BALENA_MACHINE_NAME%%-swift:5.0

invalid reference format: repository name must be lowercase

A workaround is to use a build-arg in the Dockerfile.template like this:

ARG BASE_IMAGE=wlisac/%%BALENA_MACHINE_NAME%%-swift:5.0

FROM $BASE_IMAGE

# do stuff

And then you can build the Dockerfile locally like this:

$ docker build -f Dockerfile.template --build-arg BASE_IMAGE=wlisac/raspberrypi3-swift:5.0 .

This is a decent workaround, but I’m wondering if Balena would consider sending build args for BALENA_MACHINE_NAME and other variables that are often used in templates when building via Balena.

This would allow a plain Dockerfile like this to work locally and via BalenaCloud without using a template:

Dockerfile

ARG BALENA_MACHINE_NAME=raspberrypi3

FROM wlisac/$BALENA_MACHINE_NAME-swift:5.0

# do stuff

I’m not sure of the origin of Balena’s Dockerfile.template, but it’s possible that Allow ARG in FROM makes templating less necessary.

Would love to know what others think of this idea.

Cheers,
Will

Hey @wlisac,

We’ve actually spoken about this in the past, and the reason that we didn’t is because this used to cause a docker build failure when the argument was not read, more on that here: https://github.com/moby/moby/issues/26249

That no longer is the case, and unconsumed build arguments now only cause an error (not ideal, but usable).

I can raise this for internal discussion to see what comes of it, but in the meantime, it’s possible to use balena build for this. This will build an entire docker-compose project (or a single Dockerfile(.template)) project, whilst also resolving any of these balena specific variables. The builds produce images on your local docker daemon, just like running (docker build ...).

Thanks for the idea and feedback!