fix(ci): set up snapd in the release job instead of assuming it

[vroldanbet]

What

Makes the "Install snapcraft" step in .github/workflows/release.yaml set up snapd rather than assume it is already there, and fail with a clear message if it cannot.

One file. Independent of #3356 — different file, no dependency, so neither has to wait for the other.

Why

The step installs snapcraft with sudo snap install, which fails on runner images where snapd is not running:

error: cannot communicate with server: Post "http://localhost/v2/snaps/snapcraft":
       dial unix /run/snapd.socket: connect: no such file or directory

The identical step in nightly.yaml fails this way on pushes to main today, and #3321 hit it in the Trivy job. In both of those cases snapcraft was never needed and the step was simply deleted. This job is different: goreleaser builds the snap declared in .goreleaser.yml here, and this is the job that publishes it to the Snap Store. Left alone, it will fail the same way on the next tag.

The snap is a live channel, not a leftover: it is at 1.56.2, matching the latest tag, and the docs list sudo snap install spicedb as an install method for Ubuntu and Debian. That is why this is fixed rather than dropped.

How

The step probes for /run/snapd.socket, installs and starts snapd when it is missing, waits for seeding to finish, then installs snapcraft. apt and systemctl are allowed to fail quietly because the socket check after them is what decides, and it gives a clearer message than either would.

If snapd still cannot be had, the step prints a ::error:: and exits 1. It deliberately does not skip the snap build instead — a release that quietly stops publishing the snap is harder to notice than one that stops loudly.

The wait for seeding is capped at five minutes. #3321 recorded snapd on these images hanging rather than failing outright ("timeout waiting for snap system profiles to get updated"), and a release job that hangs until the six-hour limit is worse than one that stops with a message.

What is verified, and what is not

Please read this part — the split between the two is the main thing a reviewer needs from me.

Verified by running:

• Both failure paths, executed in a container with no snapd. The missing-snapd path and the five-minute seeding-hang path each print their intended ::error:: and exit 1.
• bash -n on the step's script.
• yamllint and prettier, matching what mage lint:yaml runs.

Not verified — never observed:

The success path — apt installs snapd, systemd starts it, seeding completes, snapcraft installs — is reasoned from the step's structure only. I have not seen it run. It will execute for real for the first time on the next tag, during an actual release.

I could not find a genuinely safe way to rehearse it. This workflow does have workflow_dispatch, but dispatching it cuts a real release, so it is not a free trial run. Running the same script on a stock Ubuntu container is not a rehearsal either: the failure mode being fixed is a property of the runner image, and a container that already lacks systemd exercises the error branch rather than the success branch. If a reviewer knows a safe way to exercise this against a real runner, I would rather do that than merge on reasoning.

The mitigating factor is the shape of the failure, not the confidence in the fix: if the new step is wrong, the release job stops with a message at the same point it stops today. That is the behaviour it is designed for, and it does not publish a partial or snap-less release silently.

References

• fix(ci): stop the nightly release installing a snapcraft it never uses #3356 — the matching nightly fix, which removes the step there because that job never needed snapcraft
• fix(ci): repair jobs that were failing or never running #3321 — the same runner drift in the WASM and Trivy jobs, and the source of the snapd-hang precedent behind the five-minute bound