My project uses a symlink for the Dockerfile.template which references which of the two Dockerfiles can be used. One builds the application from source, the other installs it from a binary. They are called Dockerfile.build and Dockerfile.binary. Dockerfile.template is a relative symlink to one of these.
using balena push or git push deploys the application correctly, whereas the Balena Deploy method does not and fails in the following manner, it does not see the symlink.
[Info] Starting build for streamyard, user gh_matthewcroughan
[Info] Dashboard link: https://dashboard.balena-cloud.com/apps/1683882/devices
[Info] Building on arm01
[Info] Pulling previous images for caching purposes...
[Success] Successfully pulled cache images
[Info] Starting to build traefik
[Info] Starting to build octodash
[Info] Starting to build mdns-publisher
[Info] Starting to build octoprint
[Success] Successfully built service mdns-publisher
[Success] Successfully built service traefik
[Success] Successfully built service octoprint
[Info] Uploading images
[Success] Successfully uploaded images
[Error] Some services failed to build:
[Error] Service: octodash
[Error] Error: the Dockerfile (Dockerfile) cannot be empty
[Info] Built on arm01
[Error] Not deploying release.
balena-cli works fine, this is not an issue with the balena-cli. I’ve already stated what commands to run, it is simply balena push appname. That works correctly.
I am running
matthew@thinkpad ~ $ balena --version
12.1.11
It is deployment with the balena deploy button that behaves incorrectly.
The issue is discussed by me and the Happy Hour crew a bit here, when we discovered this as a potential issue. Also some playback in the chat from Rich Bayliss who seems to think it might be the symlink causing the issue.
I can’t get balena push working with your repo from a fresh clone (master branch). Neither from the root dir nor from the octodash dir (with --noparent-check).
From the master branch, using balena push appname I am able to build Octodash fine and that error you presented does not occur for me. Maybe something happened via github in that instant that caused curl to fail.
octodash] Step 8/9 : RUN curl -sL https://github.com/UnchartedBull/OctoDash/releases/download/v""$VERSION""/octodash_""$VERSION""_$(uname -m).deb -o octodash.deb && dpkg -i --ignore-depends=libnotify4,xdg-utils,libappindicator3-1,libsecret-1-0 octodash.deb && rm octodash.deb
[octodash] ---> Running in 06a55d14ce85
[octodash] Selecting previously unselected package octodash.
[octodash] (Reading database ... 23580 files and directories currently installed.)
[octodash] Preparing to unpack octodash.deb ...
[octodash] Unpacking octodash (1.5.0) ...
[octodash] Setting up octodash (1.5.0) ...
[octodash] /var/lib/dpkg/info/octodash.postinst: line 10: update-desktop-database: command not found
[octodash]
[octodash] Processing triggers for hicolor-icon-theme (0.17-2) ...
[octodash] Removing intermediate container 06a55d14ce85
[octodash] ---> 4a0093012f04
[octodash] Step 9/9 : CMD ["bash","/usr/src/app/start.sh"]
[octodash] ---> Running in dde7556f83f3
[octodash] Removing intermediate container dde7556f83f3
[octodash] ---> 59efc48c66e3
[octodash] Successfully built 59efc48c66e3
[Info] Generating image deltas from release 13661c5454f074494b614598dc707cf0 (id: 1432670)
[=================================> ] 67%
Additionally, you can see on the video from the timecode I’ve provided that I am building it correctly via the CLI in the background, and minutes later comment on how it has finished successfully.
Yeah thanks to issues like these, I cannot make a MULTI-ARCH image, nor can I sensibly do this without having to duplicate effort by making multiple Dockerfiles, just to change one link, something I don’t want to get involved with. A feature which upstream Docker has had for a long time (2017?) is doing this multi-arch recognition stuff and having cases in Dockerfiles for each arch.
My Dockerfile.build defines a build procedure, but it fails on the balena build server, probably nothing to do with the server, but perhaps the application itself, being managed by NPM and electron-builder not supporting ARM, but would probably work fine elsewhere. You can see that issue here.
The arch depends on the application itself, and if you have a Dockerfile.template you can use %%BALENA_MACHINE_NAME%% and %%BALENA_ARCH%% placeholders anywhere. For example:
FROM balenalib/%%BALENA_MACHINE_NAME%%-debian:stretch
RUN echo %%BALENA_ARCH%%
I know these things. It’s just that this is not ideal, since Docker solves this with MULTI-ARCH images using Docker Manifests. Something which Balena does not support in the build server. Your templating scheme does not solve the fundamental problem. Balena is an old version of Docker without these features, which is why this is so problematic when using Docker hub images. The only way to get around this is to base everything in my repo on Balena base images, which is not something I want to do.
Hi there, the CLI will resolve symlinks and replace them with the real content running balena push, which is why doing balena push works . git push or Deploy with balena button, however, send the symlink to the builder as-is, but Docker/balenaEngine don’t follow symlinks when executing COPY commands (see: https://github.com/moby/moby/issues/6094), so the build fails. Having said that, we would recommend considering not using symlinks, since that will only works using the CLI.