I have jbang.dev setup to automatic test and build on tag on several “stores”: brew, scoop, chocolatey, copr, github actions etc. all of which is automated so I don’t have to anything besides hitting release button on my github project.
Now I want to add a snap - and I can’t figure out how - all seem to rely on a human clicking in the webui which just won’t work for me.
I’m looking for way to just get notified the snap has been built, then run a basic automated verification and then publish the release to stable.
Looks like you are using GitHub, so the easiest method is to use the snapcraft build services, by default everything in master will end up in the edge channel. You can then use the CLI snapcraft (from some form of automation) to promote that build to the beta, candidate or stable channels. After testing the edge build, of course.
You could also use your favorite CI tool like GitHub Actions, Travis, … and build everything with the “snapcraft” command. This will of course give you the ultimate control how to do things but it’s trickier to setup
I use snapcraft for local test builds and mostly the build service for everything else I publish.
I noticed that you have the snap sources in a separate repository, that’s fine, just not the default excepted behavior of the build services. Manually adding the webhook to the the jbang repo will probably do the trick, or possible for greater control just trigger it from CI… or just build it your self like you do with the other packages, I “think” there is an GitHub Action available, never tried it my self.
I have it in a repo for it self so I can just tag it when release is ready to go and avoid any possible retags/rebuilds affects everything else - and also having it on all the various platforms is a nice plus.
I have activated the automatic build on push and it seem to work but haven’t found a way to know when the release is ready to be promoted and even I did how do you know what is the right revision to move forward ?
What we’ve done for Warzone 2100 is a combination of:
The Snapcraft “GitHub integration”, which gets us “edge” builds automatically with every push to the master branch.
A “combo” of a separate GitHub repo, GitHub Actions workflows, and a Launchpad repo to automate stable Snap builds as part of our release process (which involves, similar to what you’ve described, publishing GitHub Releases to trigger a bunch of automation).
More details on #2:
We have a GitHub Actions workflow in our main repo that handles the logic of tweaking the snapcraft.yml to build a tag directly (which is required for our auto-versioning process), and pushing changes at the appropriate time to the snap-stable-build GitHub repo. This workflow triggers as follows:
On tag push, this should run to “verify only” (i.e. tweaks the config, and makes sure it can successfully build the Snap, without pushing the config to the snap-stable-build repo)
On regular push, this should run to “verify only” - if pertinent files are changed
On GitHub Release publish event, this should run and push to the snap-stable-build repo
Permit manual triggering (that pushes to the snap-stable-build repo), in case snap config for the latest tagged release needs an update
(I apologize for the brevity - I have not had a chance to write up a detailed tutorial on this. But hopefully that’s enough details to reproduce it.)
You could get away without a separate “stable” GitHub repo, and just push directly to LaunchPad, but we have various requirements regarding user permissions and “secret” scoping.
If I understood correctly, the point is that, so far, the only automated way to publish to channel “stable” is doing it using LaunchPad, and hence mirroring the stable repo there to push the thing
This is fine if you just want to compile for the amd64 architecture.
For us, one of the advantages of using LaunchPad is that it supports the same (long list) of architectures that the Snapcraft GitHub Integration does for edge builds. (You can see this in the architecture drop-down.)
indeed my requirement was lighter, I just wanted a simple way to release to stable, but I’ll consider it if I need any less common arch