ci(interp): test the shared sae library, not just the recipes#1685
Draft
polinabinder1 wants to merge 1 commit into
Draft
ci(interp): test the shared sae library, not just the recipes#1685polinabinder1 wants to merge 1 commit into
polinabinder1 wants to merge 1 commit into
Conversation
The interpretability lane runs `pytest tests/` from each recipe dir, so it only
ever collected `recipes/<recipe>/tests`. The shared `sae` library's own suite
(`sae/tests`: streaming, topk, kernels, and the nine gloo/CPU `test_tp_*`
tensor-parallel tests) was never collected by any workflow — a change under
`sae/` only *triggered* the dependent recipes, it never ran the lib's own tests.
Net: the library had zero direct CI coverage.
Make the `sae` lib a first-class matrix entry, exactly like a recipe — the house
style here is "a unit with its own `.ci_build.sh` that gets `pytest tests/`", not
a bespoke standalone job:
* add `sae/.ci_build.sh` — a plain `pip install -e ".[dev]"`. The lib is
domain-agnostic (torch + triton, both in the pytorch base image), so unlike
the evo2 recipe there is no megatron venv to build.
* include `"$SAE"` in the changed-dirs glob so the lib is an eligible unit.
It then rides the same changed-dirs -> build -> `pytest tests/` rails and reports
as `interp-unit-tests (sae)` beside `interp-unit-tests (evo2)`, on the same L4
(so `test_kernels` runs on the GPU and the gloo `test_tp_*` run on its CPUs).
Triggers are inherited, no new gate: a change under `sae/` runs the lib's tests
AND the dependent recipes; a workflow change or the nightly cron runs everything;
a recipe-only change does not run the lib tests.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
Contributor
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
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.
What
Adds CI coverage for the shared
saeinterpretability library's own unit tests (sae/tests/), which no workflow currently runs.Why
The interp lane (
unit-tests-interpretability-recipes.yaml) runspytest tests/from each recipe dir, so it only ever collectsrecipes/<recipe>/tests. The library's own suite —test_streaming,test_topk,test_kernels, and the seventest_tp_*tensor-parallel tests — is never collected. A change undersae/only triggers the dependent recipes; it never runs the lib's own tests. Result: the library has zero direct CI coverage today.How
Make the
saelib a first-class matrix entry, identical to how every recipe/model is tested in this repo — the house style is "a unit with its own.ci_build.shthat getspytest tests/", not a bespoke standalone job:interpretability/sparse_autoencoders/sae/.ci_build.sh— a plainpip install -e ".[dev]". The lib is domain-agnostic (torch + triton, both already in the base image), so unlike the evo2 recipe there is no megatron venv to build.changed-dirsglob ("$RROOT"/*/→"$RROOT"/*/ "$SAE"/) so the lib is an eligible unit alongside the recipes.It then reports as
interp-unit-tests (sae)next tointerp-unit-tests (evo2), on the samelinux-amd64-gpu-l4-latest-1runner — sotest_kernels(Triton) runs on the GPU and the gloo-backedtest_tp_*run on the box's CPUs. No new infra: the TP suite is CPU/gloo multiprocessing (0 CUDA refs), not multi-GPU.When it runs
Inherited from the existing trigger logic, no new gate:
sae/→ runs the lib's tests and the dependent recipes,Validation
This PR touches both the workflow and (indirectly, via the new eligibility) the
saeunit, so its own CI run exercises the newinterp-unit-tests (sae)lane end-to-end. Onmaintoday the evo2 recipe has no.ci_build.shyet (that lands with #1622), so this PR's run is scoped to exactlyinterp-unit-tests (sae).Draft while the first
interp-unit-tests (sae)run is validated.🤖 Generated with Claude Code