Goal
Reduce repeated dependency build time by ensuring dependency-related container layers are reused when Cargo dependencies are unchanged inside each workflow run sequence.
Background
A quick analysis suggests dependency-heavy container build layers are often rebuilt even when dependency inputs do not change. In principle, when only application code changes and Cargo dependency metadata remains the same, dependency cook layers should be reusable.
Current workflows use isolated cache scopes to avoid conflicts and race conditions when multiple jobs write cache data concurrently. This issue treats that isolation as a current constraint and focuses first on making cache reuse reliable within each workflow.
A further concern emerged from post-#1853 CI analysis: in this repository, most logic lives in in-repo workspace packages (not external crates), and those packages change on nearly every PR. The cargo-chef cook stage can only pre-compile external dependencies; workspace members must always be compiled from source in the build stage. This raises the question of whether the cook/build split provides meaningful cache benefit at all given this churn pattern, or whether an alternative scoping strategy would be more effective. This issue must include that evaluation (T3).
Parent
Part of EPIC #1840 — Improve PR workflow performance.
Local Spec
docs/issues/open/ — spec file will be added in a follow-up spec-only PR.
Related Issues
Goal
Reduce repeated dependency build time by ensuring dependency-related container layers are reused when Cargo dependencies are unchanged inside each workflow run sequence.
Background
A quick analysis suggests dependency-heavy container build layers are often rebuilt even when dependency inputs do not change. In principle, when only application code changes and Cargo dependency metadata remains the same, dependency cook layers should be reusable.
Current workflows use isolated cache scopes to avoid conflicts and race conditions when multiple jobs write cache data concurrently. This issue treats that isolation as a current constraint and focuses first on making cache reuse reliable within each workflow.
A further concern emerged from post-#1853 CI analysis: in this repository, most logic lives in in-repo workspace packages (not external crates), and those packages change on nearly every PR. The
cargo-chefcook stage can only pre-compile external dependencies; workspace members must always be compiled from source in the build stage. This raises the question of whether the cook/build split provides meaningful cache benefit at all given this churn pattern, or whether an alternative scoping strategy would be more effective. This issue must include that evaluation (T3).Parent
Part of EPIC #1840 — Improve PR workflow performance.
Local Spec
docs/issues/open/— spec file will be added in a follow-up spec-only PR.Related Issues