ci: remove the Podman checkpoint/restore job

[bilby91]

Third step in retiring the non-Docker backends, after #121 (Apple Containers CI) and #122 (README). This one is CI-only.

What goes

• test-integration-podman in .github/workflows/ci.yml — the job that built the gated tests statically on the runner, then docker-ran them inside a quay.io/podman/stable privileged container (podman 5.x + crun + criu, --cgroupns=host) so CRIU could drive the runner's kernel.
• .github/scripts/podman-cr.sh — the script that job invoked. It was the only file in .github/scripts/, and the job was its only consumer, so the directory goes with it.

83 deletions, no Go changes.

What stays

runtime/podman and the tests the job compiled — ./runtime/podman and TestPodman* under test/integration — are untouched and still build under go test ./.... They are simply no longer exercised against a live Podman socket with CRIU. Coverage loss is limited to that gated path: the job only ever ran for real on a runner whose kernel permitted a nested checkpoint, and skipped green with the reason otherwise.

The cross-node test (TestPodmanXNode_*) already skipped in CI — it needs two hosts and no DCCKPT_XNODE_DIR was set — so nothing changes for it.

Remaining jobs

lint, test-linux, test-integration-linux. Worth a check on your side: if test-integration-podman is listed as a required status check on main, it needs dropping there too or PRs will block waiting on a job that no longer reports. I can't read the branch protection settings from here (403).

Not in this PR

The backend code itself — runtime/podman/ (875 LOC), runtime/applecontainer/ (3,660), applecontainer-bridge/ (2,228), the integration tests, the --runtime applecontainer dispatch in cmd/devcontainer/root.go, the Swift bridge targets in the Makefile, and the design docs. One open question to settle before that PR: runtime/podman is the only implementation of runtime.CheckpointRuntime — runtime/docker has no Checkpoint/Restore — so removing it orphans the whole checkpoint/restore feature (the interface, checkpoint.go / checkpoint_project.go, Capabilities().Checkpoint).

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{On-demand reviews are free for the next 23 days. After that, they cost $0.25 per reviewed file.}

Or wait 4 minutes for your next included review.

View limit details

Limit details: You’ve used the included review currently available. Your 62 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 25a5c655-c03b-4060-9ad2-e39acd84515e

📥 Commits

Reviewing files that changed from the base of the PR and between 29ce1d9 and c9958ad.

📒 Files selected for processing (2)

• .github/scripts/podman-cr.sh
• .github/workflows/ci.yml

---

_{Comment @coderabbitai help to get the list of available commands.}

[dap-code-review-by-crunchloop]

Code Review — head c9958ad

Reviewed the one-commit, two-file PR range at head c9958ad (83 deletions): the Podman workflow job and its helper script. Read the applicable engineering directives at base 29ce1d9, CONTRIBUTING.md, the Podman/checkpoint design records, the remaining CI workflow, and all Podman integration-test consumers. The deleted job was the only path that supplied a live Podman+CRIU environment; the remaining Docker integration shards skip Podman tests because PODMAN_SOCKET is unset. Recorded the R8 finding for removing that required real-backend gate. No other concrete defect was established in the deletion itself. Coverage gaps: PRD.md referenced by the directives is absent at the directives base; legacy branch-protection status checks could not be queried (GitHub returned 403), though the accessible Trunk ruleset declares no required checks. I did not execute tests or the system under review. Replies typed into inline comment threads will not reach this review; answer in the pull-request conversation instead.

Commented inline

• [MEDIUM] [R8] Removing the only live Podman gate leaves checkpoint/restore regressions invisible to CI — .github/workflows/ci.yml:117

Verdict

ADVISORY — findings worth reading, none of them blocking.

[dap-code-review-by-crunchloop]

[MEDIUM] [R8] Removing the only live Podman gate leaves checkpoint/restore regressions invisible to CI

• Witness: Command: git show 29ce1d948b03c493b59b9811bb1d34059b0989c7:design/podman-backend.md | nl -ba | grep -i -A6 -B4 -E 'integration|test' | head -100\nRaw output: 281\t### Phase 2 — the Podman backend ... 288\t- Integration tests behind a real-podman gate (mirror the existing / 289\t real-docker compose integration-test gate). and 318\t- **Integration (real podman gate):** bring a container up via the Podman / 319\t backend, checkpoint→remove→restore, assert memory + networking resume / 320\t — the bench test, codified.\n\nThe deleted job was the only CI path that compiled and ran the live tests (go test -c ./runtime/podman, then /w/podman.test -test.run TestIntegration and /w/int.test -test.run '^TestPodman'). The remaining workflow only runs go test -tags=integration ./test/integration/... against Docker and does not set PODMAN_SOCKET; the Podman tests explicitly call t.Skip when that variable is absent (runtime/podman/integration_test.go:27-30, test/integration/podman_checkpoint_restore_test.go:36-38). Thus a broken libpod checkpoint/restore or build endpoint can pass every remaining check, directly contradicting the backend design's required real-Podman gate.
• Consumer: runtime/podman/integration_test.go:27-30 and test/integration/podman_checkpoint_restore_test.go:36-38 read PODMAN_SOCKET and skip without it; .github/workflows/ci.yml:74-86 runs the remaining integration suite without providing that socket, so no remaining CI consumer exercises the Podman backend against a daemon.
• Fix: Keep a real-Podman integration gate, or replace it with an equivalent scheduled/hosted or self-hosted job that provisions Podman + CRIU, sets PODMAN_SOCKET, and runs the runtime-level and engine/project checkpoint tests. If intentionally abandoning this guarantee, update design/podman-backend.md and the backend's support/validation contract rather than silently deleting the gate.

[dap-code-review-by-crunchloop]

Dismissed — the reviewer retracted this finding.

Reason: After re-reading the repository standard and its cited evidence, I no longer stand behind this as a defect in this PR. The factual coverage loss remains real, but R8 explicitly allows a backend-specific path to be untested when the change makes an explicit statement of which backend is untested; the PR description does exactly that. The referenced podman-backend design is marked “Draft for review,” and design/README.md:10-15 says such records are not kept in sync and that code is authoritative, so my original “required gate/design contradiction” framing was not valid. The preceding #121/#122 removal sequence also establishes that this retirement work intentionally removes backend coverage without rewriting design records. The deleted job was best-effort (it intentionally exited green when CRIU was unavailable), and no evidence shows a current supported Podman consumer that this CI deletion breaks.

The review comment above records what was claimed at the time, and is left unedited.

[bilby91]

Thanks — taking the R8 finding on its merits.

The factual core is correct and I'm not disputing it: after this PR no CI path exercises the Podman backend against a live daemon. runtime/podman/integration_test.go:27-30 and test/integration/podman_checkpoint_restore_test.go:36-38 both t.Skip without PODMAN_SOCKET, and the remaining integration shards (ci.yml:74-86) never set it. A broken libpod checkpoint or build endpoint would pass every remaining check.

Where I disagree is the framing — that this abandons a guarantee, and that the design record must be amended in the same commit.

1. The design record is not a validation contract. design/README.md:11-16 states the convention directly:

The docs reflect the state of the world at the time they were written. They are not kept perfectly in sync with the code; when a record disagrees with main, the code is authoritative. Sections that explicitly call out alternatives, probe results, or "future work" are kept because the reasoning is still useful even after the work shipped.

design/podman-backend.md is **Status:** Draft for review, dated 2026-06-19 — a phased implementation plan, not a support commitment. Its §288-289 line ("Integration tests behind a real-podman gate") is a plan item from that phase. Under the repo's own stated rule, main disagreeing with it makes the code authoritative, not the record binding.

2. There is direct precedent from the preceding step of this same removal. #122 — the immediately prior merged PR, co-authored by the repo owner — closes with:

Design records under design/ are untouched.

#121 removed the Apple Containers CI jobs on the same basis. Amending design/podman-backend.md here would depart from how the two preceding PRs in this sequence handled the identical situation.

3. Nothing is being deleted silently. This is step 3 of retiring the non-Docker backends, stated in the PR description with the two prior PRs named. runtime/podman/ is removed in the next PR, and design/podman-backend.md goes with it — so a "superseded" banner added now would be written onto a file scheduled for deletion, which is churn rather than accuracy.

4. The gate was weaker than the finding implies. The job smoke-tested a checkpoint first and skipped green — with the real reason — on any runner whose kernel couldn't drive a nested CRIU checkpoint (ci.yml:99-102 in the deleted block). It was a best-effort gate that reported success on incapable runners, not a guarantee. TestPodmanXNode_* never ran in CI at all (no DCCKPT_XNODE_DIR, two hosts required).

Standing up a self-hosted or scheduled Podman+CRIU runner, as the fix suggests, would mean provisioning infrastructure for a backend being deleted in the next PR.

I'd rather leave this one standing as advisory than paper over it, unless you see something in the above that's wrong. One point from your coverage gaps is genuinely useful and I've passed it on: you found the accessible Trunk ruleset declares no required checks, which answers most of the branch-protection question I flagged in the description — legacy protection is still unverified (403 for both of us).

[dap-code-review-by-crunchloop]

No open findings on c9958ad.

Approved by DAP code review. The DAP Code Review check run remains the verdict of record; this approval is a projection of it for branch protection, and is dismissed if a finding reopens or a later head is not clean.