Hi. I have a GitHub release for koalaman/shellcheck on cb57b4a. git describe calls it v0.6.0.
Snapcraft, on the other hand, unceremoniously labeled it “v0.5.0+git104.cb57b4a” and doesn’t appear to let me push it as a stable version.
How do I build and release a correctly labeled version of this commit as a stable version?
You should note that versions are actually only strings for user convenience and are not used for anything beyond this in the snap ecosystem. versions have no influence on the ability to release something to stable, the actual control of different package versions is in the hands of the “revision” parameter.
in that light it would be interesting what error you get if you try to release that snap to stable since even if you called the version “d.e.a.d-b.e.e.f-0.1.2.3” the snap ecosystem should not care.
regarding getting the right version from upstream, you should try to set source-tag: v0.6.0 in your snapcraft.yaml, that should pull exactly this upstream tag with a proper version string (you indeed need to bump that version if upstream does a new release).
Yeah, version strings are totally within your control as the developer of the yaml. There’s a few ways to manage this. Hard wire the version in the yaml with version: somestring. Use a script to determine the version with version-script: somecommand (such as git describe --tags). Or via adopt-info and snapcraftctl set-version somecommand inside the part override-build section.
The obs snap uses the latter which you could use as a reference. We use the logic there to build either a stable snap (which upstream do a new release) which gets us a nice tidy version number, or unstable builds of master, if there’s no upstream release newer than the last one we put in the beta channel.
Note that you can promote previous snap revisions to desired channel at any time at the “Releases and revision history for snap_name” page <https://snapcraft.io/_snap_name_/releases>:
If no such revisions are available you may always push a build of the specified source-tag to the edge channel, promote the edge channel snap revisions to the stable channel, then re-promote the previous edge channel snap revisions back to the edge channel:
In this case, I am both upstream and developer of yaml. The yaml is in the upstream repo. It is not a separate file.
This is what happens when I try to promote the mislableled v0.6.0 release:
Is this due to the grade: devel in the yaml?
Can I re-build and release v0.6.0 without this line? How? I am not willing to roll back my upstream github repo.
Do I need to create a separate yaml that doesn’t build from github, reconfigure snapcraft to use it, and then configure it back to build from github again?
yes … only strictly confined snaps with grade “stable” are allowed into the stable channel …
I wonder if OP wan’t to promote the snap revisions from the edge channel to the beta channel?
So here’s what I gathered:
build.snapcraft.io can not rebuild a previous revision from GitHub
Instead:
Install all the snapcraft tools locally, and snapcraft login
Clone your repo locally and check out the desired revision
If your snapcraft.yaml version field is git and you make any modifications to the repo, you must hard-code the new version. If you don’t, it will be tagged as dirty
Build a package for each arch:
for arch in s390x ppc64el arm64 armhf amd64 i386; do snapcraft cleanbuild --target-arch "$arch"; done
Push each package:
for f in *.snap; do snapcraft push "$f"; done
And also:
The grade field in snapcraft.yaml is not for the software being packaged, but for the packaging process itself. When autobuilding from GitHub with version: git, it should be left on stable at all times since build.snapcraft.io does not differentiate between building a release commit and any other commit.
FYI
I’ve implemented a possible workaround for this issue:
This ensures that a tagged release snap is always built in the automated build workflow.
