Binary Size GitHub Actions workflow. It gates PRs on binary growth and keeps a historical size series. This closes the feedback loop that previously allowed dependency bloat and cross-crate monomorphization creep to go undetected between audits.
What is tracked
All metrics come from a single release build. This build usesfat LTO, codegen-units=1, and keeps symbols so cargo bloat can reuse it without recompiling.
PR gate
Every PR gets a sticky comment with all metric deltas and a per-crate top-movers table. The job fails when either of the two gated metrics exceeds its absolute per-PR budget:
Absolute budgets catch real regressions on large binaries that percentage thresholds would hide. Sizes are deterministic across the pinned toolchain, so deltas are noise-free.
Escape hatch
Add thesize-increase-ok label to a PR and re-run the failed job to downgrade the gate to a warning. Use this for expected jumps such as toolchain bumps, accepted new dependencies, or deliberate feature additions. The size increase still lands in the historical series.
The workflow queries the label live at gate time (not from the frozen event payload), so adding the label and re-running always works, even after the workflow has already triggered.
Historical series
The push job stores every main-branch measurement atdev/binary-size on gh-pages via github-action-benchmark. A 102% alert threshold posts a comment on the offending commit as a post-merge safety net for regressions that slipped through the PR gate (e.g. via the label).
Charts: https://oxidezap.github.io/whatsapp-rust/dev/binary-size/
Baseline semantics
The PR baseline is thesize-metrics artifact from the latest successful main run, not the merge-base commit. A long-lived stale PR can therefore show deltas inherited from main merges that happened while it sat open — rebase to clear them.