all of which attempt to rebuild the app release that is already sitting in the balena cloud (same arch, same target device - Intel NUC), and then fail because those deploy cli commands don’t specify registry-secrets - on purpose, as we want to use the GitHub Actions/Balena Cloud built container, NOT build it again.
@scscsc you hit the nail on the head here. We purposefully marked Apps as ‘alpha’ in the dashboard as they are not yet feature complete and do not represent everything we want to do with them.
We are pushing through a lot of cool features at the moment, and the problem that we’re having is the trade-off between waiting until everything is feature complete and changing A LOT of components all simultaneously, and drip-feeding new features so that our users get the benefit of them today. We chose the latter option as it allows us to refine our roadmap as we go and don’t accidentally spend a bunch of time building something that nobody actually wanted, but as a downside there are cases such as this where it can be a little misleading.
I think you’ve done exactly what I would have recommended here, but, perhaps another thing to consider is the use of blocks. Blocks only work with single containers, so if you have multiple containers within your app you’d have to create multiple blocks, but a block will give you a bh.cr URL to the prebuilt image which you can then use in the releases that you push to apps or fleets.
I spend a lot of my time working on these concepts at balena so have a lot of the context in my head ready to go - if you have any questions about this stuff feel free to reply here and ping me and I’ll do my best to get back to you.
You can also check out these blog posts for a bit more back story about what we’re doing: