Why are postfixes not allowed in balena.yml version field?
We would like to be able to use our own postfixes seen in balena cloud, currently we see revisions of “0.0.0+rev12” instead of our latest tagged version.
We would like to be able to set our own semver version with postfix when the balena push is executed, for example a balena.yml could look like:
type: sw.application
version: '1.2.3+dev.abc123'
Where our own CI/CD pipeline takes care of filling out that version field.
So far, when we tried this, this is not accepted because balena.yaml does not support postfixes in the version field - thereby making it impossible for us to set our own edge versions when pushing to the balena cloud.
We understand that these versions have to be unique across several pushes, it is find when balena sees a same version tag and then adds their own “.rev2” after that, so it should be fine to add a “dotted” addition in case the same version occurs. Example:
version: ‘1.2.3+dev.abc123’
And if that same version is published again (our CI/CD mistake), balena should be able to do:
version: ‘1.2.3+dev.abc123.rev2’
This way, we can get rid of the “0.0.0+revXX” as we seem to be stuck with the continous zeroos,
Let me know if we made a mistake or if something is not clear,
Can you clarify the balena-cli version that you have installed and the exact command you are using?
I was able to balena push a release with the exact balena.yml that you shared and I can confirm that 1.2.3+dev.abc123 shows up on our dashboard correctly.
Seeing 0.0.0 versions on our dashboard probably means that the version in the balena.yml can’t be parsed by our semver validator. For example a v prefix in the balena.yml (like version: 'v1.2.3' ) could be causing this. The our cli though should raise a warning during the balena push that the provided version isn’t semver compliant.
Your understanding about the +revN suffix is quite accurate. The +revN suffix is only added by our backend on the release.raw_version field (which our dashboard shows) when pushing additional releases with the exact same major.minor.patch in order to have a unique version string that can be used to identify a release in a given fleet.
The uniqueness rule that we enforce is <fleet, major, minor, patch, semver prerelease, variant, revision> , where the revision is the revN part that our backend adds on subsequent same-semver releases.
For example doing a second balena push again the balena.yml that you provided resulted a 1.2.3+dev.abc123.rev1 release to be created.
Let me raise though that the semver build metadata (like the +dev.abc123 in your example) are not considered in the uniqueness rule, since the semver spec specifies that they should have no effect in semver comparisons.
It was the balena-cli version that was a few versions behind in our own devops tooling. After updating the balena-cli to latest version, the versions are now indeed properly showing up from what we have filled into the balena.yml
In reversed order, at the bottom our earlier “0.0.0+revXX” and now we properly see our own semver with our added githash.
