test: stop printing the asserted Result in the seven flagged assertions

[Jaro-c]

Summary

Seven rust/cleartext-logging alerts are open on main, all the same shape: an assertion in the integration suite formatting a Result that CodeQL traced back to create_project_secrets.

The source is the function's name. SensitiveDataCall matches on HeuristicNames::nameIndicatesSensitiveData, so create_project_secrets is a taint source because it contains "secret" — not because of anything its Result<()> can carry, and #1599 already made it impossible for a payload to reach one of those errors.

The fix that corrects the model rather than the sinks needs a ModelsAsDataBarrier, which needs a configuration this repository owns, which the organization's Glyndor baseline pins away. That was #1603 and it is closed. This is what is left.

Why removing the value is certain to work

Not hoped — measured, twice, from the scan's own results:

• resources_health.rs:209 already asserts on the same tainted result with a plain message and is not flagged.
• Eighteen .unwrap() calls on the same values across the suite are not flagged either.

Only assert! interpolating the value is a sink.

Seven changed, eleven left alone

There are eighteen occurrences of the pattern in the suite. CodeQL flagged seven. The other eleven are on paths the query does not reach.

Nothing syntactic separates them, so each of the three files gains a note saying the inconsistency is deliberate. Without it the next reader tidies it up and the alerts come back — which is the failure this repository keeps meeting in prose form.

The one that lost the most is split, not flattened

commands_networking.rs's matches! assertion would have gone from naming what it got to saying nothing:

let err = result.expect_err("expected RunExited, got Ok");
assert!(
    matches!(err, podup::ComposeError::RunExited(_)),
    "expected RunExited, got a different ComposeError variant"
);

expect_err prints the Ok value, which here is (), so it is safe and it keeps the difference between the run succeeded and it failed with the wrong variant. A single flat message would have thrown that away.

Test plan

• cargo fmt --all --check and cargo clippy --locked --all-targets --all-features -- -D warnings, both clean
• The affected tests pass against live Podman: run_flags and commands_networking all green, including the restructured one
• The restructured assertion driven red by expecting Unsupported instead of RunExited — reports "expected RunExited, got a different ComposeError variant"
• Exactly seven occurrences removed: 18 before, 11 after

The cost, stated rather than discovered

These seven no longer say which error they got. And nothing prevents an eighth: a syntactic gate cannot tell the seven from the eleven, so there is no check to add that would not also ban the assertions that are fine.

Whether the alerts actually clear will not be visible until this reaches main, because code scanning runs on the default branch only.

Checklist

• Targets develop
• Commits are signed off (DCO, git commit -s) and signed
• Labels applied
• No secrets, keys or credentials in code, logs or fixtures
• Cargo.toml and debian/changelog untouched
• Docs updated if behaviour changed. Tests only

Refs #3, #4, #5, #6, #7, #8, #9.

Signed-off-by: Jaro-c 75870284+Jaro-c@users.noreply.github.com