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:
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.)
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?
What would solve these problems well is a (hypothetical) way to configure the build environment to “production” or “development”:
specify the target channel for auto-publishing to “candidate” or “edge” accordingly;
have a mechanism (e.g. a script inside the snapcraft.yam)l to set the grade: accordingly; and,
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 - master → edge and release/* → candidate on snapcraft builders.
Not sure if that’s something that build.snapcraft.io 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.
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.
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.