Multipass, Nested Virtualization, Gitlab CI and Snapcraft

We have been having a lot of issues building snaps in Gitlab CI. I am not suggesting any specific component is responsible but just describing what we have and some of what is happening.

We are using shell runners with Ubuntu Server 20.04 VMs with snapcraft and Multipass installed. So basically Gitlab CI runs shell commands on the VM to build the snaps.

The most recent error popping up to prompt this thread was:

mount failed: failed to obtain exit status for remote process 'which snap': timeout
An error occurred with the instance when trying to mount with 'multipass': returned exit code 2.
Ensure that 'multipass' is setup correctly and try again.

But it has been an ongoing battle to make this work reliably and well. Sometimes runners are left running or in a “bad” state.

Does anyone have any general suggestions? Multipass + CI suggestions? Is nested virtualization causing issues here (even though it shouldn’t be)?

I use LXD locally and it’s great. I would actually like to transition to that anyway. Is it a fully “suppported” method for building production snaps?

Thanks.

In a CI environment where you know the shell runner is 20.04 and you’re using core20 you could use snapcraft --destructive-mode - which is designed specifically for this use case. No nested VM, no LXD container, it builds on the “bare metal” (or VM). Use Ubuntu 18.04 for core18 snaps, and you’re set.

From the documentation " Destructive mode. Designed to be used in temporary/short-lived environments, such as on a CI system, because the build could contaminate the host build environment."

For Github actions, I would recommend using the official github action to build a snap! https://github.com/snapcore/action-build

It will use LXD to build your snaps :smiley:

1 Like