Managed to get it working… It requires an additional job at the end of the action. Also, pay attention to the openbalena env id (env rename 4 ${{ github.sha }}, you need to retrieve the correct ID from the CLI).
This adds the entire SHA which is pretty long, so there is the optional job (#2) to shorten it - to use just uncomment.
Ideally, in setting up your openbalena project, the first environment variable you would create with the CLI would be the one that will receive the SHA (or any other job id you want) that way it would be given a env ID of 1 so you’re action can remain the same, always updating a known env ID.
I can add injection of github SHA every time of build action is done - it will be more logical at this way - implement some like release tags for your env
This is great, thanks for sharing this, it’s going to be a real help. Think I will try and implement it as a dev environment so commits get pushed out to a development device.
Not sure I entirely understand the workflow. Is the idea you commit built images to GitHub and then this just deploys them to OpenBalena, or do you push the code and the it builds the images and pushes them? I see the CLI is installed in a container, does it then build from there? I’m surprised it is able to connect to docker to perform the build process. All these questions emerge as I am wondering if it is in fact building the images too, how does caching work when it is run from inside a container? Will it cache my app layers on the server to improve the build time next time around?
@maggie0002 I’ve got this working like a charm. All you do from a dev perspective after its up and running is commit to master. No need to build locally.
The action can be configured any way you like, if for example you want to kick off when a commit is made to another branch.
How about multiple commands on the same image file? Looking to do a preload with it, can you then run ‘config generate‘ by including a second ‘command’ line?
At the moment at the top of the file it does cd ${GITHUB_WORKSPACE} to point to the checked out repo. Then echo -e ${INPUT_ROOT_CERT} > ca.crt is placing my super private .crt key into my repo. Which means any commit actions or packaging of assets I do later may contain my .crt key?
Just wanted to mention that balena-cli is now publishing Docker images so there’s no need to manually wrap it. Would love to hear your feedback and how it works for you. You can find out more here: balena-cli/DOCKER.md at master · balena-io/balena-cli · GitHub
I had begun just that. But I ended up basing my workflow off yours but building it into the GitHub runner so it works a little different. Which means I don’t have a way to test right now
@teslov do you think this action could be adapted to also push to balena-cloud with some sort of selector? Presumably it would get around the self-signed cert problem which might let the github hosted runner work.
I’m wondering how viable it would be to have an App on the Balena Hub that contains all the setup required to run a Self-Hosted Runner? So someone could install the self-hosted-runner app (the Docker container) on to an Intel NUC, VPS or other hardware and then use the community CLI action to deploy via that app.
It would be great to get your technical expertise on the potential of something like this, do you think it is viable or foresee any blockers?
@maggie0002 I totally forgot about Github Actions self hosted runners in the context of Balena! I had experimented with it a year or two ago, but abandoned because I thought it was limited to running on x86 machines only.
I guess I was wrong since the runner can be installed on ARM too.
If the GH runner could be install on a Pi in the same network as local balena devices, then I think that might solve the develop globally → deploy locally problem we’re discussing.
I totally agree with that.
Early we can’t use self-hosted runners on ARM. Since it is possible, we can create an app for BalenaHub, to just install it from. If balenaHub is accessible for the openBalena instances, seems that all ca.crt already exists on the device, and it will solve the problem of self-signed certs.
In that way of thinking you can deploy and distribute builders across your balena network
Sorry for the delay in replying, unfortunately I don’t have much time online due to russia’s insane war against my country, Ukraine. Now we live in the regime of planned outages, and everyone has 4-6 hours of electricity per day, sometimes more, sometimes less, but I indicated the average duration.
I will be able to respond from time to time, but don’t put too much hope in me, because the situation is such that nowhere in the country is safe yet. There is always a chance to come under fire from Russian missiles, and not be able to answer further on the forum.
But this is actually a common thing for us, this insane and senseless war of russia against us. We donate, we work, we fight for our freedom, and we will not give it to anyone.
If I can help, I will try to answer.
In advance, I do not see any blockers from the architecture of the runners. They work in approximately the same way as balena devices. GitHub servers are pinged, asking if there are any new build jobs