Snap build service picking default branch instead of pushed branch

snapcraft
1

I have my GitHub repo hooked up to the snapcraft build service such that when I push any new commits, it triggers a new build. This is just using the default way of connecting repos to the build service via the web hook. However, it seems as though when I push to a branch, the triggered build uses the default branch instead of the pushed one. Is this a bug in how the web hook is defined (it was established by clicking on the “Set up webhook” link on the Settings tab of the snapcraft.io page for the snap), or is there some extra setting I need to tweak somewhere to get this to work as expected?

Build log for one example can be found here: https://snapcraft.io/cmake/builds/1164952

2

Hey folks, it’s a year later and this fairly fundamental problem still exists. It is much more problematic now though because since the core20 base doesn’t support the i386 architecture, I have to move i386 support off to a separate branch. The web hook still always picks up the default branch instead of the actual branch that was pushed to, making the automated builds unable to build for i386 in my case.

@Lukewh @ogra @sergiusens Who do I need to prod to give some visibility to this issue? I’m trying to support the snap ecosystem by maintaining the CMake snap for all architectures, but things like this just make it unnecessarily hard.

3

Not a solution, merely a suggestion: Use GitHub actions for proper CI/CD. It’s easy to set up (even for cross-compilation) and receives far more development/features/maintenance/support than Canonical’s GitHub integration could ever hope to achieve with the comparatively smaller team.

See e.g. https://github.com/solvespace/solvespace/blob/master/.github/workflows/cd.yml for compiling amd64 and arm64 snaps on GHA.

4

I’d be happy to use GitHub Actions, but I need packages for more architectures than I think it supports: amd64, arm64, armhf, i386, ppc64el and s390x. If there’s an alternative to the snapcraft remote-build service that provides all those, I’m all ears.

5

Yes, that’s a problem. There’s https://github.com/diddlesnaps/snapcraft-multiarch-action, which can do those architectures via QEMU user mode emulation. However, it seems it can’t do armhf and s390x for core20 atm according to its README. But maybe that has changed; there seem to be core20 docker images for amd64, armhf, arm64, ppc64el, and s390x.

6

Just to join the dots a bit, this is https://github.com/canonical-web-and-design/snapcraft.io/issues/2774. (It’s perfectly possible to set it up manually using a snap recipe in Launchpad, but getting it to work using the more shrinkwrapped workflow on snapcraft.io needs some design work on the website and some small extensions to https://github.com/canonical-web-and-design/canonicalwebteam.launchpad.)

7

@cjwatson Very nice, thank you for the links. Is it possible to pass things like --enable-experimental-extensions to snapcraft via those snap recipes?

8

Not at the moment, though I think that would be a reasonable thing to add. Could you file a bug for that, please?

1 Like
9

Here you go: https://bugs.launchpad.net/launchpad/+bug/1949989

I believe the remote build feature uses the same infrastructure on launchpad, so this could also be a building block in enabling the same for snapcraft remote-build. The bug for the remote-build part is here: https://bugs.launchpad.net/snapcraft/+bug/1950867