Let’s take an example. How should I handle this question in CI:
Support for 'multipass' needs to be set up. Would you like to do that it now? [y/N]:
There have been so many annoying issues that I have to still manually build my snaps.
You can set the snap to build on the host, or build in an lxd container, depending on what is appropriate to your environment.
The invocation is snapcraft build --provider host (or --provider lxd)
More info in snapcraft build --help
Note that if you’re building the snap in multiple places in your CI workflow, you may be better served by building the snap once, then referencing the resultant .snap file in your testing scripts. You might also build a CI flow that triggers off of new edge builds of the snap in the store.
2 Likes
It wants me to add --destructive-mode, is that how it’s supposed to be?
It seems that build now only builds my part but doesn’t create any snaps!
If I run snapcraft --destructive-mode I get:
Unable to determine library dependencies for ‘/home/jussili/Git/Heimer/prime/usr/lib/x86_64-linux-gnu/fcitx/fcitx-autoeng.so’
Unable to determine library dependencies for ‘/home/jussili/Git/Heimer/prime/lib/x86_64-linux-gnu/libexpat.so.1.6.11’
…lots of these…
The linker version ‘2.27’ used by the base ‘core18’ is incompatible with files in this snap:
/home/jussili/Git/Heimer/prime/usr/lib/x86_64-linux-gnu/dri/i915_dri.so (2.29)
/home/jussili/Git/Heimer/prime/usr/lib/x86_64-linux-gnu/dri/i965_dri.so (2.29)
…lots of these…
Is it so that I must run this on Ubuntu 18.04 ?
base: core -> needs to build on 16.04
base: core18 -> needs 18.04
base: core20 -> 20.04
if you use multipass (the default) snapcraft will make sure to pull the right VM image into the virtual machine and do the build inside there …
if you want to use --destructive-mode you should really run snapcraft inside an lxd container for the respective release
there is also https://snapcraft.io/fabrica in case you just want automated per-commit builds, that does the --destructive-mode thing inside an lxd container automatically for you …
Not necessarily.
Destructive mode was designed specifically for CI use cases. Ideally the machine would be ephemeral, which yes, lxd may be an option, but it’s not necessary. Destructive mode could be used in a dedicated vm or any other machine running the appropriate version of Ubuntu as outlined by Ogra above.
1 Like
I didn’t want to use --destructive-node. Snapcraft required me to add it 
As with all software, you have choices. If your CI system is able to install and run lxd then you could indeed snapcraft --use-lxd to build in a clean container, but --destructive-mode is an alternative option.
1 Like
–use-lxd typically means you run snapcraft outside of the container itself, snapcraft then spawns the container and does the build inside it, caring for everything.
–destructive-mode is OTOH used if you use snapcraft inside the container … i.e. you would enter the VM or container or whatever other ephemeral system you have first, make sure snapcraft is installed inside that and then run snapcraft --destructive-mode in there …
1 Like
$ snapcraft --use-lxd
Support for 'LXD' needs to be set up. Would you like to do that it now? [y/N]:
How can I run that without this interaction? This is now the same problem as with multipass. Jenkins cannot understand and answer these questions. At least with multipass it did could ask this similar question again.
Is this setup per working directory, per project or is it global or what? At least it must find the snapcraft.yaml in order to do anything.
EDIT: I let it set up things, and now:
$ snapcraft --use-lxd
Launching a container.
An error occurred with the instance when trying to launch with 'LXD': No storage pool found. Please create a new storage pool.
Ensure that 'LXD' is setup correctly and try again.
I can see that one creates new storage pools with lxc storage create but I have no idea what I exactly should do in this context.
lxd requires initial setup:
sudo lxd init # do a "chicken install" (hit enter for all the questions)
now try snapcraft --use-lxd again …
1 Like
Alternatives are lxd init auto or to use the preseed option.
1 Like
There is nothing wrong with using --destructive-mode on throw away environments. The intention of the flag is to state that Snapcraft will own the system where it is run, and by that I mean, a snapcraft.yaml could state that it needs certain packages installed or modifications made for a build to take place.
If your CI can spawn its own containers where you do your builds in, you’re better off installing snapcraft and using snapcraft --destructive-mode inside of that container, and since each new build is a new container you spin up, it is safe to do so.
You can also let snapcraft (on your host CI itself, not in a new container!) spin up your container with snapcraft (multipass) or snapcraft --use-lxd (lxd).
1 Like
fyi as per Samuel Meuli’s request I’ve taken over maintenance of https://github.com/samuelmeuli/action-snapcraft which makes life easier to build & deploy with github actions…
1 Like