The coverage gate measures a Podman-less subset, so the 90% standard is checked nowhere

[Jaro-c]

Measured 2026-08-03, and the gap is not where it looks.

what	lines covered
cargo llvm-cov --lib --bins — what the CI job can see	79.39%
cargo llvm-cov --all-features — the full suite	91.52%

podup already clears the org standard's 90%. It just clears it in a place nothing checks.

Why the job sees less

The rust-ci coverage job runs on a plain runner with no Podman. Every integration test begins with if podman().await.is_none() { return; }, so they all skip, and with them the coverage of dispatch.rs, dispatch/rest.rs, autostart_cmd.rs and the command entry points — all of which read 0.00% under --lib --bins and are exercised heavily by the suite that cannot run there.

The gate was set to 75 against that 79. #1400-style slack: four points could be lost silently. That part is fixed in the accompanying commit by ratcheting to 79, which locks in what holds.

What is actually missing

Nowhere enforces 90. The lane that can run the integration tests — podman-lane.yml, the nested-virt Fedora matrix — runs them for pass/fail and measures no coverage at all. So the org standard's number is satisfied by the code and checked by nothing.

Options, roughly in order of cost:

• Measure coverage in the podman-vm lane and gate at 90 there. Correct, and it is the only place the number means what the standard means. Cost: cargo llvm-cov inside the VM matrix, and a decision about which leg owns the gate when the two majors disagree.
• Keep two gates, named for what they measure. The current job stays a subset floor; a second one carries the real number. Honest, and it doubles the surface to maintain.
• Exclude the untestable-without-Podman files explicitly and gate the remainder at 90. The testing standard allows this — "if a file is genuinely untestable (thin glue), exclude it explicitly and justify the exclusion" — but dispatch.rs is not untestable, it is untestable here, which is a different claim and a worse reason to exclude something.

I would not do the third.

No VM needed to decide; the lane work needs one to verify.

[Jaro-c]

Half done, and the half that is done is the measuring one.

Landed

• ci: close the silent slack in the coverage gate #1327 — the CI job's gate went from 75 to 79, closing four points of silent slack on the subset it can actually see.
• ci(lane): measure coverage where the integration tests can actually run #1332 — the podman-vm lane now runs cargo llvm-cov and reports the number into the job summary, on the scheduled and manual paths only.

Still open, deliberately

The 90% gate. I did not add it, and the reason is the same one this issue exists for: a threshold set from a number never observed in the environment that enforces it is a phantom check waiting to happen. I have 91.5% from my own host; I have nothing from the lane yet. The first manual run is going now, and the gate should follow real numbers from a few runs, not one.

Two things to settle before it goes in:

• Which leg owns it. Podman 5 is the stable one and has a classified failure list; Podman 6 has environmental failures that could depress coverage for reasons unrelated to the code. Gating both means the flakier one decides.
• How much margin. 91.5% against a 90% floor is 1.5 points. If the lane's number sits lower — instrumentation changes what runs, and failing tests cover less — the floor has to be set from what the lane actually produces or it blocks merges on the first bad day.

Verified on the way in

The claim that pull requests are unaffected is not an assertion. The lane runs on its own PR, and its log shows:

coverage pass for Podman 5: 0
coverage pass for Podman 6: 0

with the suite result unchanged. The only PODUP_COVERAGE strings in that log are the script echoing itself, not a run.