Skip to content

v2.4.0

Choose a tag to compare

@devgony devgony released this 09 Aug 07:29
· 4 commits to main since this release

Highlights

Fork pull requests get diff coverage without double builds

Baseline reads from GitHub repository storage no longer require the pull
request head to live in the same repository. Fork PRs fetch stored baselines
with the default read-only fork token (same-repository storage) or
anonymously (public storage repositories), so they get diff coverage and the
fail-on-uncovered gate without re-running the test suite at the merge-base.
All write paths (storage push, Pages deploy, PR comments, annotations) keep
the same-repository gate.

Deploy Pages reports into shared and cross-repository sites

The Pages inputs now mirror the repository storage inputs:

  • pages-repo — deploy the HTML report into another repository's Pages site
  • pages-prefix — deploy under a directory instead of the branch root
  • pages-token — a dedicated credential, kept separate from the
    github-token used for PR comments and check annotations

Setting a prefix or a foreign pages-repo marks the branch as shared:
Badgers appends regular commits, never rewrites history, writes only inside
the prefix, and leaves root files such as .nojekyll and CNAME untouched.
Concurrent pushes from other jobs are retried by re-cloning and re-applying
the report, which cannot produce merge conflicts.

pages: true
pages-repo: gluesql/gluesql.github.io
pages-prefix: coverage/badgers
pages-token: ${{ secrets.PAGES_DEPLOY_PAT }} # Contents + Pages write

The report-url output resolves the target repository's Pages
configuration, including custom domains and owner.github.io root sites.

Pages builds are no longer a silent failure

Commits pushed with the workflow's default GITHUB_TOKEN never trigger a
GitHub Pages build, so previous runs pushed the report and linked a site
that never updated. Badgers now requests a build explicitly through the REST
API after each push. Grant the job pages: write (or pass a PAT/GitHub App
token as pages-token); without it the action emits a warning explaining
why the site is stale.

base-rebuild: never — a safety valve for expensive suites

When no stored baseline matches the merge-base, base-rebuild: auto (the
default) re-runs coverage-command at the merge-base as before. Set
never to skip the rebuild and degrade to a head-only report: diff coverage
for changed lines and both coverage gates still work, only the total
coverage delta is omitted.

SHA-pinned action refs get prebuilt binaries

uses: devgony/badgers@<full-sha> with cli-version: auto previously fell
back to a source build without a word. The action now resolves the release
recorded in the pinned checkout's manifest, so security-hardened workflows
that pin actions to commit SHAs still download the matching prebuilt CLI.
Every remaining source-build fallback is logged with its reason.

Retention for Pages reports

pages-retention: <N> keeps only the N pr-* report directories with the
highest PR numbers (plus the current deployment) under the prefix, keeping
the branch clear of GitHub Pages size limits. branch-* directories and
anything outside the prefix are always kept. The default all prunes
nothing.

Fixes

  • The merge-base worktree at /tmp/badgers-base is now removed after the
    baseline is built — even when the coverage command fails — and stale
    worktrees from interrupted runs are cleaned up before reuse. This fixes
    repeated runs on self-hosted runners and halves peak disk usage for
    baseline rebuilds.
  • Storage baseline fetches with an empty github-storage-token now try
    anonymous read access before falling back to a rebuild, so public storage
    repositories work without any token.

⚠️ Behavior change: badgers-owned Pages branches

When the report deploys to the current repository's Pages branch without a
prefix
, each deployment now replaces the branch with exactly one
parentless commit — previously deployed report directories are preserved,
but branch history is discarded so it can never grow toward the 1 GB Pages
limit. Two consequences:

  • A branch-protected gh-pages branch will reject the push. Remove the
    protection or deploy elsewhere.
  • If your gh-pages root also hosts content deployed by other jobs, set
    pages-prefix — that switches Badgers to the shared, append-only mode
    described above.

Full Changelog: v2.3.0...v2.4.0