I currently maintain the emacs snap and this is automatically built and published via build.snapcraft.io to publish a build of the current stable emacs release (26.2). Recently I have thought about perhaps also publishing a build of the current emacs development release, and fortuitously it seems I am not the only one who thinks this might be a good thing to have and so it would seem to me the best way to achieve this is to publish this in a separate channel (called devel or snapshot etc?).
However, I have no idea how this would be done given the current use of build.snapcraft.io - it seems this only builds from the master branch of the github repository and only publishes to the latest/edge channel - is it possible to use build.snapcraft.io to support building from a different branch from the same repo to publish to a different track? Is there some other standard way which is recommended to do this to keep the awesome functionality of automated builds from the repo getting automatically published to edge (do I have to look at TravisCI?)
Once the initial import is performed, select the branch you want to build and click the “Create snap package” link. Fill out the details and it should start publishing builds to the chosen channel.
One downside to this is that builds will be triggered when the code import job runs rather than when you push to Github. On the plus side, it can produce builds on multiple architectures: something that is non-trivial to do with Travis.
Thanks @jamesh - yeah I really value using launchpad as a build service for both multiarch builds and I consider it a more trustworthy build environment, so I assume from your instructions this would approximately replicate the existing functionality of using build.snapcraft.io but without the instantaneous building on new commits - instead only on the periodic repo sync - but this allows to choose both which branch to build from, and which channel to push to - this sounds just what I need - thanks!
The builds should be identical to what you get through build.snapcraft.io: it is the same build infrastructure either way.
If you want more control over when the builds are triggered, another option would be to push your repository to Launchpad manually: this would give you the same “build on push” functionality, but require that you to push to two locations. The code import route lets you keep Github as the primary code repository, which could be useful if you’re accepting contributions via pull requests there.
Thanks - one more question - so then I want to disable the builds via build.snapcraft.io - but it is not clear if deleting the entry via the trashcan icon on https://build.snapcraft.io/user/$USERNAME will also delete the existing emacs snap released builds from the store - since it says
Are you sure you want to remove this repo from the list?
* The name will remain registered.
* Removing this repo will delete all its builds and build logs.
Do you happen to know if this will keep the existing released builds?
As I understand it, it won’t have any effect on snaps published to the store. What it will do is delete the Launchpad build recipe it created for you, which stores copies of the built snaps and their logs.
The build recipes the website creates can be found here:
The information you see on each of those linked pages is the kind of thing you’d lose by deleting the build on build.snapcraft.io.
