Core snap delivery process

snapd
1

Intro

This document describes the delivery process of the core snap from development to release, ie, when it reaches the stable channel. It includes the criteria for promoting a snap from one channel to the next, the actors involved and the actions performed after a successful promotion.

Development

During development we apply continuous integration principles to test snapd’s code base automatically using static, unit and integration tests through the spread suite:

  • Each GitHub’s Pull Request triggers the execution of the full suite, static and unit tests using as source the code at the PR. The PR is only merged if the tests are green.

  • After each merge with a new test execution is triggered using master as source.

  • Daily tests:

    • Execution of the nightly suite (includes long tests like those related to docker and unity)
    • Execution of the main suite with reexec disabled
    • Smoke tests with instance booted from pristine image exercising system-user autoimport

  • Event driven tests, which are triggered in response to changes in external resources:

    • New staging store endpoints versions (including SCA, CPI, SAS, SSO)
    • New production store endpoints versions (including SCA, CPI, SAS, SSO)
    • New kernel snap in each channel for amd64 architecture.
    • New gadget snap in each channel for amd64 architecture.

Edge channel

A new core snap is generated daily using deb packages built from snapd’s master branch and uploaded to the edge channel. Once this event is detected, the following tests are performed:

  • Full suite execution for amd64 and i386
  • Refresh core snap from stable to edge for amd64 and i386
  • Full suite execution reexec-ing from 2.21 version of snapd for amd64 and i386
  • ubuntu-core transition test
  • Full suite execution with snapd deb installed from proposed and unmodified core for trusty, xenial, yakkety and zesty

Beta channel

When all the required features for the current cycle are in place, a new release branch is created in GitHub, the deb packages are generated from it in the team’s PPA and a core snap is built using those deb packages.

The verification at this stage is mainly automated, including also part of manual verification for setting up the ubuntu-core systems (only happy paths in this case).

As soon as the core snap is detected in the beta channel the following tests are executed:

  • Full suite execution for amd64 and i386
  • Refresh core snap from stable to beta for amd64 and i386
  • Full suite execution reexec-ing from 2.21 version of snapd for amd64 and i386
  • ubuntu-core transition test

As part of the validation at this stage we execute the full suite on all the reference ubuntu-core platforms, including amd64, i386, pi2, pi3 and dragonboard. Given that the goal of the validation is the promotion of the core snap we need to make sure that it plays well with the rest of fundamental snaps (gadget and kernel) currently at the stable channel, because the promotion of those are not in sync with core, we don’t know when they will happen. If after executing those tests, at this stage or at candidate, a new kernel or gadget are promoted to stable (this would be detected by our automated tools) we need to execute these tests again with the new stable snaps.

There are two kinds of validations:

  • Using an image built with core from beta and gadget and kernel from the current stable
  • Using the latest stable image and refreshing core to beta

In both cases, after manually setting up the instance using console-conf, we execute the following sets of tests:

All the test results are published on https://forum.snapcraft.io/

Candidate channel

After a successful validation at the beta channel the core snap is promoted to candidate. The validations at this stage are mostly manual, apart from these automated tests triggered after the new snap is detected in the candidate channel:

  • Full suite execution for amd64 and i386
  • Refresh core snap from stable to candidate for amd64 and i386
  • Full suite execution reexec-ing from 2.21 version of snapd for amd64 and i386
  • ubuntu-core transition test

We rely on crowd testing for the candidate validation, when the snap is promoted we create a call for testing post on https://forum.snapcraft.io/ and also send a message to the public snapcraft list. Additionally we execute the manual tests described in Core snap manual tests

Stable channel

After the core snap hits stable wee execute the following automated tests:

  • Full suite execution for amd64 and i386
  • Full suite execution reexec-ing from 2.21 version of snapd for amd64 and i386
  • ubuntu-core transition test
5 Likes
2

I’m a rather non-technical user and maybe I don’t need to know, but what does this mean:

‘When all the required features for the current cycle are in place, a new release branch is createed in GitHub, the deb packages are generated from it in the team’s PPA and a core snap is built using those deb packages.’

What are the Deb packages exactly and how is this different to how the Core Snap is build during the Edge part of the cycle?

3

snapd, snap-confine etc

4

So during Edge the Core Snap is built straight from GitHub, then for Beta you instead generate Deb packages from the GitHub repo and then build the Snap from the Deb packages. I’m guessing there’s a reason why xD

5

no, the core snap is always built from the package archives from deb packages, optionally there is a PPA where builds from the github master branch can go in (as deb packages) that land in the edge snap.

1 Like
6

In both cases the snap is generated using the deb packages, for edge those deb packages are built from master and for beta they are built from the release branch, i’ll update the description to make this clearer.

1 Like
7

@Ads2000 To be clear, there isn’t a great reason for the process to be put in place the way it is in terms of the outcome. This is just reusing pre-existing infrastructure that is able to take source code organized in a number of places and produce a snap with properly compiled binaries for multiple architectures as an outcome, very similar to how we can assemble any other snap out of deb or rpm packages.

8

What does staging store endpoints versions and production store endpoints versions mean?