Skip to content

Latest commit

 

History

History
187 lines (142 loc) · 7.46 KB

README.md

File metadata and controls

187 lines (142 loc) · 7.46 KB
Raw

Checkbox release process

NOTE: Here you can check the Launchpad Builders status. Our build process relies on Launchpad builders, and they may be down or very busy. This might prevent building the packages and snaps from being built.

When can you release a new beta version

A new beta version will be automatically released by the canary validation process. When this process passes, it moves the beta branch to the latest commit it verified calculating it from the version string. Namely if the latest edge version is 1.2.3-dev120, and it is verified, the beta HEAD will be moved to the 120th commit after the tag v1.2.3 (so that origin/beta/HEAD~120 is v1.2.3)

The verification process works as follows:

flowchart TD
    A[Wait for specific time of the day] --New changes--> D
    D[Build runtime/frontend snaps]
    A --No new change--> A
    D --Build failed--> E(Failure, do nothing)
    E --> A
    D --Build ok--> F[Verify snaps via Metabox]
    F --Validation ok--> G[Run canary testing on jenkins]
    F --Validation failed --->E
    G --Validation failed --->E
    G --Validation ok--->H(Move beta branch to the commit)
Loading

NOTE: This process is fully automated, you don't need to trigger it.

Promote the previous beta release to stable

Internal teams (mostly QA and Certification) are using the version in the beta snap channels or the beta PPA to complete their tests. If this version is validated, it can then be pushed to stable for other teams and external stakeholders.

Therefore, if there has been no negative feedback from internal teams after a cycle of testing the beta release, run the Stable release workflow to copy deb packages to the stable PPA and promote all snaps to stable.

How packages versions are generated?

Both Debian packages and checkbox snaps rely on [get_version.py] to calculate package versions from git metadata.

>>> from get_version import get_version, OutputFormat
>>> get_version(dev_suffix=True, output_format=OutputFormat.SNAP)
'2.9.0-dev38

The get_version module can generate the version for any packaging we support and can also be called from the CLI. The idea is that each commit done since the last tag is categorized using the postfix included in the commit message and the version is calculated as follows:

  • Infra: are changes to our CI/CD infrastructure, they are ignored
  • Bugfix: are bugfixes, the patch number is incremented
  • New: are new backward compatible features, the minor version is incremented
  • Breaking: are new breaking changes, the major version number is incremented

NOTE: If any commit is in a different format, the script will complain about it by logging it to the stderr. Don't ignore these messages: double check what was changed in the problematic commits and re-calculate the version accordingly

Tag the release

First you need to determine the version string for the tag. You can use the previously described script to do so:

  • Clone the repository and get the version 
    $ git clone git@github.com:canonical/checkbox.git
$ cd checkbox/tools/release
$ ./get_version.py --output-format tag
  • Tag the release 
    $ git tag -s "v2.10.0" -m "Beta promotion of: 2.9.1 → 2.10.0"
  • Push the tag to origin 
    $ git push --tags

Monitor the build and publish workflows

3 workflows are triggered on tag push events:

In addition to the above workflows, a Draft Release Note is created on Github with an auto-generated changelog.

Check the related Github Action logs to see if everything runs as expected:

  • Snapcraft is not blocked during the snap build process. For example, in this build, the i386 build was blocked on an error (Chroot problem) for hours before finally completing

Send the release e-mail

The release process should have created a new Draft Release Note. You can use this to prepare a release e-mail:

  • If this release comes with big changes for the user, you can talk about them in a Highlights section.
  • Not all changes in the Release Note from GitHub are meaningful for the end users. Highlight the ones that are most important for them by bolding them. For instance, changes related to the tooling used for Checkbox releases is not important to the users, but fixes for bugs reported by the users are!

You can see a sample release e-mail here.

Send the release e-mail to:

Note: You need to be registered to both these mailing lists in order to be able to send an e-mail to them.

References

PPA/Repositories

  • stable: For external customers.
  • beta: For Canonical internal users. This version should be the one used for Certification, and early QA pipelines.
  • edge: To test recent developments that are not yet in beta.

Projects released as Debian packages

Usage

Testing release tools

These are the steps to run the tests for the release tools:

# Only run the tests
python -m pytest
# Run the tests and get the coverage
python -m coverage run -m pytest
python -m coverage html

If you have tox instaled, you can just run

tox -e py310