Update official docker image

[VladRassokhin]

What needs to get done

Release a new version of docker image https://hub.docker.com/r/snapcore/snapcraft/tags

Why it needs to get done

The current :stable was published 3 years ago, it bundles "snapcraft, version 4.4.4" which doesn't support the --build-for option for snapcraft snap command.
:latest has "snapcraft, version 4.6.2.post12+gitae6e8b70", which also lacks --build-for.

Without --build-for, I cannot proceed to generate multi-arch (amd64/arm64) snaps, since I'm using one snapcraft.yaml for two per-arch snaps.

While I can build a custom docker image, I'd prefer to use an official one.
For custom docker image I've used #4290 as the base, with some additional changes in my fork, dockerfile branch: main...VladRassokhin:snapcraft:dockerfile (I can send those commits as PR if you need)

Related issue in IntelliJ IDEA tracker: https://youtrack.jetbrains.com/issue/IDEA-253637/snapcraft.io-Add-ARM64-snap-package-for-Idea-based-IDEs.

[ARostovsky]

+1

[mikemarquez]

+1 Can this please be addressed? The fact that the image is using Xenial and several major versions behind is concerning. I would even be happy with an update on the status of this.

[nuxy]

+1

[tigarmo]

Hi folks. A belated update here is that our new snapcraft-rocks initiative should satisfy the need for up-to-date Docker images. We already have rocks for Snapcraft 7 and 8 and in the coming weeks will be publishing the images somewhere (I'll update here when it's done).

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2617.

This message was autogenerated

[tigarmo]

(I'll update here when it's done).

Following up on this! Here's the announcement: https://forum.snapcraft.io/t/snapcraft-rocks-oci-images/39581

[mr-cal]

Closing this issue now that snapcraft-rocks is publishing OCI images here.

[VladRassokhin]

There's a compatibility problem between the old image and the new one: one has to remove first snapcraft argument, since new image has wrapper as ENTRYPOINT which does exec /bin/snapcraft "$@"

[VladRassokhin]

More incompatibilities:
Previously it was possible to place snapcraft.yaml into arbitrary directory (e.g. mount it as ...:/build/snapcraft.yaml:ro) and use --workdir=/build. Now it doesn't work and gives gas-lighting error:

2024-04-29T09:59:11.631Z [snapcraft] Could not find snap/snapcraft.yaml. Are you sure you are in the right directory?
2024-04-29T09:59:11.631Z [snapcraft] Recommended resolution: To start a new project, use `snapcraft init`

Whole docker args if you're interested (paths removed and lines added for readability):

docker
run
--rm
--volume=/work/out/idea-ce/dist.snap.amd64/snapcraft.yaml:/build/snapcraft.yaml:ro
--volume=/work/out/idea-ce/dist.snap.amd64/intellij-idea-community.desktop:/build/snap/gui/intellij-idea-community.desktop:ro
--volume=/work/out/idea-ce/dist.snap.amd64/intellij-idea-community.png:/build/prime/meta/gui/icon.png:ro
--volume=/work/out/idea-ce/dist.snap.amd64/result:/build/result
--volume=/work/out/idea-ce/dist.all:/build/dist.all:ro
--volume=/work/out/idea-ce/temp/linux.dist.snap.product-info.json.amd64:/build/dist.product-json:ro
--volume=/work/out/idea-ce/dist.unix.x64:/build/dist.unix:ro
--volume=/work/community/build/download/jbr_jcef-21.0.3b442.1-linux-x64:/build/jre:ro
--workdir=/build
ghcr.io/canonical/snapcraft:8_core22@sha256:ea7434407f1ccede1feee183b982b23e1914a36267701063c392fb299a04dd89
snap
--build-for=amd64
-o
result/intellij-idea-community_2024.2-EAP_amd64.snap

Turns out one must inspect sources (https://github.com/canonical/snapcraft-rocks/blob/core22-8/rockcraft.yaml) and use /project. Is it documented anywhere?

UPD: Filled as canonical/snapcraft-rocks#40

[VladRassokhin]

@mr-cal @tigarmo Overall, new snapcraft-rocks image doesn't seem to provide anything useful compared to Dockerfile from #4290+fixes.
Even worse:

1. one cannot build it without using Ubuntu as host and several other Ubuntu-specific tools and packages.
2. It still lacks an arm64 version.
3. --workdir is not supported, and the first argument should be dropped, meaning no 'drop-in' replacement possible.