Can't build from a branch other than the default branch

[didrocks]

I'm sure you know about that one, it's more for a tracking purpose.

You can't build to a different branch than master, which could be handy in that you have maintainance and release branch. Seems like a good opportunity for build.snapcraft.io

[evandandrea]

Hey Didier! Can you elaborate on your use case for building snaps from a different branch?

[didrocks]

Hey Evan! Yes:

• I have a master branch (pointing to 2.0 features) which goes to edge (in implicit "latest" track).
• I have a 1.x branch which gets regular bug fixes. I want it to publish in another track (once we have track support), like 1.x/edge

That way I always have latest release on all my maintenance branch

Another interesting note, would be to produce some snaps based on features: master -> edge ("latest" track) feature-foo -> features/edge/foo That way, people can test feature foo just in installing the snap in features/edge/foo (or if we don't have the 3 branch parts: foo/edge, having a "foo" track). Continous delivery, and continous testing of features! Sounds almost like CI-Airline which rings a bell to you, I'm sure :)

[evandandrea]

Thanks for clarifying. So we can call this tracks / major version branches support, as you suggest.

It will require design work. In terms of priority, I think we should implement organisations support (#132) before we come to this.

[didrocks]

:+1: in term of priority for org support.

[evandandrea]

"ondra: and one more thing, so looking to various github projects, they seem to tag releases,but not really push it to any branch, which is quite tricky to make build"

So perhaps we need to support a mapping of branch or tag to track.

[theshadowx]

At least it shouldn't be pointing directly to master but use the default branch set in Github.

In the other hand, it would be great if the branch/tag setting is something like automation build in docker hub.

[evandandrea]

This is happening for tarantool as well.

[lasconic]

+1 MuseScore has the same need.

[timsueberkrueb]

:+1: required for Liri Platform too.

[evandandrea]

Tracking a few more cases where this is needed:

• ethereum
• neuronify
• distlib
• atomify

[harshavardhana]

You can Minio under the mix here as well @evandandrea

[evandandrea]

@harshavardhana is 'release' the branch you want to build snaps from?

[harshavardhana]

Actually no just the tags is fine. I think this issue is not the same sorry for the confusion.

[timsueberkrueb]

Hey, any news on this one? It's the only real show stopper for me (and probably for the other mentioned cases too). ~Just using the default GitHub branch for a start won't be a very difficult change (I guess) but it would improve the story a lot for many users :)~ EDIT: Just learned this was supposed to be the case already! Looks like it hasn't taken effect automatically for my existing repo. Just readded the repo and hope it will work now.

[timsueberkrueb]

Interesting, it still doesn't work: https://build.snapcraft.io/user/lirios/platform-snap/89110 Any ideas? Am I doing something wrong? It is still trying to build from master. The default branch is clearly develop. Thanks in advance!

[cjwatson]

@tim-sueberkrueb, something odd is going on here, but I don't think it's on our side. Observe:

$ git clone https://github.com/lirios/platform-snap
$ git -C platform-snap branch
* master
$ git clone https://github.com/cjwatson/jenkins-snap
$ git -C jenkins-snap branch
* drop-use-proxy
$ git clone https://github.com/ethereum/cpp-ethereum
$ git -C cpp-ethereum branch
* develop

Why is your repository different? It appears that it has develop somehow set as the default branch in the web UI, but it isn't what you get as HEAD when you clone the repository. This is the root of the issue: fix it and things will work.

[timsueberkrueb]

@cjwatson wow, this is indeed very odd! Normally setting GitHub default branch should also change the remote HEAD, because this is a setting you can only make having direct access to the remote git repo 0.0 (afaik) Anyway, I deleted master (and changed the default branch setting again) and will recreate it in the future, I hope it will work now. Thanks a lot, I didn't notice!

[come-maiz]

parity has three branches: master, stable and beta. It would be great to be able to build the three. Even better if we could automatically land the snaps into the respective channels in the store.

[philippgille]

Another thing that I didn't see being mentioned here before:

I've got a repo set up to be build by build.snapcraft.io. Now when I push changes to the develop branch, build.snapcraft.io picks up that something changed, but always builds the master branch, even if it didn't change at all AND even if it was ALREADY BUILT before.

So even if someone doesn't care about the requested features in this ticket (select specific branch to build or build all branches), this creates unnecessary load on your build servers. You could check the build history and see that the exact same commit has already been built, see that no snaps have been pushed manually and just skip the build altogether.

[cjwatson]

Unfortunately the design of snapcraft means that we can't do that sort of optimisation without breaking other things. snapcraft.yaml can pull in parts from all sorts of places, and as soon as it pulls anything from the internet (which most non-trivial snaps do), then you have to at least run snapcraft pull before you can tell that the inputs to the build are exactly the same as last time. The central build dispatcher can't do that, so we have to dispatch a build anyway.

[bartaz]

I don't remember exactly how we trigger builds by webhook, but from what @philippgille says it seems that push to any GH branch results in triggering a build.

Let's say someone has a snap set up to be built from master and they do some changes in other branch. If they push anything to other branch GH will send a push webhook to BSI that will trigger the build from master branch (that didn't change).

Sure, external parts may have been changed. But as repo owner did a push to different branch they don't really expect snap to be built from master.

So it seems that we could probably verify if it's the master (or default branch to be specific) that triggered the push only to build when branch that snap is set up with changes.

We have 'Build manually' if anyone would need to rebuild without pushing. And there was a poller script to detect changes in parts (at least those hosted on GH).

[Safihre]

So if I understand correctly, there's still no way to have Snapcraft build from all branches and direct them to the right channels? Our usecase is simple: develop to edge and everything in master to stable. As a workaround I now use the snapcraft release sabnzbd X stable to force my edge release X to stable.

[olizilla]

go-ipfs uses release branches so experimental work can continue on the default branch while we test out an RC. Stable releases are tagged on the release branch.

So right now we have the edge channel for the ipfs snap ticking over nicely from the default branch, but there will never be a build on that channel that we can promote to candidate or release. As mentioned in https://github.com/canonical-web-and-design/snapcraft.io/issues/2861#issuecomment-298229739 we need to be able to configure branches and tags for snap/launchpad to watch for much like docker hub does.

[RetGal]

Is there a way to "up vote" this issue? Wouldn't it be a pretty low hanging fruit to add a --branch param to the git clone command - or am I getting something wrong here?

[erayerdin]

Is there a way to "up vote" this issue? Wouldn't it be a pretty low hanging fruit to add a --branch param to the git clone command - or am I getting something wrong here?

Just upvote the first one at the very top. I did so.

[merlijn-sebrechts]

This should ideally support releasing to different channels/tracks.

We'd like to have a setup where the main branch builds to edge and the candidate branch builds to candidate.

[fujiapple852]

What is the best (manual?) workaround to be able to (temporarily?) build from a branch/tag for a given channel?

[merlijn-sebrechts]

There isn't really a workaround to do this with the snapcraft build service currently. What you can do is switch to GitHub actions, like we did for signal-desktop: https://github.com/snapcrafters/signal-desktop/blob/candidate/.github/workflows/snap-store-publish-to-candidate.yml