Grilling
Turborepo Release Caching Grill Status
Turborepo Release Caching Grill Status
Branch Dashboard
| Branch | Completion | Locked direction | Still open |
|---|---|---|---|
| Retry routing | 100% | An uncached dispatcher probes npm before verification. Existing versions keep the current retry path. New versions run verification and re-probe immediately before publication. | None. |
| Recovery completeness | parked | Preserve current external behavior in this delivery. Accepted future direction completes channel-specific npm dist-tags, Git tag, and GitHub release without republishing. | Separate release-recovery work. |
| Verification cache boundary | 100% | Aim to cache all release tests except an explicit uncached exception set. Ordinary tests use file-level assignment; registered update cases carry explicit cache-policy metadata. | None. |
| Release-test schedule | 100% | Run four update shards in parallel, then the ordinary CLI suite. Typecheck may run beside the test chain. Timing and controlled-network tests may be cached under the declared identity; the real child-process timing assertion remains uncached. | None. |
| Build cache contract | 100% | Root changelogs and both generated outputs affect the CLI build. The generated identity is output-only and is restored from cache. | None. |
| Remote cache trust | 100% | Developer machines and same-repository PR CI share a signed development namespace and may satisfy required PR checks. Protected and release jobs use a separate trusted namespace. | None. |
| Validation contract | 100% | Require forced success, miss/hit, restoration, invalidation, runtime-identity, byte-equality, exact-inventory, uncached-execution, and clean-worktree proofs. | None. |
Current Round
- Round: R7
- Current frontier: empty
- Shared-understanding confirmation: confirmed
| Question id | Prerequisites | Question | State |
|---|---|---|---|
| Q1 | none | What must an existing-version release retry do before reconciliation? | answered |
| Q2 | none | Which deterministic tasks may use Turbo cache in the first delivery? | answered |
| Q3 | none | Must release tests keep the current two-wave schedule? | answered |
| Q4 | Q1 | Which external release state must reconciliation complete? | answered |
| Q5 | Q2 | How should cacheable and uncached tests be separated? | answered |
| Q6 | Q2 | What proof makes a test task cache-eligible? | answered |
| Q7 | Q2 | May the first delivery use shared remote cache results? | answered |
| Q8 | Q4 | What npm dist-tag state must stable and beta reconciliation enforce? | answered |
| Q9 | Q4 | What must happen when an existing Git tag points to another commit? | answered |
| Q10 | Q7 | Who may write reusable CI remote-cache entries? | answered |
| Q11 | Q1, Q4 | Where must the npm version probe route new releases and existing-version reconciliation? | answered |
| Q12 | Q2, Q3, Q5, Q6 | At what granularity are tests classified as cacheable or uncached? | answered |
| Q13 | Q2 | Is the generated baseline identity a build input, a build output, or both? | answered |
| Q14 | Q6, Q7 | Which platform and toolchain values belong in the remote-cache identity? | answered |
| Q15 | Q7, Q10 | Must shared remote-cache entries use artifact signatures? | answered |
| Q16 | Q4, Q8, Q9 | Is external release-state reconciliation part of this caching delivery? | answered |
| Q17 | Q7, Q10, Q15 | How may local development and pull-request runs reuse cache entries without supplying artifacts to protected release jobs? | answered |
| Q18 | Q5, Q6, Q12 | Are timing-sensitive or network-using tests cacheable? | answered |
| Q19 | Q13, Q15 | May release publication consume a restored build artifact from trusted remote cache? | answered |
| Q20 | Q6, Q13, Q14, Q15 | What cache behavior proof is required before delivery is accepted? | answered |
| Q21 | Q18 | May a real OS-timing assertion be cached before it is rewritten to use a controllable boundary? | answered |
| Q22 | Q17 | May a developer-originated cached pass satisfy a required pull-request check? | answered |
Glossary
Terms
- Deterministic verification: A build, typecheck, or test task whose result depends only on declared inputs.
- Release mutation: A change to npm, npm dist-tags, Git tags, or a GitHub release.
- Existing-version retry: A release run where the target package version already exists in npm.
- Reconciliation: A retry operation that brings external release state into the required final state without publishing the package version again.
- Cacheable test task: A test task whose result depends only on declared inputs and controlled execution state.
- Uncached exception set: Tests grouped into tasks that always execute because they still depend on unmodeled state.
Relationships
- A release command can run deterministic verification before it performs a release mutation.
- An existing-version retry performs reconciliation instead of publishing the package version again.
- A test belongs to either a cacheable test task or the uncached exception set for one release run.
- Reconciliation brings a partially completed release to its required final state without publishing the package version again.
Axioms
- A release mutation is never cacheable.
- A task is cacheable only when all result-affecting inputs are declared and all required file outputs can be restored.
- Turbo cache policy applies to a complete task execution, not to one test inside that task.
- Protected-branch and release jobs are the only writers to the protected cache namespace.
- Developer machines and same-repository pull-request CI share one signed development-cache namespace; protected main and release jobs use a separate signed namespace.
Flagged Ambiguities
- "Cache the release" can mean caching deterministic verification or caching release mutations. Only deterministic verification is eligible.
- "Retry" can mean retrying a new publication attempt or reconciling an already-published version. These paths require different behavior.
- "Cache the full suite" means every release test still runs logically, while tests with different cache policies execute in separate Turbo tasks.
- "Repair" was vague. Use reconciliation for completion of missing external release steps after partial failure.
- Effect
TestClockcontrols Effect clock operations. It does not control JavaScript wall-clock reads or operating-system child-process timeouts. - "Local cache seeds CI" means a signed development-cache entry may cross machines only when the complete platform and runtime cache identity matches.
Parked Branches
- External release-state reconciliation. Q4, Q8, and Q9 preserve its accepted future requirements.