fix(snap): update stale snap docs and tests

[olivercalder]

Summary

Previously, the openshell snap required the docker snap. Now, it works with any Docker daemon running on the system. Furthermore, the snap-declaration assertion on the openshell snap when installed from the Snap Store causes the openshell snap to always connect to the system :docker slot, rather than a slot provided by the docker snap.

Related Issue

This PR splits some of the changes from #2250 into a dedicated PR which just touches documentation and (minimally) tests, without the changes to install.sh.

Changes

• Always connect to the system :docker slot in tests of the CI-built openshell snap which need to manually connect interfaces
• Update documentation, including the description field in snapcraft.yaml, to reflect the current reality of the openshell snap interface autoconnections
• Rename the ubuntu release-canary job to ubuntu-deb, and make the ubuntu-snap job use the same docker setup as ubuntu-deb

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[elezar]

The migration to the system :docker slot is consistent across the canary, installation docs, reproduction scripts, contributor skill, and regression checks. The direction looks sound, but I think one issue needs to be addressed before merging.

Blocking: the snap does not declare the snapd version required by :docker.

System-wide Docker access through this interface was introduced in snapd 2.77, according to the snapd NEWS. As of September 23, the corrected 2.77.1 release is still in candidate, with stable scheduled for September 25; the original 2.77 rollout was held after a regression was found (snapd roadmap).

Before this PR, users could connect to the Docker snap's exported slot on older snapd versions. After this PR, every documented and tested path requires the new system slot, but snap/snapcraft.yaml does not declare an assumes requirement.

Please either:

• add an appropriate minimum such as assumes: [snapd2.77.1] and document that requirement, or
• retain a compatible fallback for older snapd versions.

Snapcraft's assumes field would produce a clear installation-time failure instead of allowing the gateway to install without being able to access Docker.

There is also a smaller test-documentation mismatch: nix/test-guest/scripts/snap-gateway-repro.sh defaults to an immediate readiness check and says that this mirrors the canary, while .github/workflows/release-canary.yml waits up to 30 seconds. This mismatch predates the PR, but the updated README renews the claim that the reproduction follows the canary exactly. Please set the reproduction's default timeout to 30 seconds or describe it as intentionally stricter.

Validation performed: tasks/scripts/test-packaging-assets.sh and git diff --check both pass. The test-release-canary contributor skill is updated consistently; I did not find additional agent-infrastructure drift.

[olivercalder]

Thanks for the review!

System-wide Docker access through this interface was introduced in snapd 2.77, according to the snapd NEWS. As of September 23, the corrected 2.77.1 release is still in candidate, with stable scheduled for September 25; the original 2.77 rollout was held after a regression was found (snapd roadmap).

This isn't quite right... what 2.77 added was changing the base declaration built into snapd to allow people to manually connect to the system docker slot. But since the openshell snap has a snap-declaration assertion from the store, it overrides that base declaration and allows it to be auto-connected.

But the system slot itself was added in snapd 2.76. So I'll add an assumes: [snapd2.76] to enforce this correctly.

I've pushed this, plus the requested fixes for the snap canary reproducer.

Thanks!

[johntmyers]

gator-agent

PR Review Status

Thanks @olivercalder. I checked the snapd-version and readiness-window updates you pushed in response to @elezar. The 30-second reproducer change resolves the timeout mismatch, but the compatibility requirement remains incomplete: snapd 2.76 provides the system Docker slot, while the supported local-install, canary, and reproduction paths explicitly connect to that slot, an operation enabled in 2.77.

Action required: raise the declared minimum to snapd 2.77 and lock it into the packaging-assets checks, or retain a supported 2.76 path that does not require the explicit connection.

Blocking findings:

• GATOR-f146ec90-01: the declared minimum does not support every documented and tested system-slot connection path.

Carried findings:

• None

Non-blocking suggestions:

• None

Gator metadata

• Validation: This is concentrated Snap packaging, documentation, and release-canary maintenance with a clear supported-user path.
• Docs: Fern installation docs are updated, subject to the version-compatibility correction above.
• Checks: Current-head required workflows have not started because contributor validation is still pending.
• E2E: Required for the changed Snap runtime packaging path; dispatch is deferred until review feedback is resolved.
• Head SHA: f146ec909cfc46a25135eb12dfac9b7cbc169c3f
• Base SHA: 123d95e2edda002004ab17a46e3477d182059fa7
• Merge base SHA: 11f1fe5806797d8c211c29b411017197a3d810e8
• Patch ID: 290f88b442e07b3e14f4e61cb4a60ffecd8e504a
• Gator payload: 9
• Review mode: initial
• Previous reviewed SHA: none
• Review budget exhausted: no
• Maintainer decision required: no
• Next state: gator:in-review

[johntmyers]

gator-agent

PR Review Status

Thanks @olivercalder. I checked the new snapd2.77 declaration you pushed after the prior review. That fixes the immediate compatibility mismatch, but the same finding remains partially open because the packaging-assets check still does not lock in the required minimum; lowering it again would pass that check while breaking the supported local-install, canary, and reproduction paths.

Action required: add a packaging-assets assertion that snapcraft.yaml contains the chosen snapd2.77 minimum.

Blocking findings:

• No new blocking findings.

Carried findings:

• GATOR-f146ec90-01: the runtime minimum is corrected, but the requested regression assertion is still missing.

Gator metadata

• Validation: This is concentrated Snap packaging, documentation, and release-canary maintenance with a clear supported-user path.
• Docs: Fern installation docs are updated; no further docs change is needed for this follow-up.
• Checks: Current-head required checks are not all green, and test dispatch remains deferred until review feedback is resolved.
• E2E: Required for the changed Snap runtime packaging path; dispatch is deferred until the carried finding is resolved.
• Head SHA: 2ee8a43107fad34e903cd21ab04d81e0d6230519
• Base SHA: 123d95e2edda002004ab17a46e3477d182059fa7
• Merge base SHA: 11f1fe5806797d8c211c29b411017197a3d810e8
• Patch ID: dd000920b2347a3617f7d0514a6834c10e38494b
• Gator payload: 9
• Review mode: follow_up
• Previous reviewed SHA: f146ec909cfc46a25135eb12dfac9b7cbc169c3f
• Review budget exhausted: no
• Maintainer decision required: no
• Next state: gator:in-review

[olivercalder]

I've added the assertion test, thanks!

[johntmyers]

/ok to test 60d8340

[github-actions]

Label test:e2e applied for 60d8340. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway, sandbox, and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[johntmyers]

gator-agent

PR Review Status

Thanks @olivercalder. I checked the packaging assertion you added after the prior review. The exact snapd2.77 minimum is now enforced by the packaging-assets check, so GATOR-f146ec90-01 is resolved. The independent follow-up review found no new blocking issues in the author-only delta.

Action required: the current Branch E2E Checks attempt must finish, then Gator will rerun all jobs as requested by E2E Label Help so the test:e2e label takes effect.

Blocking findings:

• No new blocking findings.

Carried findings:

• GATOR-f146ec90-01: resolved by the snapd2.77 packaging assertion.

Gator metadata

• Validation: This is concentrated Snap packaging, documentation, and release-canary maintenance with a clear supported-user path.
• Docs: Fern installation docs are updated; no further docs change is needed.
• Checks: Current-head branch workflows are running, but the label-aware E2E rerun is not yet queued.
• E2E: test:e2e is applied; E2E Label Help requires rerunning current-head run 35928622109, which GitHub will not permit while its first attempt is in progress.
• Head SHA: 60d83406b682369500fd071fc28109c67e06db4a
• Base SHA: 123d95e2edda002004ab17a46e3477d182059fa7
• Merge base SHA: 11f1fe5806797d8c211c29b411017197a3d810e8
• Patch ID: 31b62c8945a644cfa8ead2bd7757556181ad8d16
• Gator payload: 9
• Review mode: follow_up
• Previous reviewed SHA: 2ee8a43107fad34e903cd21ab04d81e0d6230519
• Review budget exhausted: no
• Maintainer decision required: no
• Next state: gator:blocked
• Blocked reason: test_dispatch_required

[olivercalder]

Merged as part of #3656

[olivercalder]

Merged as part of #3656

[johntmyers]

gator-agent

Monitoring Complete

Monitoring is complete because this PR has been closed without merge. The author reported that the work was merged as part of #3656; the latest checks on this PR's final head were green.

I removed the active gator:* label because there is nothing left for gator to monitor on this PR.

Gator metadata

• Head SHA: 60d83406b682369500fd071fc28109c67e06db4a
• Gator payload: 9
• Final state: closed without merge