there is no corresponding snapcraft process inside the VM. It seems as if the snapcraft command on the host side missed the message that everything is done inside the VM.
Is this problem reproducible after snapcraft clean? I successfully built the rabbitmq-server-snap snap from the github main branch, but maybe you’re working on a different branch or with local modifications. Is there any change I should do to reproduce the problem locally?
My attempt:
$ multipass --version
multipass 1.10.1
multipassd 1.10.1
$ snapcraft
Launching a VM.
'SNAPCRAFT_BUILD_ENVIRONMENT_CPU' was set to '16' in the environment. Changing the default allocation upon user request
Launched: snapcraft-rabbitmq-server-snap
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
...
Priming erlang
+ snapcraftctl prime
Priming elixir
+ snapcraftctl prime
Priming rabbitmq-server
+ snapcraftctl prime
Priming rabbitmq-support
+ snapcraftctl prime
Snapping |
Snapped rabbitmq-server-snap_3.8.35_amd64.snap
$
If this keeps happening and you’re running on a Linux host you can try snapcraft --use-lxd to use LXD instead of multipass.
I am building from main, i.e. b9a9a8fc2a36248e71c0e0b6f4ffa92e85d99ab5. Cleaning the VM does not make a difference unfortunately. And I see the same behavior with multipass or lxd.
It’s odd that the fail is consistent since it works on my machine. Maybe you could try to just prime the snap, and then pack by hand to see if that works? The actual packing is performed using the snap tool, so after you run snapcraft prime you can enter the VM or container and run snap pack <prime directory> to generate the snap file.
Potentially yes. Very annoyingly I can’t reproduce this issue on my laptop anymore. It is still present in GitHub actions and snapcraft builders though.