Nightly builds vs releases

Hi,

build.snapcraft.io is very convenient to quickly build and publish new versions of a snap.
However, I haven’t found how to do a few basic things.

A project will often push commits daily to its master branch, which HEAD can then be used for nightly builds.
But build.snapcraft.io will build and publish after each commit, which we might not want.

A project will also create releases, using git tags. These will likely be built only once, and used for publishing to stable. But build.snapcraft.io will want to use the latest commit.

What I’m currently doing is, in snapcraft.yaml:

version="$(git tag -l | egrep -v ‘^v|-rc’ | sort -rV | head -n 1)" # or similar depending on projects naming conventions
snapcraftctl set-version “$version”
git checkout tags/$version
make # or whatever is relevant

Which allows me to build the latest release, and then I manually promote to the relevant channels.

So, TL;DR: how can I have build.snapcraft.io:

  • build nightly snaps from master/HEAD
  • build a specific version when it’s released and/or with a manual trigger
    ?

Thanks !

2 Likes

Kinda really surprised this has received zero responses. Seems like a pretty important feature if you really want to use the snapcraft build service. I’m experimenting with setting it up for the cmake snap and this is one of the first things I’ve hit which is pretty much a showstopper. I have nightly builds and manually triggered tag builds working on Travis CI, but the snapcraft build service seems more integrated. Strange that it doesn’t have these features.

well, typically you’d simply use the channels (or for a more complex setup ask for tracks) … nightly builds go to the edge channel automatically, after QA you move them to beta etc … or your master tree goes to edge, tagged releases go to beta and after QA to candidate etc …

I already have separate tracks, one for each feature release so that users can stick with a particular feature release, but still get the bug fixes for that series. One of the problems with the way the snapcraft build service currently works, it assumes every build belongs to the latest track, but when you have to do a build for a back ported fix on another track, you end up with that other track’s build at least temporarily appearing on the latest track. That means anyone following that latest/edge channel is going to potentially get an older release appearing for the period before you move it away to the track it should have gone to. This could be resolved if a build could specify the track it belongs to (i.e. override of the default “push to latest” behavior).

The lack of any sort of scheduled build feature is the other missing part. At the moment, it looks like the only real choices are:

  • Set up some sort of manual cron job on a machine somewhere to simulate the web hook. This is super fragile and not something I want to maintain.
  • Set up a cron job to push a fake commit to the repo every day. This just fills the repo with meaningless noise, all for the purpose of triggering web hooks.

Neither of those is particularly attractive. Note that in my case with the CMake snap, the CMake source code and the snapcraft yaml are in different repositories. Absorbing the snapcraft yaml into the CMake source repo is not an option available to me, so they must be kept separate. The repo containing the snapcraft yaml very rarely changes, so having builds only triggered from pushes is not great. At least with Travis CI I can trigger a build and use a custom environment - this lets me specify a git tag to build instead of master, which is how I currently trigger builds for specific releases. The .travis.yml has logic which also uses that environment variable to upload the build to the right track. Would be great if the snapcraft build service had something equivalent.

I’d like to see you show us how to achieve that using the build service considering there aren’t any knobs to do any of those things.