ci: install only the uv binary for v4 ingest (drop the workspace sync)#8517
Draft
connortsui20 wants to merge 1 commit into
Draft
ci: install only the uv binary for v4 ingest (drop the workspace sync)#8517connortsui20 wants to merge 1 commit into
connortsui20 wants to merge 1 commit into
Conversation
Supersedes the earlier reorder. The v4 ingest runs `uv run --no-project --with psycopg[binary] --with boto3 --with xxhash`, which needs only the uv binary and an ephemeral env -- never the workspace. But the "Install uv" step used spiraldb/actions/setup-uv, which runs a full `uv sync --all-extras --dev`: it rebuilds vortex-python via maturin -> sccache -> S3, and on the s3-cache bench runners that fails `s3:GetObject AccessDenied` under the just-assumed ingest role (rds-db:connect only). Production proved the sync is dead weight -- the "Install uv" step went red while the ingest still succeeded, because the binary installs before the sync and the ingest doesn't need it. Switch the three v4 "Install uv" steps to astral-sh/setup-uv (the same v7.6.0 binary spiraldb's action vendors) with no sync. This removes the wasteful workspace build, eliminates the sccache->S3 dependency entirely (so step order no longer matters -- the reorder is reverted), and is much faster. The benchmark job's own non-v4 setup-uv is left as-is (it legitimately needs the workspace). Signed-off-by: Connor Tsui <connor@spiraldb.com>
Merging this PR will improve performance by 18.2%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Simulation | chunked_varbinview_canonical_into[(1000, 10)] |
191.6 µs | 154.6 µs | +23.92% |
| ⚡ | Simulation | chunked_varbinview_opt_canonical_into[(1000, 10)] |
206.7 µs | 170.6 µs | +21.11% |
| ⚡ | Simulation | chunked_varbinview_opt_into_canonical[(1000, 10)] |
221 µs | 184.9 µs | +19.53% |
| ⚡ | Simulation | chunked_varbinview_canonical_into[(100, 100)] |
258.8 µs | 224.1 µs | +15.48% |
| ⚡ | Simulation | chunked_varbinview_opt_canonical_into[(100, 100)] |
339.6 µs | 304.9 µs | +11.37% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing ct/bench-v4-emitter-uv-binary (1b7139c) with develop (e0faa08)
connortsui20
added a commit
that referenced
this pull request
Jun 20, 2026
The bench-v4 CI emitter dual-write project shipped to develop via separate code-only PRs (#8513 emitter + workflows, #8516 reorder CI fix + commit-metadata rename, #8517 binary-only uv install). This orchestration branch is retired down to just its `.big-plans/` record -- the spine (goal, decisions, phase map, verdict ledger), the design spec, and the per-sub-phase task plans -- as a durable archive of the planning + execution history. The commit history is squashed; the shipped code lives on develop. Signed-off-by: Connor Tsui <connor@spiraldb.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
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.
The v4 Postgres ingest runs
uv run --no-project --with psycopg[binary] --with boto3 --with xxhash, which needs only the uv binary and an ephemeral env — never the workspace. But the "Install uv" step usesspiraldb/actions/setup-uv, which runs a fulluv sync --all-extras --devthat rebuildsvortex-pythonvia maturin → sccache → S3. On theextras=s3-cachebench runners that failss3:GetObject AccessDeniedunder the just-assumed ingest role (which only hasrds-db:connect).It's
continue-on-error, so CI never broke, and production confirmed the sync is dead weight — the ingest succeeded even when "Install uv" went red, because the binary installs before the sync and the ingest doesn't use the synced workspace. Switch the three v4 "Install uv" steps toastral-sh/setup-uv(the same v7.6.0 binary that action vendors) with no sync, which removes the wasteful workspace build and the sccache→S3 dependency entirely. The benchmark job's own non-v4setup-uvis unchanged.Follow-up to #8516, which fixed the same failure by reordering so the sync ran with good credentials; this drops the now-pointless sync instead, so step order no longer matters.
🤖 Generated with Claude Code