Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

Alan Pope
on 7 January 2021


Branches are an under-used but important feature of the Snap Store publishing capabilities. Indeed as I’m writing this post, I’ve never had a need to use the feature, and I’ve been publishing snaps for four and a half years. Let’s fix that!

Start with acorns

The rationale for branches is simple. Each snap in the Snap Store has a default track called ‘latest’ in which there are four channels named ‘stable’, ‘beta’, ‘candidate’ and ‘edge’. These are all typical buckets in which snaps are published for an extended period, perhaps months or maybe even years. Branches on the other hand are short-lived silos for publishing snaps. 

As a developer you may have a published application which has bugs users experience but you cannot reproduce. A temporary branch can be used to hold a test build of the application you’re working on to solve a bug.

If you’re tracking and fixing multiple bugs in parallel, each can have their own separate branch under the same snap name in the Snap Store. Branches are ‘hidden’, so unless someone guesses the name of it, users aren’t going to stumble upon potentially broken bug-fix builds of your application. 

Branches only live for 30 days, after which they’re deleted, and any user with the snap will be moved to the latest track for the channel. So a user who tested the branch latest/stable/fix-bug-12 and didn’t switch to another channel within 30 days, will be moved to the latest/stable channel on their next refresh.

Germinate

Let’s take an example. A user filed an issue on the Atom snap under the snapcrafters GitHub and provided a pull request. We can grab the pull request, build the snap with their fixes, test and publish to the store in a branch so they can try it out.

This could be automated with tools like GitHub Actions, but in lieu of that setup, let’s explain it with the manual steps.

$ git clone https://github.com/aminya/atom-2.git
$ cd atom-2
$ git checkout -b aminya-libstdc++6 master
$ git pull https://github.com/aminya/atom-2.git libstdc++6
$ snapcraft --use-lxd

Building atom
Building launcher
Staging atom
Staging launcher
Priming atom
Priming launcher
Snapping
Snapped atom_1.53.0_amd64.snap

Install the application locally to make sure we didn’t completely break it.

$ snap install atom_1.53.0_amd64.snap --dangerous

Upload to the Snap Store and release it to a branch. I selected the latest track as it’s the only track this snap uses. Other snaps may use different tracks for each supported release (e.g. node) or have separate tracks for stable and insider builds (e.g. Skype). We’re fixing the stable release, so I’m using a branch off the stable channel.

$ snapcraft upload atom*.snap --release=latest/stable/fix-65
Preparing to upload 'atom_1.53.0_amd64.snap'.
After uploading, the resulting snap revision will be released to 'latest/stable/fix-65' when it passes the Snap Store review.
Install the review-tools from the Snap Store for enhanced checks before uploading this snap.
Pushing 'atom_1.53.0_amd64.snap' [============================] 100%
released
Revision 269 of 'atom' created.
Track Arch Channel Version Revision Expires at
latest amd64 stable 1.53.0 265
candidate ↑ ↑
beta ↑ ↑
edge 1.53.0 268
stable/fix-65 1.53.0 269 2021-02-05T10:34:51Z

We can already see the branch exists under the latest track, stable branch, but we may want to confirm this – especially if the upload happened in GitHub Actions, a CI or other remote system where we can’t easily see the above output.

$ snapcraft status atom
Track Arch Channel Version Revision Expires at
latest amd64 stable 1.53.0 265
candidate ↑ ↑
beta ↑ ↑
edge 1.53.0 268
stable/fix-65 1.53.0 269 2021-02-05T10:34:51Z

Note, as mentioned earlier, only we as publishers can see the new branch. If a non-publisher looked at the channel map they wouldn’t see it. Non-publishers don’t have access to the snapcraft status command for this snap, and snap info just doesn’t show branches.

$ snap info atom 

channels:
latest/stable: 1.53.0 2020-11-10 (265) 242MB classic
latest/candidate: ↑
latest/beta: ↑
latest/edge: 1.53.0 2020-12-09 (268) 224MB classic
installed: 1.53.0 (x2) 224MB classic

I’m still currently tracking the build I “side loaded” onto my machine, which you can see with the “x” prefixed revision on the last line. We can refresh to the branch hosted in the store. Note that we can optionally omit the ‘latest’ track name, because it’s the default (and only) track. This also allows us to test the instructions we can provide to the author of the pull request.

$ snap refresh atom --amend --channel stable/fix-65
atom (stable/fix-65) 1.53.0 from Snapcrafters refreshed

Note: The --amend option is only required for us because we’re switching from a locally installed revision to one from the store. Users who only installed from the store won’t need that.

Now we have the fix published, we can let the contributor know via a comment on the pull request. Something like this will do nicely:

“Thanks very much for the pull request. I don’t have the ability to reproduce the issue right now. I have published a build of the snap incorporating your fix in a branch. Please could you install the build on a clean system, or if you have the snap already installed, refresh to this branch, and test it?

snap install atom –channel stable/fix-65
or:
snap refresh atom –channel stable/fix-65

If you’re happy with the fix, I’ll land this PR.
Thanks again!”

Once the user replies that this fixes their issue, we can land the PR and roll this into the next stable release. If it doesn’t, well, that’s more software engineering on the to-do list!

Get planting

Of course it’s not just bug fixes which can use branches. Perhaps you have a new feature to soft-launch in the application, or design changes you’d like to experiment with. Having a short-lived branch which is only known by a limited set of testers can be advantageous.

Branches are one of those features that sets the Snap Store apart from some other distribution methods for Linux. It’s not something most publishers will use, but once you know it’s there, it can be quite handy with only a small learning curve.

Join us over on the snapcraft forums if you’d like to discuss this or other features of snapcraft.

Photo by Colin Watts on Unsplash

Related posts


Aaron Prisk
3 April 2024

Creating Snaps on Ubuntu Touch

Community Article

This article was written in collaboration with Alfred E. Neumayer of the UBports Project. Tablets, phones and current technology’s capabilities are phenomenal. Who would have thought a thin, light, barely 10 inch device would provide all the power necessary to run Virtual Machines, wherever one desires while powered on battery? That a sma ...


Holly Hall
15 January 2024

Managing software in complex network environments: the Snap Store Proxy

Internet of Things Article

As enterprises grapple with the evolving landscape of security threats, the need to safeguard internal networks from the broader internet is increasingly important. In environments with restricted internet access, it can be difficult to manage software updates in an easy, reliable way. When managing devices in the field, change management ...


Igor Ljubuncic
21 December 2023

We wish you RISC-V holidays!

HPC Article

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found themselves in the last group at some point or another; you sit down to perform a task relevant to your needs or duties, but suddenly the machine does not work as ...