Skip to content

Scenario S15: Multiple Independent Targets, One Build

You have several shared libraries, built together (one CI job, one build output), but they don't depend on each other — a break in one says nothing about the others. This is the oneDAL/PVXS-class case ADR-047 §8 names S15: N separate checks, N separate reports, each keeping its own header/compiler context. Deliberately distinct from S14 (a release bundle — one report, cross-library findings): here, one target's failure never invalidates another's report.

Declaring several targets

Nothing beyond what S3 already sets up — list every target under .abicheck.yml's targets: block, each with its own checks::

targets:
  libfoo:
    binary_pattern: "lib/libfoo.so*"
    public_headers: ["headers/foo"]
    checks:
      - channel: accepted-main
        depth: headers
  libbar:
    binary_pattern: "lib/libbar.so*"
    public_headers: ["headers/bar"]
    checks:
      - channel: accepted-main
        depth: headers

check-project.yml generates one matrix cell per target from this — each cell downloads its own candidate binary (via its own binary_pattern glob) and runs independently (fail-fast: false); libfoo's check failing never skips or blocks libbar's.

Do you need a combined CI status?

Not necessarily. If each target's own check is already a required branch-protection status check, that's the whole gate — no extra step. A combined "one CI status from N checks" is S28's job (check-project.yml's own trailing aggregate job, which runs automatically whenever any cell in the plan uses gate-mode: deferred), not something S15 itself requires.

When to move past this scenario

See also