For ease we would like for the snap to be automatically released to the stable channel whenever a new release is tagged. We were told that the fact that’s currently not possible is because the architects of snapd expect that there has to be some kind of manual testing before a new release of a software. While that might be a fare observation for some cases, there are scenarios where there may not be a need for manual testing or a project may not have the resources to do so.
One suggestion is that build.snapcraft.io could have that as an optional feature, that is off by default.
@evan suggested to bring the request to “snapd architects”.
Hello, and sorry for the lack of a timely response on this one.
I believe the store team is already working on a mechanism to simplify the workflow in this case.
At the same time, I really hope we don’t get a feature that will do a completely automatic release to any channel besides edge, with the following rationale: we cannot really claim something is stable before anyone has looked into it at all.
There are several things that can go wrong during a build process, and given the nature of snaps once the snap is released it gets automatically refreshed into everybody’s system, so it’s important that the final result built gets a chance to be looked at before it is widely distributed.
The workflow I hope we get to eventually is that the build service will build the stable snap and make it available for installation by the developers. Then, after someone has looked into it, just click a button saying “Yep, that looks good to go into everybody’s systems!”.
That is basically the workflow now though - build.snapcraft.io builds and releases to edge, then you “click a button” or snapcraft release foo 123 stable. Also, there is nothing blocking you from achieving the build and release direct to stable workflow outside of build.snapcraft.io.
That’s not the same thing. We don’t want something tagged stable in the repository going into edge. We want it to be built and made available for the developer to install locally, and have a proper notice in the UI and a trivial way to get that to go out into the stable channel.
We did cover that during the last sprint in London, together with the design team. @carlaberkers may have more details.
While your arguments make sense, there are cases which that might not cover.
Here is a scenario: Today was a release day for our stack, we released multiple libraries and our router. The router is packaged as a snap, though that’s not our main medium of distribution just yet. We released our router to DockerHub, pypi and snap store, though the testing only took place for the docker container that are part of our CI.
So given the resources we have and the frequency by which we do releases, its a challenge for us to all that testing.
So maybe if build.snapcraft could provide some API through which we could find “which snap revision refers to which commit” then we could do some automation on our end and do the release through snapcraft release.
@om26er That’s a sensible suggestion, and that feature I alluded to above definitely needs some kind of programmatic interface as well, as we’ll want to have access to it via snapcraft too.
Just to be extra clear, the issue isn’t just doing the release automatically. We could easily do that one our end. The issue is making sure that whatever was in fact built by the automated infrastructure is in fact stable and may be distributed into people’s production systems automatically.
We don’t have concrete work on this in the pipeline right now, but we have discussed better tagging/metadata for the builds to capture the origin commit and/or trigger source. This is related to the build-set idea as well, where we would be able to link together builds for multiple archs that came from the same commit/trigger.
We only want to publish to stable channel when we tag a new release on GitHub. This doesn’t necessarily have to be automatic on build.snapcraft.io, though we need some kind of reliable to way to check the revision number of the snap built by b.s.o and add the release magic in our own release management tool.
We need to publish Crossbar snap to stable and want to ensure its always in sync with our Docker containers and pypi releases.
Sure, that’s what I did for MAME. I have two branches. One which builds (whenever I trigger it) and pushes to edge only. It gets the stable version from a file in the upstream source tree. The other builds and pushes to candidate and beta only. I’m doing this because the build service can’t cater for this use case right now. I use lp-build-snap to trigger launchpad to do the builds.
I could push to stable, but there’s a bug in the snap currently which means I need process-control to get audio working. Once that works, I could probably have launchpad build and push directly to stable.
Here’s the result:
alan@KinkPad-K340:~$ snap info mame
name: mame
summary: Multiple Arcade Machine Emulator (MAME)
publisher: popey
contact: alan@popey.com
license: unknown
description: |
MAME is a hardware emulator. it faithfully reproduces the behaviour of
many arcade machines (it is not a simulation). This program is not a game
but can directly, through ROM images, run the complete system of these old
arcade machines. These ROMs are subject to copyright and it is in most of
the cases illegal to use them if you do not own the arcade machine.
.
This package provides the MAME binary and configuration files and support
libraries.
.
Place ROMs in "~/snap/mame/common/roms" or edit the ini file located
in "~/snap/mame/common/mame.ini" to point to where your ROMs
and other files are.
snap-id: D2AbMrcy0frlQRhokuBnhAtABqtw8hJb
commands:
- mame
tracking: candidate
installed: 0.194 (96) 117MB -
refreshed: 2018-02-25 03:17:35 +0000 UTC
channels:
stable: –
candidate: 0.194 (96) 117MB -
beta: 0.194 (96) 117MB -
edge: 0.194-b38f1d0 (95) 118MB -
However, as with your requirement, it’s totally under my control. I choose when to build and push to the store via a command on my laptop lp-build-snap --lpname popey mamestable (and lp-build-snap --lpname popey mameedge).
Worth a look perhaps rather than waiting for build.snapcraft.io to grow the features you need. Launchpad is way more flexible for these use cases.