Use of channels and auto-publishing


The Mir project provides three PPAs:

  1. ppa:mir-team/release - for the latest release
  2. ppa:mir-team/rc - for the release candidate/latest release (we build the tagged release to /rc and test before copying to /release)
  3. ppa:mir-team/dev - for current development

Using the launchpad builders (which allow us to specify these PPAs in the build environment) we’ve been automating publication of various snaps based on Mir to the “edge” and “candidate” channels as follows:

  1. ppa:mir-team/rc => “candidate”
  2. ppa:mir-team/dev => “edge”

And, following testing of a release, promoting “candidate” to “stable”.

For snaps that rely solely on Mir seems a logical, effective workflow. The only complication in automating this is identifying when the content of the PPA is more recent than that of the snap in order to start a build. We currently extract the deb package version and use that to set the snap version string. (I.e. we poll the snap and the PPA to compare these versions and start a build accordingly.)

This doesn’t work so well when there are multiple dependencies: for example a Mir PPA and the egmde github repository. That is the case for the egmde and egmde-confined-desktop snaps.

The question

Detecting changes in dependencies and triggering builds when they change is something the snapcraft builders can do, so that could make things easier for us. (I realize that snapcraft builders don’t allow us to configure PPAs in the build environment, but that could be worked around if it were the only issue.)

However, switching to snapcraft builders would mean we cannot automatically publish to any channel other than edge (previous discussion here: Auto-release to stable from build service) and that seems messy when multiple configurations are being built.

There are “tracks” but we don’t need to support snaps based on multiple releases of Mir (which is the advertised purpose of “tracks”).

Publishing separate snaps to package builds based on Mir “release”, “rc” and “dev” also seems messy.

Is there something I’m missing that would make this scenario easier for me?

Dream answer

What would solve these problems well is a (hypothetical) way to configure the build environment to “production” or “development”:

  1. specify the target channel for auto-publishing to “candidate” or “edge” accordingly;
  2. have a mechanism (e.g. a script inside the snapcraft.yam)l to set the grade: accordingly; and,
  3. allow a scripts inside the snapcraft.yaml to act accordingly (for Mir, to set the right PPA).

While that’d definitely help, does it solve the entirety of the problem? Since we diverge around release time, like we have two recipes in Launchpad today, we’d need two “recipes” to build into the same snap name - masteredge and release/*candidate on snapcraft builders.

Not sure if that’s something that would want to do. But maybe we can “backport” dependency change detection to Launchpad builders? If that also includes detecting releases of build-snaps, I think we’d be in a much better place.

For clarity, there’s no such thing as a ‘snapcraft builder’, there is the Launchpad build farm, Launchpad API and which talks to the API to get things built on the build farm.

A little peak behind the curtain: already publishes automatically to candidate… and to edge? Can’t something similar work for Mir itself?

Again, I think scriptlets will help you here.

Agreed, I’m really asking about the difference between the launchpad web-based wrapper and the build.snapcraft wrapper for the launchpad builders.

There is no “Mir itself” snap, there is the mir-kiosk example you mention and mir-test-tools, both of which work as described above (and by you).

The thing to note here is that both recipes use the same snapcraft.yaml and the different results come from using different PPAs in the recipe. Lacking such a configuration point in build.snapcraft as it is now means maintaining two almost-identical versions.

Yes, the script can say snapcraftctl set-grade "devel" or snapcraftctl set-grade "stable", but it needs some external information (e.g. an environment variable) to decide which is appropriate.

Again, the script needs some external information to decide which is appropriate.

That too would help.

I’m not sure what role you envisage for build-snaps here. By my reading of the yaml reference “A list of snap names to install that are necessary to build” they are similar to build-packages, not stage-packages which is what I think you are imagining.