ci: compile the opt-in features, and widen the research path filter - #184
Open
adityak74 wants to merge 4 commits into
Open
ci: compile the opt-in features, and widen the research path filter#184adityak74 wants to merge 4 commits into
adityak74 wants to merge 4 commits into
Conversation
adityak74
force-pushed
the
ci/close-gating-gaps
branch
from
September 6, 2026 00:44
6fed0dd to
4f93bb5
Compare
`cargo test --workspace` resolves default features only, so every non-default feature in this workspace was dead to CI. Nothing compiled a line of `otel`, `search`, `clipboard` or `library` on zorp-agent, `search`, `memory` or `voice` on zorp-web, or `library` on zorp-track. A `#[cfg(feature = ...)]` block could stop compiling and no build would go red until somebody turned the feature on. `recall` and `research` were already covered and are not duplicated here. A new `features` job takes the cheap ones on the per-pull-request path with no filter. `otel`, `search` and `clipboard` are one `cargo clippy --all-targets -- -D warnings` invocation, because none of the three has a test the default build does not already run, so the only question is whether the code compiles, and clippy answers that and lints code no lint had ever seen. zorp-web's `search`, `memory` and `voice` do have tests of their own, so they get `cargo test`. `library` pulls LanceDB and the whole arrow tree, so it joins the `research` pair, which already builds DuckDB from source and already installs protoc. Both timeouts move from 60 to 90 minutes, since that is a third slow build on a cold cache. The `research-pr` filter missed `erbga/`, which zorp-track's search layer depends on, all of `zorp-agent/tests/`, `src/lib.rs` and `src/main.rs` on both crates, `zorp-web/src/api.rs`, and this workflow file, so a change to the research jobs could not run the research jobs. `docs/` stays out, specs included: prose cannot break a build, and a twenty minute job that fires on prose is a job people learn to ignore. No Harbor job. The adapter exists and has tests, but they skip themselves when Harbor is absent, on purpose, so running them in CI means either installing Harbor from PyPI, which puts a package index in the critical path of a gate, or collecting eight skips, which is a green check that checks nothing. Nothing added here touches the network. `jobs/` is gitignored; it is per-run local scratch in the repo root. Claude-Session: https://claude.ai/code/session_01PG2vuux5tMsjnZBLWJzMyp
`Test zorp-track (library feature)` failed on an ubuntu runner with ar: .../libduckdb.a: error reading .../ub_src_function_cast_variant.o: No space left on device which is the runner's disk, not this code. The job resolves three different feature sets, so `libduckdb-sys` gets a different metadata hash each time and the bundled DuckDB amalgamation is compiled three times over, and the `library` steps then add LanceDB and the whole arrow tree on top. That does not fit in the roughly 14 GB an ubuntu image leaves free. Deleting the android, CodeQL, dotnet, swift and ghc trees the workspace never touches buys about 17 GB in well under a minute. `rm -rf` of a path a future image stops shipping is a no-op, so this cannot start failing because somebody upstream reorganised the image, and it is before `Install Rust` with only CodeQL taken out of the hosted tool cache so the toolchain that lands after it is intact. A job that dies on disk space reports nothing about the code it was meant to gate. Claude-Session: https://claude.ai/code/session_01PG2vuux5tMsjnZBLWJzMyp
Two runs said what a runner can hold. The research job compiles the bundled DuckDB amalgamation once per feature set it resolves, because each one gives libduckdb-sys a different metadata hash and none of them shares a build with the others. Three of those already fit with almost nothing spare. A fourth, `cargo test -p zorp-track --features library`, plus the whole arrow tree, failed with ar: .../libduckdb.a: error reading .../ub_src_function_cast_variant.o: No space left on device Freeing about 17 GB made the fourth fit. A fifth, `cargo check -p zorp-agent --features library`, failed the same way even then, after 47 minutes, which was already far too slow for the per-pull-request path. So `research-pr` carries no library step and goes back to the three research builds and about twenty minutes. `zorp-track --features library` runs nightly and on pushes to main, where nothing is waiting on it. `zorp-agent --features library` is not gated at all: what that leaves uncovered is one `#[cfg]` in validate calling an API the nightly step already compiles and tests, and an ungated opt-in feature is a smaller problem than a step that cannot finish. A gate that goes red for a reason with nothing to do with the code is the thing this repo refuses. Both research jobs free disk first and print `df -h /` on each side, so the headroom is visible rather than rediscovered. Claude-Session: https://claude.ai/code/session_01PG2vuux5tMsjnZBLWJzMyp
The free-disk step printed `df -h /` on both sides, so the figures are observed now rather than assumed: the runner starts with about 87 GB free, not the 14 GB the comment claimed, and deleting the toolchains this workspace never uses reclaims about 22 GB. A debug build of the bundled DuckDB amalgamation is enormous and this job makes several, so 87 GB is genuinely most of the way used before the arrow tree arrives. Those 22 GB are the difference between the fourth build fitting and not. `research-pr` measured at 13m38s warm, so the twenty minute figure is corrected to fourteen. Claude-Session: https://claude.ai/code/session_01PG2vuux5tMsjnZBLWJzMyp
adityak74
force-pushed
the
ci/close-gating-gaps
branch
from
September 6, 2026 02:28
8905988 to
b4a0b4c
Compare
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.
cargo test --workspaceresolves default features only, so every non-default feature in this workspace was dead to CI. Nothing compiled a line ofotel,search,clipboardorlibraryon zorp-agent,search,memoryorvoiceon zorp-web, orlibraryon zorp-track. A#[cfg(feature = ...)]block could stop compiling and no build would go red until somebody turned the feature on.recallandresearchwere already covered and are not duplicated.What is gated now
zorp-agentotel,search,clipboardcargo clippy -p zorp-agent --features otel,search,clipboard --all-targets --locked -- -D warningsfeaturesjob, every PRzorp-websearch,memory,voicecargo test -p zorp-web --features search,memory,voice --lockedfeaturesjob, every PRzorp-tracklibrarycargo test -p zorp-track --features library --lockedresearchonly: nightly and pushes to mainzorp-agentlibraryclippy rather than test for the first row because none of those three has a test the default build does not already run, so the only question is whether the feature-gated code compiles, and clippy answers that and lints code no lint had ever seen. The zorp-web three do have tests of their own, so they get
cargo test. Nothing here touches the network: the search tests use a nonsense key and never spend a search, and the memory and voice tests run their servers on loopback.libraryis nightly, and half of it is ungated, because of runner diskThe research job compiles the bundled DuckDB amalgamation once per feature set it resolves, because each one gives
libduckdb-sysa different metadata hash and none of them shares a build with the others. A debug build of it is enormous. The runner starts with about 87 GB free and three of those builds is already most of it.A fourth,
cargo test -p zorp-track --features library, plus the whole arrow tree, failed withwhich reads like a compiler error and is not one. Both research jobs now free disk first and print
df -h /on each side: deleting the android, CodeQL, dotnet, swift and ghc trees reclaims about 22 GB (measured, 87 GB to 108 GB), and that is the difference between the fourth build fitting and not.A fifth,
cargo check -p zorp-agent --features library, did not fit even then, and the run that proved it took 47 minutes. So that step is dropped entirely. What it leaves uncovered is one#[cfg]invalidatecalling an API the nightly step already compiles and tests. An ungated opt-in feature is a smaller problem than a step that cannot finish, and CLAUDE.md already says to leavelibraryoff unless you are working on retrieval. A gate that goes red for a reason with nothing to do with the code is the thing this repo refuses.research-prtherefore carries no library step. It measures 6m53s warm and 13m38s on a partial cache.The
research-prpath filterIt missed
erbga/, which zorp-track's search layer depends on, all ofzorp-agent/tests/,src/lib.rsandsrc/main.rson both crates,zorp-web/src/api.rs, and this workflow file, so a change to the research jobs could not run the research jobs. Every path added is one the research steps actually compile.docs/stays out, specs included: a documentation change cannot break a build, and a long job that fires on prose is a job people learn to ignore. The nightly run is the backstop for whatever the filter cannot name.No Harbor job
The adapter exists at
evals/harbor/zorp_agent.pyand has tests, but those tests skip themselves when Harbor is not installed, on purpose, because a stubbed version of them passed for a year while the adapter could not be imported. So CI could only install Harbor from PyPI, which puts a package index in the critical path of a gate, or run them without it and collect eight skips, which is a green check that checks nothing.py_compileinstead would be the same false comfort in a smaller package.Also
jobs/is gitignored; it is per-run local scratch written into the repository root.https://claude.ai/code/session_01PG2vuux5tMsjnZBLWJzMyp