Snapcraft 7.2 depends on snapd socket at runtime


Running snapcraft 7.2 seems to require access to the snapd socket in the snap context, as in http://localhost/v2/snapctl via /run/snapd-snap.socket.

I’m assuming at this point it’s due to this being introduced via snap options ?

This seems to like an obvious way to provide a config option for a snap of course, but it’s potentially quite a big problem for anyone that has to use docker for snap builds in the CI system that they have to use.

I completely understand the using snapcraft in this way is not really supported. But, I also know of quite a few places where it’s used. The mains reason seems to be because docker for CI is so ubiquitous, and CI choice is not completely open for many companies etc.

Current, when using the latest 7.2 version in docker, this is the error:

Call to snapctl failed with error 1: error: cannot communicate with server: Post http://localhost/v2/snapctl: dial unix /run/snapd-snap.socket: connect: no such file or directory

Is there any obvious way of handling this in docker that I’m not seeing ?

If it is the default provider snap config that introduced this, could a CLI flag be introduced in parallel to specify the provider and disabled the snap config query? Or, even further, as we know builds in docker are likely not to use either provider, and snapcraft seems to know it’s running in docker, perhaps snapcraft could just disable provider config lookup in that situation ?

Example of already detecting docker:

The following snaps are required but not installed as snapcraft is running inside docker or podman container: core18.
Please ensure the environment is properly setup before continuing.
Ignore this message if the appropriate measures have already been taken

Cheers, Just

Hi @jocado,

I agree that snapcraft should work around the snap get snapcraft call when running inside docker (or more generically, when snapd does not respond).

Can you give me a few details on how you install snapcraft inside Docker? I’m having trouble reproducing the issue.

Nevermind, I was able to reproduce the issue!

Closing the loop here (more details in Call for testing: Snapcraft 7.2.0).

The fix has been released and snapcraft should now work inside docker again.