Introduction

In certain cases it is necessary to be able to stage new click packages before their official release in the stable store. Situation like this happens when new features are added to the rc-proposed images and introduced in a new framework which is not yet available in any stable image. In such a case, click packages that use the new features and depend on the unreleased framework need to be somehow staged to be made available to dogfooders and testers without disrupting normal stable phone users.

The currently implemented solution is click-locking and staging the click in the store's upload queue. In this process, we manually lock down selected click packages on snakefruit from click-sync and build rc-proposed images with those pre-installed.

Rationale

Ideally, a click application that depends on a new framework and is published to the store should not be visible for normal users until their phones receive the framework in mention. Sadly, the current implementation of the store allows only one version being visible. This means that if a new version is published that requires an unreleased framework, the application is no longer visible to all stable phone users (those without the new framework).

The store does incorporate logic to allow multiple channels for a single applications, so it could allow an explicit staging place for new apps - sadly our click format is not compatible with those features. We would either have to migrate clicks into snaps or modify click to support the required bits. Both solutions are very time-consuming.

The click locking mechanism has multiple pros. One of them is the ease of implementation, as basically all the elements were in place and we're not really intrusive with new changes. It also gives some potential flexibility.

Process

For locking down the click package in rc-proposed:

• New click package is built and a CI Train landing ticket prepared
• QA signs off the package, giving a +1 on release
• The Lander prepares a properly versioned (with the final version number) click package and uploads it into the store, marking it explicitly as 'not meant to be published'

• The Lander downloads the signed click package from the upload queue in the store and sends it over to the LandingTeam

  • Best bet is sending it over to sil2100
  • It's also possible to reach out to anyone with snakefruit access
• The signed click package is copied to snakefruit's /home/lzemczak/locked-clicks directory
  • Anyone with snakefruit access has write privileges in this directory
• The full filename is added to the /home/lzemczak/locked-clicks/locked_clicks_list to finally lock down the click
• During next click-sync tick (which is happening twice in an hour) the locked click is stored
• Next rc-proposed build has the new click

For image promotion from rc-proposed/rc to stable:

• The rc-proposed/rc image is tested by QA in the promotion process
  • It has all the staged clicks locked down inside
• QA gives green light on promotion, images get copied to stable
• Phased updates are started
• Once phasing ends, all locked clicks that are staged in the upload queues are now published into the store
• The /home/lzemczak/locked-clicks/locked_clicks_list file is updated (or removed) to flush all the packages that have now been published

For pushing a new version of an already staged package:

• A click package is staged in the store and locked on snakefruit
• New version of the same package is prepared and signed off
• The new version goes through the same lock-down mechanism as above, overwriting the previous package in the queue