Subtle differences of the build environment between multipass and build.snapcraft.io

In local build the curl utility is available but after I pushed to GitHub the build.snapcraft.io build fails complaining that it is missing…

UPDATE: Also wget as well, don’t ask me why I use both at the same time. :wink:

Is there any way to fully imitate the same environment of build.snapcraft.io?

Doing this at the moment involves a lot of setup and is unlikely to be worth it most of the time; we have some work in progress to make snapcraft and Launchpad snap builds use the same base images, which will address this.

In the meantime, of course, you can add curl to your build-packages.

2 Likes

I have a issue where I appear not to be able to override the PATH during the build on build.snapcraft.io.

The issue is that the configure script of the libguestfs part is taking the full path of binaries from its path at build-time and they are then compiled into the end result.

I have a snapcraft.yaml [0] which successfully overrides this when I build in multipass or with --use-lxd locally.

What can I do differently to have this succeed on build.snapcraft.io? The built result is currently failing :frowning: [1]

0: https://github.com/openstack-charmers/octavia-diskimage-retrofit/blob/450da8960dcf75a6d68c651cac0f9d0eac14112d/snap/snapcraft.yaml#L193 1: https://github.com/openstack-charmers/octavia-diskimage-retrofit/issues/7

Hey @fnordahl since you’re building from source already, have you considered a pre-build patch in your snapcraft.yaml, or even better, fixing upstream to not bake PATH in?

Yes, i should probably just do that. I’m carrying patches (with intent to upstream) already, so I can just add one more instead of this PATH havekery.

I was just blindsided by the surprise of differences in the local vs. remote build-environments.

Thank you for getting me on the right path @Saviq