Hi,
Thanks for the heads-up. This got me thinking: wouldn’t you agree that “limitations of using Docker for building snaps” would be an interesting paragraph to mention on a “Build on Docker” doc page too?
The explanation you wrote here: Reasoning behind the move to multipass - snapcraft - snapcraft.io is a great read, you explain it there very nicely.
Kind regards,
Brecht
Yes, I agree that would be helpful.
Not true. They don’t work on the official docker images. Mine work just fine 
Righto, sorry. Fixed it.
“terrible hacks”? I don’t agree with that sentiment. Yes it’s a hack, but suggesting that it is “terrible” will put people off using the images when they work perfectly fine.
The only scenario that they don’t work with currently is when you’re running them through the docker snap because the apparmor rules of the snap get in the way of the nested snapd instance.
Hi,
Please allow me to get into this: @lucyllewy is there somewhere I can read why you created your Docker that way and what problems you evade/fix? Again, with the mindset of expanding documentation, this is very useful.
From what I understand, the limitation of Docker is that it doesn’t contain snapd, which is needed for the build-snaps plugin. Snapd depends on systemd, which isn’t there by default, so you need a similar hack as in WSL to enable it?
Is that a correct?
Even if Docker can’t be an officially supported way of building snaps, and we have to add that big disclaimer on the docs page, offering a Docker image that actually works 99.9% of the time is still a major asset in my opinion. Not everyone can just spin up multipass VMs “just to try out a snapcraft build”. Docker and LXD are much more lightweight dependencies than multipass.
Kind regards,
Brecht
Hi @lucyllewy,
Just a small question: in your https://github.com/diddlesnaps/snapcraft-container/blob/master/entrypoint.sh , the entrypoint of your snapcraft Docker, you mount the securityfs, which isn’t enabled by default in the WSL kernel. Just double checking, is this needed? Cause my first attempt failed on that, and switching to your kernel config solved that issue.
In regards to the previous discussion, your snapcraft-container is OK, but, how would one put it… not intuitive.
For now I would propose adding the disclaimer somewhere in the documentation about Docker building, that with the current proposed steps there are limitations and that only multipass & LXE provide a 100% reliable result. Either on this docs page, or in a README file in the Docker folder of the snapcraft repo.
If that is ok for you guys, I will attempt to do just that.
Kind regards
Brecht
The securityfs is required IF your kernel has apparmor enabled. Without apparmor it is not needed.
Rather than state “don’t use this” because “it’s not 100% reliable” please file issues that highlight the problems so that I can fix them. My goal is for this method to be as reliable as Multipass or LXD or Build Service builds. If it is currently not reliable, I need to know about it so that I can fix it.
Hi @lucyllewy, Thanks for your reply.
Note that the only perspective I’m taking here is from a starting user trying out this method. Please understand me correctly, I found your Docker image to build snaps reliable. But it is not intuitive.
Compare it to LXD. In LXD you can just spin up a container, install ubuntu & snapcraft and call snapcraft --destructive-mode . It is the equivalent of using --use-lxd in the snapcraft command. Very easy.
This is not the case in Docker. You have to fabricate a very custom Docker image to do this kind of stuff. The current docs mention a simple Dockerfile, but the resulting Docker container cannot build all snaps. So a disclaimer is needed right now, because there is information there that is just wrong.
If we can manage to get a build Docker to a point where a standard user can read it and understand what is going on, that would be ideal. The alternative is that the maintenance of that (more complex) Dockerfile is done in the snapcraft repo, and then it is an official way of building that is supported by the whole community. This is also something that is possible.
Thanks, can you add this exact line as a comment in the entrypoint.sh above the mount command?
Kind regards,
Brecht
I’m not sure how running the container image is more difficult. Can you elaborate some more about how it’s more difficult for you? It should be a simple case of executing this where you’d normally execute snapcraft:
docker run --rm -it --privileged -v $PWD:/data -w /data diddledan/snapcraft:core22
This is a standard docker invocation that should be understandable to anyone with experience of running containers in Docker.
Also, it should be noted that, the primary purpose of these container images is for CI/CD pipelines, where I’m maintaining the images to allow building Snap Packages in GitHub Actions and Gitlab CI.
I’ve created a PR to fix the securityfs issue with the default WSL2 kernel:
This is now merged and the container images published. You can run docker pull diddledan/snapcraft:core22 (replacing core22 with the tag appropriate for the base that your snap package targets) to get the updated image(s).
The supported tags are:
core (deprecated, due to ESM status of Ubuntu 16.04 - you should be moving off using core as your base snap as soon as possible if your package is still using it)core18core20core22Hi @lucyllewy,
Thanks for your work.
To be clear I mean the actual Dockerfile, your source, is not for newbies, not the usage of that Docker.
To craft that Dockerfile, it took a lot of insight, and it is not intuitive. This is okay, hiding complexity is perfectly fine, and for someone just using it, it does not really matter. As you point out, the docker run is pretty standard.
It just means that someone (you) will have to have that knowledge to maintain it and keep in touch with the snapcraft team to make sure that new snapcraft features/dependencies do not break the Docker build. Which is why I proposed that the actual snapcraft repo maintainers adopt it. But there could be other ways.
Kind regards,
Brecht
Hi, i think the Dockerfile is obsolete ant not working anymore with the current snapcraft stable snap (it requires snap20 instead of 18),
Thanks for letting us know. I think we may have to deprecate this page (at least from the official navigation) as I don’t think there’s currently an official Docker method. I know @lucyllewy has put a lot of effort into maintaining images, but I’ve not run through the process recently.
You’re right that there is currently no official docker support for building snaps. I’ve not rechecked my own images for a couple of months but they were functional and up to date fairly recently. I haven’t had any reports of them failing since I last fixed them, so I think they’re good to go.
You can find them at hub.docker.com/r/diddledani/snapcraft
Thanks Dani! In that case, it may be worth updating this page (it badly needs it) and to mention your images specifically (with a shout-out/thanks, of course), but as an unofficial guide - I know this page is still used by lots of people, and building with Docker is still a great option. I’ll create a task to look into it.