So I have a Pi 3 B+ and a Pi 0 w. The intention was to develop my application in local development mode on my Pi 3, then move over the hat to the Pi 0 and install the application in normal production mode on the Pi 0 w.
I’ve discovered that the devices are not considered compatible in the same application, however.
What is the reason for this, and what is the recommended way of implementing a scheme like this?
Is making two applications and pushing to both the only solution?
Hi!
I think the reason is that starting from Raspi 2 onwards there is another ARM CPU, effectively making it a completely different compilation target.
You can have a look at the Raspberry PI images available:
https://www.balena.io/docs/reference/base-images/base-images/#armv6hf-
EDIT: so, yes, possibly the only way would be to have two different application and push to both git remote
hope this helps
I guess each application only has a single compilation target makes sense, but it would seem like a commonly desired feature to be able to push portable code to multiple device types.
Fortunately for me, I am able to delete the raspberry pi 3 application from balena cloud entirely, and I can just use local pushing to test on my Pi 3.
Hi @bathtubed and @hahaha,
We have support for exactly this sort of design pattern. We provide a special Dockerfile template to allow our builders to inject your Dockerfile with the appropriate values for architecture and machine name, depending on which application you are pushing to. Here is the corresponding documentation for that feature, please try it out and let us know how it works for you!
Thanks for using balena!
that would be a very useful feature but I’m afraid there’s no such thing between Raspis 1 and 2+3 (would be somehow like asking to have portable code between Linux and Windows).
If I understand correctly how Balena works, they build and deploy a single Docker container on your device. A Docker container is nothing but a chroot environment, sort of a “directory” completely isolated from the rest of your device filesystem. They must build multiple container for different architectures.
oh cool thanks @xginn8 for the heads-up! I’m new to balena too and that is pretty interesting!
I know about and use the templating feature. However, to actually deploy this code to multiple types of devices, I still need to create two balenaCloud applications, where I duplicate my environment variables and push to both.
What’s the point of the .template if I still need to push to each device type anyway?
We have support for multiple architectures per app on our roadmap, but for now you can get multiple device types which share an architecture on a single app.
Now, if you have multiple apps (one for armv7 devices, one for armv8) necessitated by the (present) limitation on architecture-homogeneous apps, you can still benefit from the .template file being a means to deploy your single codebase to the apps. You can also make use of the CLI & SDK to synchronize deployment of environment variables to the apps.