ci: speed coverage, PR CI, and publish-track certification

Problem

Local make coverage-rust takes ~40 minutes. PR CI still duplicates native rebuild work. Publication certification (Binding RC multi-OS ~1.5–2.5h plus optional M1 load up to ~4h and extras) takes hours and blocks frequent publishing—including scheduled runs.

This is infrastructure/toil and test/proof debt in quality regime A. Correctness and registry honesty must remain; wall-clock must become a first-class constraint.

Objective

Make speed a first-class engineering value alongside honesty. Every surface has a wall-clock target, sheds work not required for its objective, and parallelizes the rest. Frequent publishing uses a publish-track, not a separately named “nightly” product.

Establish dual tracks:

Surface	Objective	Wall-clock target
PR Test Suite + CI Gate	Changed-surface correctness	≤10m p50 / ≤12m p95
`make coverage-rust`	Honest floors	≤20m p50 local
Binding RC	Multi-OS publish bytes + offline rehearsal	≤20m p50 warm / ≤35m cold
publish-track	Registry-honest publish (scheduled or on-demand)	≤35m p50 / ≤50m cold (RC + tag + publish)
Human release close	Milestone / coordinated GA confidence	publish-track + optional gates (M1/extras as documented)

Unchanged-SHA reuse: skip redundant RC when a complete unexpired same-SHA candidate exists; publish-only ≤15m.

Requirements

Document dual-track objectives (PR / publish-track / human close) and speed as a value in TESTING.md, workflows README, PUBLISHING.md / publication-order.md.
Rewrite CI storage policy around Blacksmith-first primitives: sticky disks for target/ / optional .sccache, colocated actions/cache for registries; retire GitHub-cache-era bans that block RC speed.
Define and automate publish-track: Binding RC → tag / release identity → publish.yaml on retained bytes; defer M1, checkpoint, m20, m21 from publish-track.
Speed Binding RC: sticky target/ (Linux), sccache on sticky, bigger runners, slim post-build acceptance, assemble parallelism, skip RC when SHA unchanged.
Speed coverage-rust: align llvm-cov with instrumented release; parallel Python‖Node acceptance and binding *.py; HTML opt-in.
PR Test Suite: artifact-share Concurrency Matrix; path-gated policy slim; dedupe local make coverage / pre-push orchestration.

Acceptance Criteria

Dual-track (PR / publish-track / human close) objectives documented; speed called out as a value.
Blacksmith-first storage policy merged; Binding RC uses sticky target/ on Linux.
publish-track runs Binding RC → tag → publish without M1/checkpoint/m20/m21 as blockers.
Binding RC ≤20m p50 warm / ≤35m cold (measured on same SHA before/after where practical).
publish-track ≤35m p50 / ≤50m cold; unchanged-SHA publish-only ≤15m.
Local coverage-rust ≤20m p50 (measured).
PR Test Suite ≤10m p50 / ≤12m p95 on binding/Rust PRs after artifact-share.
Registry honesty invariants unchanged: same-SHA Binding RC candidate partitions + offline rehearsal; publish.yaml writes only retained bytes (no rebuild-on-write); fresh registry observation; topo order; immutable tags; reconciliation green.
No floor weakening, skips, sleeps, blanket ignores, or weakened assertions.

BDD Completion Scenarios

Dual-track docs

Given a maintainer reads TESTING / workflows README / PUBLISHING
When they choose a surface (PR, publish-track, human close)
Then each surface’s objective, required-when, wall-clock target, must-keep, and shed/defer list is explicit
And stale claims that CI runs full coverage or that every publication evidence gate blocks every publish are gone.

Blacksmith storage

Given Binding RC runs on Blacksmith Linux
When a warm sticky target/ hit occurs
Then the cell does not cold-rebuild the full release tree from empty
And the storage policy tests encode sticky + colocated-cache rules (not GHA-era bans that forbid them).

Publish-track honesty

Given main tip is green and Binding RC retains a complete same-SHA candidate
When publish-track runs
Then tag/release identity is created and publish.yaml publishes retained bytes without rebuild
And M1/checkpoint/m20/m21 are not required blockers
And mixed SHA, incomplete candidate, expired artifacts, or registry conflict fail closed.

Coverage speed

Given a coverage-sensitive local tree
When make coverage-rust runs after profile align + parallel acceptance
Then floors and ledger honesty remain
And wall-clock p50 is ≤20m (measured).

PR CI

Given a binding/Rust PR
When PR Test Suite runs with artifact-share
Then Concurrency Matrix does not perform a third native rebuild
And p50 wall-clock is ≤10m.

Non-Goals

Weakening coverage floors or skipping Binding RC multi-OS natives required by npm/PyPI platform matrix.
Rebuild-on-write in publish.yaml.
Running Binding RC on every PR.
Moving M1/load (or checkpoint/m20/m21) into PR CI or into publish-track as a blocker.
Claiming GA/milestone close without human-track evidence when the runbook still requires it.
Micro-optimizing TCK itself in this program.

Implementation notes

Baseline origin/main at issue creation: 0f3cad576479f9d05b909faeff8b64ca5edebd74.

Priority order: standards → Blacksmith storage policy → publish-track + Binding RC speed → coverage-rust → PR Test Suite + local orchestration.

Canonical close gate: this parent. Native sub-issues block this issue and must not expand scope.

#208 - ci: minimize Blacksmith cache storage [merged]
#278 - fix(ci): retain certification evidence as artifacts [merged]
#305 - feat(release): orchestrate resumable publication [merged]
#361 - test(ci): measure native binding Rust coverage [merged]
#377 - test(release): isolate npm publication dry-run policy [merged]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

Close-out evidence (parent #383)

All child issues merged to main with green exact-head CI Gate. Tip after close-out: 5a8ee9a4f5d21ed9f72a8ea0de6b72c4d6ce6de2.

Child	PR	Merge SHA on `main`
#384 dual-track docs	#390	`c1e814b37a47f1194515b866153314233721ef31`
#385 Blacksmith storage policy	#395	`af88fed387e7755e2a7e839813889536f5f60dee`
#386 publish-track	#393	`62b16d24f634ab89975b60bfea7836ec5b4e2074`
#387 Binding RC sticky/speed	#392	`1d8844bcab86ebbdc35a78beb9e3d9e413af31ad`
#388 coverage-rust speed	#391	`ba4181d65e039c116b04f714f7a8cdfb0aa67455`
#389 PR artifact-share	#394	`5a8ee9a4f5d21ed9f72a8ea0de6b72c4d6ce6de2`

AC outcomes on `main`

Dual-track / speed value docs: docs/engineering/TESTING.md, docs/engineering/PUBLISHING.md, docs/development/publication-order.md, .github/workflows/README.md
Blacksmith-first sticky + colocated cache policy: scripts/ci/test-ci-storage-policy.py + Binding RC sticky Linux mounts
publish-track workflow: .github/workflows/publish-track.yml (RC → tag → publish; M1/checkpoint/m20/m21 deferred)
Binding RC sticky target/ on Linux Blacksmith runners
coverage-rust: release-profile llvm-cov + parallel acceptance (scripts/coverage-rust.sh)
PR artifact-share: Concurrency Matrix consumes same-SHA wheel/addon (.github/workflows/test.yml); PR ci: share PR artifacts with concurrency matrix #394 Test Suite ~10.5m wall-clock (run 30931289631, head 4b92232)

Operational follow-up (non-blocking for this close): multi-run Binding RC warm/cold p50 and local coverage-rust p50 measurement ledgers when a full cold/warm sample set is practical.

All native sub-issues landed on main:

docs: dual-track CI objectives and speed as a first-class value #384 → docs: dual-track CI objectives and speed as a first-class value #390 (c1e814b)
ci: rewrite storage policy for Blacksmith sticky disks and colocated cache #385 → ci: rewrite storage policy for Blacksmith sticky disks and colocated cache #395 (af88fed)
ci: automate publish-track Binding RC to tag to publish.yaml #386 → ci: automate safe publish-track certification #393 (62b16d2)
ci: cut Binding RC wall-clock with sticky disks, runners, and slim acceptance #387 → ci: accelerate Binding RC builds #392 (1d8844b)
test: speed make coverage-rust via profile align and parallel acceptance #388 → test: speed make coverage-rust via profile align and parallel acceptance #391 (ba4181d)
ci: PR Test Suite artifact-share and local coverage orchestration #389 → ci: share PR artifacts with concurrency matrix #394 (squash merge)

Registry honesty invariants preserved (no rebuild-on-write; Binding RC multi-OS retained). Wall-clock ACs remain measured targets for warm Binding RC / publish-track / coverage-rust follow-up evidence on comparable SHAs.

Navigation Menu

Repository navigation

ci: speed coverage, PR CI, and publish-track certification #383

Problem

Objective

Requirements

Acceptance Criteria

BDD Completion Scenarios

Dual-track docs

Blacksmith storage

Publish-track honesty

Coverage speed

PR CI

Non-Goals

Implementation notes

Related

Close-out evidence (parent #383)

AC outcomes on `main`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ci: speed coverage, PR CI, and publish-track certification #383

Description

Problem

Objective

Requirements

Acceptance Criteria

BDD Completion Scenarios

Dual-track docs

Blacksmith storage

Publish-track honesty

Coverage speed

PR CI

Non-Goals

Implementation notes

Related

Activity

coderabbitai commented on Aug 4, 2026

DecisionNerd commented on Aug 4, 2026

Close-out evidence (parent #383)

AC outcomes on main

DecisionNerd commented on Aug 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

AC outcomes on `main`