ci: name which audit failure happened #13

Merged

jlxq0 merged 1 commit from ci/name-which-audit-failure into main

2026-09-07 04:04:38 +00:00

jlxq0 commented

2026-09-02 02:54:26 +00:00

Owner

main's cargo job failed on 99a213b while the v0.4.2 tag job passed on the same commit eighteen seconds later.

19187  cargo   v0.4.2  02:36:47Z -> 02:37:51Z  success
19186  cargo   main    02:36:29Z -> 02:37:20Z  FAILURE

Fifty-one seconds, so not the two-second never-ran shape. Job logs are not retrievable on this instance, so I reproduced it locally with the same command:

error: couldn't fetch advisory database: git operation failed: failed to prepare fetch

Then two clean runs immediately after. Transient, and nothing to do with the commit.

Why that is worth a change rather than a re-run

A single cargo audit step is red both when a vulnerability exists and when the advisory database cannot be fetched, and those want opposite responses: one is a bump, the other is a re-run. With no logs, the job name is all anyone has, and it says the same thing either way.

The fetch is now its own named step, cloning into a fresh mktemp -d, and audit runs --no-fetch --db against it. A red fetch advisory database is the network. A red audit is a finding.

No retry on the fetch, for the reason this repository has now applied twice: a retry that succeeds hides how often the first attempt fails, and that rate is the measurement.

Both halves exercised, not assumed

The two steps were extracted from the YAML and run exactly as written:

fetch advisory database   exit 0, ADVISORY_DB written to GITHUB_ENV
audit                     exit 0, "warning: 1 allowed warning found"

And the split does not turn the gate into one that cannot fail. The same audit command against v0.3.0's lockfile:

ID:        RUSTSEC-2026-0258
error: 1 vulnerability found!
exit=1

That is the negative control, and it is the reason to trust the green above it.

Incidentally

cargo audit currently reports one allowed warning, chacha20 0.10.1 yanked, at exit 0. Not a vulnerability and not addressed here.

Merging this also clears main's red, since the merge produces a fresh main run.

`main`'s `cargo` job failed on `99a213b` while the `v0.4.2` tag job **passed on the same commit** eighteen seconds later. ``` 19187 cargo v0.4.2 02:36:47Z -> 02:37:51Z success 19186 cargo main 02:36:29Z -> 02:37:20Z FAILURE ``` Fifty-one seconds, so not the two-second never-ran shape. Job logs are not retrievable on this instance, so I reproduced it locally with the same command: ``` error: couldn't fetch advisory database: git operation failed: failed to prepare fetch ``` Then two clean runs immediately after. Transient, and nothing to do with the commit. ## Why that is worth a change rather than a re-run A single `cargo audit` step is red **both** when a vulnerability exists and when the advisory database cannot be fetched, and those want opposite responses: one is a bump, the other is a re-run. With no logs, the job name is all anyone has, and it says the same thing either way. The fetch is now its own named step, cloning into a fresh `mktemp -d`, and `audit` runs `--no-fetch --db` against it. **A red `fetch advisory database` is the network. A red `audit` is a finding.** **No retry on the fetch**, for the reason this repository has now applied twice: a retry that succeeds hides how often the first attempt fails, and that rate is the measurement. ## Both halves exercised, not assumed The two steps were extracted from the YAML and run exactly as written: ``` fetch advisory database exit 0, ADVISORY_DB written to GITHUB_ENV audit exit 0, "warning: 1 allowed warning found" ``` And the split does not turn the gate into one that cannot fail. The same audit command against `v0.3.0`'s lockfile: ``` ID: RUSTSEC-2026-0258 error: 1 vulnerability found! exit=1 ``` That is the negative control, and it is the reason to trust the green above it. ## Incidentally `cargo audit` currently reports one allowed warning, `chacha20 0.10.1 yanked`, at exit 0. Not a vulnerability and not addressed here. Merging this also clears `main`'s red, since the merge produces a fresh `main` run.

jlxq0 added 1 commit

2026-09-02 02:54:26 +00:00

ci: name which audit failure happened

CI / cargo (pull_request) Successful in 48s

Details

CI / docker (pull_request) Successful in 11s

Details

1fd60a5cf4

main's cargo job failed on 99a213b while the v0.4.2 tag job passed on
the same commit eighteen seconds later. Reproduced locally with the same
command: 'couldn't fetch advisory database: git operation failed: failed
to prepare fetch', then two clean runs. Fifty-one seconds, so not the
never-ran shape.

A single cargo audit step is red both when a vulnerability exists and
when the database cannot be fetched, and those want opposite responses.
Job logs are not retrievable on this instance, so the step name is the
only diagnostic anyone gets.

The fetch is now its own step, cloning into a fresh mktemp directory,
and audit runs --no-fetch --db against it. A red 'fetch advisory
database' is the network; a red 'audit' is a finding.

No retry on the fetch. A retry hides how often it fails.

Both steps were run exactly as written before committing, and the split
does not turn the gate into one that cannot fail: against v0.3.0's
lockfile the same audit command still exits 1 on RUSTSEC-2026-0258.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCiHcHN6LrhiuLXbG9SBYG

jlxq0 merged commit 8d6f0a7679 into main

2026-09-07 04:04:38 +00:00

jlxq0 deleted branch ci/name-which-audit-failure

2026-09-07 04:04:38 +00:00

jlxq0 referenced this pull request from a commit

2026-09-07 04:04:38 +00:00

Merge pull request 'ci: name which audit failure happened' (#13) from ci/name-which-audit-failure into main