Change running commit from Balena CLI on OpenBalena Fleet

We have many commits to a fleet. Some say “success” and one says “running”. It should be easy to change the running I would imagine. However, we can’t find anything online illustrating the Balena CLI command. We are running the latest CLI. At the time of this post 13.6.0

Can someone help me document the command to change the running commit on an open balena fleet?

Hi brownster

I’d first like to confirm your question. You mention that you have several “commits” on a fleet. Are these the releases that you see when running balena releases <fleet> ?

If that’s the case, in order to switch a fleet to a specific release you can run a script. You can use this as a reference: staged-releases/set-device-to-a-release.sh at master · balena-io-examples/staged-releases · GitHub

That script is for a device. In order to pin a fleet, you can use this endpoint: Resources - Balena Documentation , so instead of "https://api.$BASE_URL/v6/device($DEVICE_ID)" you should use "https://api.$BASE_URL/v6/application($FLEET_ID)"

Cheers, Ramiro

1 Like

Thanks Ramiro,

It sounds like there is no simple CLI command for that as we hoped. We are still bringing ourselves up to speed with the SDK and how to best us it.

Right now we are looking at the admin project: GitHub - dcaputo-harmoni/open-balena-admin: Open Balena Admin

My hope it that this might fast track things. Unfortunately running into install issues at the moment.

Thanks again for the point in the right direction. Get to know the SDK or hope the admin project works out is my takeaway.

Hi brownster

Glad to help. I’ll also check with the internal CLI team if we have plans for this feature

Ramiro

@bversluijs first I wanted to say I read your blogpost this morning and it is such a great resource! Thank you so much for writing it; I’ll be passing it along to plenty of other interested openBalena customers.

In addition, I was wondering if you might have any suggestions for Chad based on your experience with openBalena. They are trying to find some best practices for setting releases using our SDK and I thought you might have some suggestions since you mentioned you use openBalena in production, and thus must have run across the need to manage your various releases over time. Any ideas or best practices you could share would be appreciated if you have the time!

Hi,

Thanks for the kind words!

Setting releases using the SDK is something I’ve used in the past, but haven’t used for quite some time. It’s definitely something I’ll be picking up in the near-future, because of our new release management strategy. At the moment, we’re testing our devices using local mode, and once it’s ready, we’re releasing it to the whole fleet. This isn’t best practice, so I won’t advise anyone to do it this way. But since we’re using Balena, publishing a release is less “scary”. When something goes wrong, debugging the problem is quite easy and publishing the fix is easy as well.

But to come back to the original question, there are some docs that use the API to pin a release to an application and/or device. I haven’t tested it myself, but it seems like this repo is updated to the v6 API, so you can use these scripts (I see these are mentioned already).


But about the best practices, a few years ago we were using tags to determine which device is running which release. BalenaCloud now has UI for it and I see the SDK also has support for pinning a release, but to be honest, there isn’t a “best-practice” afaik. Every project and organization has its own release policy. But what I can say is the policy we’re implementing is this:

  • Local mode for developing
  • Test devices that are running in-house
  • Test devices that are running at some locations
  • A/B testing groups
  • Release :tada:

The SDK can help you with setting tags and let the SDK search for all devices within an application with the tag (for example): POLICY = IN-HOUSE / TEST / GROUP-A / GROUP-B and setting the release for that group.


Hope this somewhat helps, but as I mentioned, we’re also experimenting with the release management. It’s a difficult subject and I think testing releases thoroughly and having some monitoring in place is always the best way to start. For example implementing and using Sentry for errors is always nice to have :slight_smile: