Skip to content

Scenario S1: One Library, Baseline Committed in the Repo

You maintain one shared library. Its previous accepted ABI/API surface is a snapshot file (baseline.json, abicheck dump's output) checked directly into the repository — no release process, no separate baseline-storage backend, nothing to fetch. This is the minimal onboarding case ADR-047 §8 calls S1: "the root Action alone suffices, no new primitive needed."

What you need

  1. A candidate binary (built by an earlier step in the same job, or checked out from a release artifact).
  2. A committed baseline snapshot.
  3. Nothing else — no .abicheck.yml targets:/profiles:/baseline: block, no reusable workflow, no separate baseline-publishing job. Those exist for the scenarios after this one (multiple targets, multiple profiles, a baseline that refreshes itself) — adding them here before you need them is pure overhead.

The check

Call the root Action directly in your PR workflow, pointing old-library at the committed snapshot and new-library at the just-built candidate:

- uses: abicheck/abicheck@v0.5.0
  with:
    old-library: baseline.json
    new-library: build/lib/libfoo.so
    header: include/

That's the whole integration. See the GitHub Action reference for every input/ output this Action accepts, and Creating and Comparing a Baseline for how baseline.json itself gets produced and refreshed.

When to move past this scenario

  • More than one library → S15 (multiple independent targets) or S14 (one release bundle) — see check-project.yml's matrix, not N copies of this same step.
  • The baseline should track the last release or main, not a file you update by hand → S2/S19/S20 — publish-baseline/update-main-baseline. check-single.yml's baseline-channel/baseline-artifact-name inputs are the bridge once you have one of those.
  • Your build is expensive and this step re-parses a binary a separate job already built → S3: Reuse an Existing Build.

See also