Reuse graph integration build outputs without skipping validation #9668
Closed
dnikolayev
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I would like to reduce repeated graph compilation during integration startup while preserving the current tests and service lifecycle.
In Test run 34585846537, the workflow took 22m 53s. The integration startup steps include
cargo build --bin hash-graph --all-features, and the graph compile task currently disables Turbo caching. These historical observations identify a candidate cost; they are not a controlled baseline or demonstrated savings.The investigation starts from main at
67f60d5446ed3224609161f938e1b36bc9d62f89. Relative to the historical executed merge83a8548e394001846d8ff72424f870ce611f88ea, onlypackage.jsonandyarn.lockdiffer; the relevant workflow and graph startup configuration are unchanged.The proposed scope is reuse of the graph integration build output through existing build/cache mechanisms. Reuse must bind the effective pruned workspace, direct and transitive sources, generated inputs, lockfiles, toolchain, target, build flags, profile/features, and build environment. A missing or invalid output must take the normal build path. Migrations, health checks, service startup, integration test selection, coverage, retries, and timeouts stay live. Cache access must retain GitHub's fork/PR trust boundaries.
I found the existing frontend build caching PR, so frontend caching is excluded here. I will also avoid adding a shared producer dependency or other architectural change without maintainer agreement.
Validation will include colocated focused tests and paired GitHub Actions measurements, separating cold and warm fresh runners and input-change rebuilds. The comparison will retain raw job/step timings, test counts, transfer overhead, scheduling delay, aggregate job-minutes, and the actual workflow critical path, with at least three successful samples per primary condition and variant. Credential-free fork measurements will be labelled separately from upstream performance. The pull request will remain draft while required performance evidence, checks, or contributor agreement are outstanding.
Please flag any overlapping graph build work or constraints on this narrow approach.
All reactions