Managing Mir snaps

Mir Docs
1

Mir snaps

We’ve a number of snaps around Mir to manage and, over the last day, @saviq and I have been trying to get some consistency and automation into the way we manage them.

To recap, these are the snaps based on Mir:

  1. mir-kiosk is our recommended solution for IoT use-cases
  2. mir-test-tools is a snap of the tests and tools we’ve found useful for proving Mir works on various devices
  3. egmde is a Mir based “desktop environment”. Unlike the other snaps we maintain it is a classic snap and will not install on Ubuntu Core
  4. egmde-confined-desktop is also a Mir based “desktop environment”, but is an experiment to determine the limitations and possibilities of a fully confined snap

Typically, we build each of these snaps with the current release (or release candidate) of Mir and also with the latest development “master” branch.

Managing automated snap builds

We use launchpad “snap recipes” to build these snaps. We use Launchpad directly, not through the snapcraft build tools as this allows us to specify source of the Mir libraries to use (either ppa:mir-team/rc or ppa:mir-team/dev).

We also needed a way to determine if the version of Mir in the snap is up to date with the version of egmde (where appropriate), Mir and the snap packaging. To do that we use the version string in the snap as follows: [<server-version>-mir]<mir-version>[-snap<snap-version>]. Like this:

mir-kiosk mir-test-tools edge egmde-confined-desktop
1.1.2-snap73 1.1.2-snap39 82-mir1.1.2+dev168-snap53 82-mir1.1.2+dev168-snap18

Here “1.1.2” (or “1.1.2+dev168”) is the current Mir version (release or development), “82” is the egmde version and “snap18” is the version of the snapcraft packaging.

Generating these version numbers isn’t quite trivial, the snap packaging for each snap has some variant of the following:

  ppa-mir:
    plugin: nil
    override-pull: |
      sudo apt --assume-yes install software-properties-common
      sudo add-apt-repository -yu ppa:mir-team/release
      snapcraftctl pull

  recipe-version:
    plugin: nil
    source: .
    source-type: git
    override-build: |
      git rev-list --count HEAD > $SNAPCRAFT_PART_INSTALL/recipe-version
    prime:
      - -recipe-version

  egmde:
    after: [ppa-mir, recipe-version]
    override-pull: |
      snapcraftctl pull
      server_version=`git rev-list --count HEAD`
      mir_version=`LANG=C apt-cache policy mir-graphics-drivers-desktop | sed -rne 's/^\s+Candidate:\s+([^-]*)-.+$/\1/p'`
      recipe_version=`cat $SNAPCRAFT_STAGE/recipe-version`
      snapcraftctl set-version $server_version-mir$mir_version-snap$recipe_version
      if echo $mir_version | grep -e '+dev' -e '~rc'; then snapcraftctl set-grade devel; else snapcraftctl set-grade stable; fi

The final piece that pulls this all together is a script that runs in ci. This checks each of the snaps version strings against the contents of corresponding PPAs. That gets an automated build of the snap to the edge (for mir-team/dev, and beta (for mir-team/rc).

Ensuring security

Many (probably most) snaps include some packages from the Ubuntu archives. It’s easier that way than to build the whole dependency chain yourself and it actually has an additional advantage - the Ubuntu Security team publishes security notices for all the packages under their care and the review-tools snap has the means to inspect snaps with that in mind. It will return a list of issues your snap is affected by.

We have now added a daily job in our Travis setup that checks these for the snaps under our care. Every 24h (the process requires downloading and unpacking the snaps, so we don’t want to do this all the time) the currently published snaps are checked for packages that are affected by a security issue and those snaps are rebuilt if the checks are positive.

Here’s an example, which resulted in mir-test-tools being rebuilt:

…
Processing channel candidate for snap mir-test-tools…
Found USNs:
{'679': {'libsqlite3-0': ['4019-1']},
 '680': {'libsqlite3-0': ['4019-1']},
 '681': {'libsqlite3-0': ['4019-1']},
 '683': {'libsqlite3-0': ['4019-1']}}
Triggering mir-test-tools…
…

As you can see, it’s quite easy to integrate and it’s definitely worth the time. There’s many security issues discovered and fixed daily, automating the rebuilds takes a lot of manual maintenance, ultimately ensuring a higher quality of your snaps.

Humans still required

The final stage of promotion to devel and stable still takes a manual intervention. We typically push beta to devel after a Mir release, and issue a “call for testing”. If no issues show with lab or user testing we promote to stable after a week.

3 Likes
2

I added a section about Ensuring security above.