ci(rust): cargo test -p continuum-core --lib on every PR - #1616
Merged
Conversation
3 tasks
Today's session (2026-06-14) opened the first continuum realization cards on canary — #1613 (lease-revocation classifier) + #1614 (rust toolchain pin). In doing so we discovered NO existing CI workflow runs `cargo test` against continuum-core. `docker-images.yml` builds release bins via cargo-chef (compiles but never executes tests). `carl-install-smoke.yml` exercises the install flow end-to-end. The Rust unit-test surface was entirely unguarded — every Rust PR before #1613 was inspection-verified rather than test-verified. Adds `.github/workflows/continuum-rust-tests.yml` with the minimum gate: - triggers on PRs that touch Cargo.{toml,lock}, rust-toolchain.toml, core/**, or this workflow itself, plus pushes to canary/main; - checks out with submodules: recursive (the llama.cpp + whisper.cpp prereq BIGMAMA hit during Docker self-validation today); - picks up Rust 1.95 from rust-toolchain.toml (PR #1614); - installs the same -dev deps continuum-core.Dockerfile uses; - caches cargo registry + target/ keyed on Cargo.lock with restore-key fallback (cold build ≈ 3-6 min, warm ≈ <1 min); - runs `cargo test -p continuum-core --lib` with default features (Linux-CPU-only, no metal/cuda); - 30-min timeout safety bound; - concurrency group cancels prior runs on the same PR head. `--lib` is the minimum scope. Integration tests + apps/cli + workers binaries can join in follow-up workflows once this one proves stable. The substrate doctrine the dogfood loop surfaced today: validation is infrastructure, not an operator concern. A test that doesn't run in CI is a documentation comment. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
First CI run on this PR exposed ~20 continuum-core unit tests that
have never run on a Linux-CI runner before this workflow existed:
GPU-required (need real GPU + driver):
- gpu::memory_manager::tests::test_detect_returns_nonzero
- modules::gpu::tests::* (13 tests)
Env-var-required (assert behavior contingent on ANTHROPIC_API_KEY etc):
- persona::allocator::tests::test_allocate_with_anthropic_key
- modules::persona_allocator::tests::* (4 tests)
These have never been false-positives — they catch real environment
preconditions. They have just never been gated by feature flag or
hidden-by-default annotation, so until someone built CI for cargo test
they shipped as "ignored by virtue of nobody running them."
This patch skips them by name pattern with --skip so the gate ships
as the baseline (≈4000 other tests CONTINUE to run + protect every
PR). Each skipped pattern is a follow-up:
- task #221: persona_allocator → test-fixtures shim
- new follow-up: gpu::* behind a feature flag
The skip is named and inline-documented, not stealthy. Future PRs that
ADD a real GPU/env-var test will hit the skip pattern and need to
either fix the gate or graduate the test to a separate workflow that
provides the prerequisite.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
joelteply
force-pushed
the
fix/continuum-rust-tests-ci
branch
from
June 14, 2026 22:51
514f2e3 to
75774c9
Compare
This was referenced Jun 15, 2026
joelteply
added a commit
that referenced
this pull request
Jun 15, 2026
The substrate has Rust types with `#[derive(TS)]` + `#[ts(export_to =
"../../../protocol/typescript/...")]` attributes. `cargo test`
regenerates those .ts files as a side effect of running per-type
`export_bindings_*` tests.
When an author adds a new field or variant to a Rust type but forgets
to commit the regenerated .ts file, the wire shape drifts silently:
- Mac/Linux dev: cargo test regenerates locally, looks fine, ships
PR without the .ts in the diff.
- Reviewer: sees only the Rust change, approves.
- Downstream TS consumer at runtime: hits the new variant / missing
field; no compile-time guard fires (the .ts file is stale).
Today's session had a near-miss on continuum #1624 (Mac Intel
classify_silicon fix): TargetSilicon gained the MacIntelMetal variant
but the regenerated `protocol/typescript/governor/TargetSilicon.ts`
was not in the initial push. Had to amend.
Adds `.github/workflows/ts-rs-binding-drift-guard.yml`:
- triggers on PRs touching Cargo, rust-toolchain, core/**, or
protocol/typescript/** (a TS edit needs the gate too — it must
match the Rust source);
- picks up Rust 1.95 from rust-toolchain.toml (#1614);
- runs ONLY the `export_bindings_*` tests (cheap — same skip
patterns as #1616's CI gate so GPU/env-var tests don't sink it);
- then `git diff --exit-code protocol/typescript/`. Non-empty diff
means the test run regenerated bindings that the PR did NOT
commit. Fail with a verbatim fix-recipe in the error log.
Composes with:
- #1614 toolchain pin (Rust version)
- #1616 unit-test CI gate (same skip patterns)
- #1624 (the near-miss this workflow would have caught at CI)
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Today's session opened the first continuum realization cards on canary (#1613 lease-revocation, #1614 toolchain pin). In doing so we discovered NO existing CI workflow runs
cargo testagainst continuum-core.docker-images.ymlbuilds release bins via cargo-chef — compiles but never executes tests.carl-install-smoke.ymlexercises the install flow end-to-end.validate-continuum.ymlis TypeScript-only.Unit tests on the Rust core were entirely unguarded. Every Rust PR before #1613 shipped on inspection-verification rather than test-verification. The substrate doctrine the dogfood loop surfaced today: validation is infrastructure, not an operator concern. A test that doesn't run in CI is a documentation comment.
Changes
.github/workflows/continuum-rust-tests.yml— minimum gate:Cargo.{toml,lock},rust-toolchain.toml,core/**, or this workflow file. Also on pushes tocanary/main.submodules: recursive(the llama.cpp + whisper.cpp prereq BIGMAMA hit during Docker self-validation today).rust-toolchain.toml(added in build(toolchain): pin rust 1.95 — unblock continuum-core unit tests on stable #1614).-devdeps asdocker/continuum-core.Dockerfile.target/keyed onCargo.lockwith restore-key fallback. Cold build ≈ 3-6 min; warm ≈ <1 min after first hit.cargo test -p continuum-core --libwith default features (Linux-CPU-only — nometal, nocuda).--libis the minimum scope. Integration tests +apps/cli+ workers binaries can join in follow-up workflows once this one proves stable.Test plan
cargo-test-continuum-corecheck.continuum-coreunit test, the check turns red before merge.Follow-ups (not blocking)
apps/cli,client/continuum-client, andcore/continuum-orm-deriveto a broader workflow once this gate proves stable.cargo clippy --workspace -- -D warnings).cargo fmt --check.🤖 Generated with Claude Code