Juju snap plans, tracks and channels


#1

Currently we have a single track, latest, that has four channels. We’ve abused these to have snaps delivered for the current stable released Juju, the in-progress next stable, as well as the edge daily builds.

This proposal for where we want to get to is the following:

We will create 2 tracks for Juju use. One track will be for 2.3 release which is the latest stable right up to the new 2.4 release. We want to allow users to stick with 2.3.X for a little while as 2.4 gets its legs under it.

Within the 2.3 track we want to utilize the channels in that track for exactly what it’s meant for.

2.3 track

  • 2.3/stable - latest stable release of 2.3.x
  • 2.3/candidate - what we expect will become the next 2.3.x release. This is used for QA solutions testing and folks validating the release.
  • 2.3/beta - not used as 2.3 has been released and so beta users would just get candidate releases
  • 2.3/edge - updated per commit landed against the 2.3 branch. This is the “daily” as we go from one 2.3 release to the next.

2.4 track

  • 2.4/stable - the latest stable of 2.4. This will also track the latest/stable as 2.4 is the latest release.
  • 2.4/candidate - what we expect will become the next 2.4.x release. This is used for QA solutions testing and folks validating the release. Currently this would be for when we deem 2.4.1 ready for release.
  • 2.4/beta - as 2.4 is out we’d not use the beta channel
  • 2.4/edge - updated per commit landed against the 2.4 branch. This is the “daily” as we go from one 2.4 release to the next.

latest track

  • latest/stable - currently the 2.4 stable release updated each time we release a new 2.4
  • latest/candidate - what we expect will become the next 2.4.x release. This is used for QA solutions testing and folks validating the release. It’ll turn into the 2.5 series once we have an RC candidate.
  • latest/beta - unused currently but will turn into the 2.5 series once we have a 2.5 beta1 release to work from
  • latest/edge - updated per commit landed against develop. This is the “daily” build of trunk and is currently the work in progress for 2.5

Give this lineup the team needs to update our various landing jobs such that they can release to the correct track. Currently, snaps are built and uploaded to the store via the LP build process. I’m not sure how we can adapt that such that as we build snaps for various versions we can make sure they end up in the right places in the right tracks.


#2

Sounds like a good layout and use of the various channels.


#3

The channels for 2.3 and 2.4 are now open. I’ve released the last stable release to each so we now have

  • 2.4/stable at 2.4.0
  • 2.3/stable at 2.3.8

We can now begin to work on automating the builds into the release processes we need from here.

You can see the tracks listed out here: https://snapcraft.io/juju


#4

beta is currently 2.4-rc3 (and as @thumper points out, behind candidate and stable).

With the new tracks, should we then points 2.4/edge|beta|candidate point to the 2.4.1-* builds?
Where should beta then point? at edge? (i.e. 2.5-beta1-).

Seems like we’re in an awkward time with versions and tracks :slight_smile:


#5

Yes, the next steps from here are pointing the various builds at the track/channels now that they exist.

I would think that we’ll need to update the various build jobs to handle comitting to the git repos when they need to with the info for each track we have going? Can we keep the single edge job, for instance, but have it pushed whenever a 2.3 branch, 2.4branch, or develop are merged to?


#6

To clarify; the setup for which track gets built into (and how the snap is actually built) is done on the Launchpad end.
All that job does is update a git repo containing the build snapcraft.yaml and pushes it, LP monitors that and builds on new commits.

To answer your question;
We should be able to make a couple of jobs (we can template it in our JJB, so very little extra bits needed) to push to different branches and have the snap builds handled by LP.

I’m not 100% sure how the LP snap builds are setup, but I’m sure it’s not a biggie


#7

FYI, the 2.4/stable is currently still sitting at 2.4.0 while stable is 2.4.1.

zeestrat@vagrant:~/dev$ snap info juju
name:      juju
summary:   juju client
publisher: canonical
contact:   http://jujucharms.com
license:   unknown
description: |
  Through the use of charms, juju provides you with shareable, re-usable, and repeatable expressions
  of devops best practices.
commands:
  - juju
snap-id:      e2CPHpB1fUxcKtCyJTsm5t3hN9axJ0yj
tracking:     stable
refresh-date: today at 07:36 UTC
channels:
  stable:        2.4.1                     (4768) 55MB classic
  candidate:     2.4.2+2.4-b866365         (4812) 63MB classic
  beta:          2.4-rc3                   (4583) 55MB classic
  edge:          2.5-beta1+develop-6e24852 (4816) 66MB classic
  2.3/stable:    2.3.8                     (4423) 55MB classic
  2.3/candidate: ↑
  2.3/beta:      ↑
  2.3/edge:      ↑
  2.4/stable:    2.4.0                     (4587) 55MB classic
  2.4/candidate: 2.4.1+2.4-9181c94         (4700) 63MB classic
  2.4/beta:      ↑
  2.4/edge:      ↑
installed:       2.4.1                     (4768) 55MB classic

#8

@szeestraten I’m currently working on this. While we’ve got the tracks setup it’s manual and I haven’t updated the various release tooling and documentation/checklists yet so that it’s perfect. I’ll have it updated in a few here. Apologies while we smooth out the rough edges of the new setup.


#9

Heads up that Heather got working the 2.4 branch builds going into the 2.4/edge channel. With that done I’ve closed the latest/candidate channel which will be the home of 2.5-rc1 once it’s available.

If you’re looking to test out the latest in the 2.4 commits make sure to use the 2.4/edge.