When developping balena applications, we usually maintain two seperate dockerfiles:
Dockerfileuses standard x86 images, for developping on our workstations
Dockerfile.templateuses balenalib images, using variables for the hardware type
This works without issue for most use cases, but sometimes we have to override the default build context in order to access files that are outside of the service folder (shared configuration between services most of the time).
The compose file reference instructs us to use the
dockerfile instructions in order to achieve such a thing. The only issue is that by specifying the Dockerfile, we lose balena’s Dockerfile template feature.
Consider the following example:
$ tree . . |-- docker-compose.yml |-- file.txt `-- service1 |-- Dockerfile `-- Dockerfile.template
# docker-compose.yml version: "2.0" services: service1: build: context: . dockerfile: "./service1/Dockerfile.template"
# service1/Dockerfile FROM node:14 COPY file.txt .
# service1/Dockerfile.template FROM balenalib/%%BALENA_MACHINE_NAME%%-node:14-build COPY file.txt .
$ docker-compose build Building frontend Step 1/2 : FROM balenalib/%%BALENA_MACHINE_NAME%%-node:14-build ERROR: Service 'service1' failed to build : invalid reference format: repository name must be lowercase
As you can see, our build fails on our workstation because we override the default dockerfile. If we omit the
.template part, then our production build uses the wrong Dockerfile.
Is there a solution to this issue? I checked the docs and forums but couldn’t find any.