Snapcraft not building RCs or stable releases

[olizilla]

the snapcraft autobuild set up only tracks the default branch. go-ipfs uses release branches to allow work to continue against the default branch while only fixes land on an rc branch while it is in testing. This means the snapcraft autobuild system is not creating a snaps for our stable releases or rcs.

See: canonical/snapcraft.io#2861

In order to publish new releases we need to handle it manually. We could possibly mirror go-ipfs in launchpad http://www.ktechpit.com/ubuntu/building-snaps-launchpad-auto-build-server/ or just build the snaps from CI.

[olizilla]

it looks like we need the custom launchpad set up to keep multi-arch magic. @rvagg can you give me a quick intro to the Node JS launchpad set up you mentioned?

[olizilla]

Alternatively, we can go back to managing the snap releasing from https://github.com/ipfs-shipyard/ipfs-snap and add yet another cron job github action to update the snapcraft.yml as significant branches from ipfs/go-ipfs change.

[rvagg]

OK, let's see how much (if any) of this applies here, we're dealing with a different beast for Node.js and there's still a cron job involved. I've been meaning to covert this to Github Actions but it's still currently running on a server I maintain, regularly checking for releases from the upstream feed @ https://nodejs.org/download/release/index.tab and pushing updates for each maintained branch. There's also one that checks https://nodejs.org/download/nightly/index.tab which goes out every day.

There's a slightly out of date version of the script that runs stored here: https://github.com/nodesource/distributions/blob/master/snap/snapcraft.yaml.sh (I don't have access to that repo anymore and haven't bothered upstreaming my latest but it's close enough). I have a repo with a branch for each release line of Node.js plus master for the nightlies. You can see them here: https://launchpad.net/~nodesource/+snaps and the repo is https://code.launchpad.net/~nodesource/snap-node/+git/snap-node/+ref/node14 (that's for branch node14).

I have a cron job for each release line, spread over the course of an hour, that runs the script like this: ./snapcraft.yaml.sh -r14 -gnode14

So it checks out that branch, runs an update of the snapcraft.yaml file from the latest release on nodejs.org and if there's a change it pushes it up to launchpad. Then launchpad takes over and does the rest.

I have a launchpad "snap" config for each branch that's linked to the snap store so it can auto-publish, and they look like this:

Then I get to ignore it and have a pleasant surprise every time node --version shows I have the latest within a few hours of release.

I have challenges of maintaining all these tracks, and I have to go requesting a new one each time, but I have an agreement with the Canonical folks that it gets fast-tracked so it's just a matter of remembering to do it as soon as there's a new release line. But none of that should apply here.

My plan is to switch to GitHub Actions for the cron part of this, and also to get all of the scripting portion out into the public. I get complaints about how it's not as transparent as it could be and it's not so obvious where people need to complain to when it's not updated properly (doesn't help that my account is still called "nodesource" but this isn't affiliated with them anymore). I'm mostly fine with the launchpad side of this, it's quirky but it works and is nicely integrated with the snap store so I don't need to manage tokens or any of the store stuff myself. I did discover that launchpad<>snapcraft auth tokens expire after 2 years (iirc) so I had a few release lines stop updating without me knowing and had to track that down. So I need to remember to regularly re-auth. I wish there was a notification system for that.

[olizilla]

Nice, thank you very much @rvagg!

So go-ipfs has relatively short release lines compated to node; 0.6 has been replaced with 0.7 since I opened this issue. I've set up a mirror of go-ipfs on launchpad, but as far as I can tell, I would need to set up a new snap configuration in launchpad for each new go-ipfs release, as we run a release-v<x.x> branch for each release version. It looks like this path would have a tedious level of admin...

I'm thinking I could whip up some github actions over on https://github.com/ipfs-shipyard/ipfs-snap and basically have it poll the go-ipfs repo for changes, and patch the source-tag a release tag is pushed, and have the snap store watch that repo instead. Will experiment and report back.

[olizilla]

Aha, we also have a release branch. A good enough solution here would be to track the release branch in lauchpad, and have it build and publish changes there to the candidate channel in snap. Then RCs and stable releases would appear on the candidate channel automatically, and we just promote the stable build to the stable channel when we're ready to call a release done.

That reduces the magic down to just, "configure a snap build on lauchpad", as we have the snapcraft.yml in the go-ipfs source tree already.

[olizilla]

For any fellow snap build yak shavers our there, I found this video walk through on publishing snaps from launchpad a good addition to Mr. Vagg's intro https://www.youtube.com/watch?v=X_U-pcvBFrU

[olizilla]

go-ipfs 0.7 is now published to the stable channel on snap 🎉

We now have

• A mirror of the go-ipfs repo on launchpad that will pull in changes every few hours (at canonical's leisure)
• An ipfs-candidate snap config that builds on change to the go-ipfs release branch and pushes to the candidate channel.
• An IPFS Maintainers team that would love you to be part of it.
• The edge channel snap is built and published automatically from master as before.

This means that go-ipfs release candidates and stable releases will appear automatically on the candidate channel for the snap, and anyone with access to the ipfs snap listing can promote stable release to the stable channel after doing hte go-ipfs release dance. 👯

[bertrandfalguiere]

Should promoting stable releases from candidate to stable be part of the checklist for the dance, then?

[olizilla]

@bertrandfalguiere absolutely! I shall add it to the checklist and step through it with @aschmahmann

[rvagg]

I think the Node case is fairly special in that we push their release track feature pretty hard. They've had to do a bunch of dev work around that stuff to support Node's style of supporting many release lines and preferring users to opt-in to upgrading between release lines. That's probably not applicable here. Snap users mostly expect automatic upgrades to their software and for those upgrades to handle migrations where possible.