Abbreviatory Now Tracks New Warnings and Runs as a GitHub Action

Warnings pile up. A build has forty of them, everyone stopped reading them months ago, and the one that matters, the deprecation that turns into an error next quarter, arrives as number forty-one. Abbreviatory has always kept warnings in its report. Until now it didn’t say which ones were new.

v0.6.0 does, behind a flag. Run with -warnings and a history, and the report compares warnings with the last run the way it already compares failures. New ones are listed at the top and marked (new). Ones that went away are listed as gone, with a reference back into the run where they last appeared.

Two panels. On the left, a cargo build report for run 2 lists one new warning and one warning gone above the recurring errors. On the right, a GitHub Actions step using abbreviatory/engine@v0.6.0 with run and warnings inputs, and what the step does.

What It Looks Like

A Rust build, second run, after someone swapped a HashMap import for a BTreeMap one:

[abbreviatory] cargo / rustc output, 119 lines (5.2 kB), ref 538a9844f655
run 2; since run 1: the same errors; 6 recurring (longest for 2 runs), 1 new warning, 1 warning gone
new warning: warning: unused import: `std::collections::BTreeMap` at src/report.rs:2:5 [ref 538a9844f655:g3]
warning gone: warning: unused import: `std::collections::HashMap` at src/report.rs:2:5 [ref 905ded08dbb8:g3]

A warning is known by what it says with the numbers taken out, the same as a log error. So a warning that moved down three lines because someone added code above it is the same warning, not a new one. The old warnings stay quiet. The new one is the first thing you read.

A run is compared with the one just before it, so both need the flag. When the last run didn’t record warnings, the report says they weren’t compared rather than pretending nothing changed.

The GitHub Action

Getting run history working in CI used to take a dozen lines of YAML: restore a cache, run, prune, save the cache whether the tests passed or not. Now it’s one step:

- uses: abbreviatory/[email protected]
  with:
    run: go test -json ./...
    warnings: true

The action downloads the release for the runner and checks it against the published checksums. It runs your command and writes the report to the job summary. It keeps the run history in the Actions cache, so the second run on a branch already knows what’s new. And it fails the step when your command fails, unless you set fail: false to report only.

Its outputs are there for the next steps: the exit code, pass or fail, how many failures are new, how many are fixed, how many new warnings. Each use of the action in a job keeps its own history, and so does each job of a matrix, so a Go 1.25 run doesn’t get compared with a Go 1.26 one.

It works on Linux, macOS and Windows runners. The test for it runs the action on all three, twice across jobs, to check that the history really comes back from the cache.

Found by the Review

Two independent reviews again, ten defects between them, all fixed before release. The big one: when the command failed, the action’s step stopped before it wrote its outputs and its report. So the action worked fine on passing tests, which is exactly when you need it least. The action’s own test caught it on its first run too.

Others were quieter. With more than 50,000 kinds of warning in one run, a warning could look gone when it had only been folded into the overflow. That case now says the warnings weren’t compared. Every saved run kept its whole warning list, so history files grew large and slow. Now only the newest run keeps it.

Get It

Download v0.6.0, or add the action to a workflow. The reference has every flag and input.