Every review fetches the repository from scratch, so reviewing the same repository repeatedly re-downloads the same objects each time.
Observed
Workbench provisioning creates an empty repository per run and populates it over the network:
gitCommand(ctx, "", "init", req.Artifacts.WorkbenchRepoDir)
gitCommand(ctx, req.Artifacts.WorkbenchRepoDir, "remote", "add", "origin", baseRemoteURL)
ensureCommit(ctx, ..., req.ReviewPR.Base, baseRemoteURL)
ensurePullRequestHead(ctx, ..., req.ReviewPR.Head, baseRemoteURL)
Nothing is shared between runs: reusable() is keyed on the run's own artifact directory, so a second review of the same repository starts from an empty directory again.
Why it matters
Deleting the workbench after a successful review reclaims the disk, but the network cost was always the larger recurring one and is untouched by that change — arguably it is now paid more often, since the objects are no longer sitting on disk from the previous run.
For anyone reviewing the same repositories repeatedly, which is the normal usage pattern, the same objects are fetched on every run.
Possible shape
A per-repository object store that runs borrow from, rather than a per-run clone: a bare cache keyed on the remote, with each workbench created against it so only objects the cache lacks cross the network. Git supports this through alternates or --reference, and both have a known failure mode worth designing around — a workbench holding a reference to an object store that is later pruned.
Retention then needs a rule of its own, since the cache outlives the runs that populate it and is not covered by the existing run-artifact window.
Notes
Filing as a design question rather than a fix. The alternates approach has real sharp edges around pruning and corruption, so the trade-off is worth stating explicitly before anyone implements it.
Every review fetches the repository from scratch, so reviewing the same repository repeatedly re-downloads the same objects each time.
Observed
Workbench provisioning creates an empty repository per run and populates it over the network:
Nothing is shared between runs:
reusable()is keyed on the run's own artifact directory, so a second review of the same repository starts from an empty directory again.Why it matters
Deleting the workbench after a successful review reclaims the disk, but the network cost was always the larger recurring one and is untouched by that change — arguably it is now paid more often, since the objects are no longer sitting on disk from the previous run.
For anyone reviewing the same repositories repeatedly, which is the normal usage pattern, the same objects are fetched on every run.
Possible shape
A per-repository object store that runs borrow from, rather than a per-run clone: a bare cache keyed on the remote, with each workbench created against it so only objects the cache lacks cross the network. Git supports this through alternates or
--reference, and both have a known failure mode worth designing around — a workbench holding a reference to an object store that is later pruned.Retention then needs a rule of its own, since the cache outlives the runs that populate it and is not covered by the existing run-artifact window.
Notes
Filing as a design question rather than a fix. The alternates approach has real sharp edges around pruning and corruption, so the trade-off is worth stating explicitly before anyone implements it.