Skip to content

[Docs] Evaluate walgit for repository bootstrap - #1635

Draft
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/walgit-bootstrap-evaluation-33bpsnbmmu9dq
Draft

[Docs] Evaluate walgit for repository bootstrap#1635
roomote-roomote[bot] wants to merge 1 commit into
developfrom
feature/walgit-bootstrap-evaluation-33bpsnbmmu9dq

Conversation

@roomote-roomote

Copy link
Copy Markdown
Contributor

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

Added a technical evaluation of walgit as a possible repository bootstrap accelerator for disposable Roomote sandboxes. It documents the current clone/startup path, fit and non-fit, security and tenant-isolation constraints, and a gated A/B experiment with statistical success criteria.

The recommendation is a no-go for production adoption and only a conditional go for an isolated blobless bundle-uri experiment after existing setup telemetry proves clone transfer is a material bottleneck.

Why this change was made

The radar signal identified walgit's object-store-backed Git architecture as potentially useful for large repositories. A complete audit of 128 open PRs found no exact walgit, bundle-URI, mirror, or shared Git object-cache work; PR #934 is adjacent clone-timeout work and remains separate.

The evaluation turns that signal into a durable, source-pinned decision while avoiding a speculative provider or clone-path implementation. It also captures walgit's documented filtered-bundle caveat and current repository-authorization gap before either can become a production risk.

Impact

There is no runtime behavior change. Reviewers gain a concrete decision gate and experiment design that preserves the existing source-control provider as origin, fetch target, credential authority, and push destination.

@roomote-community

roomote-community Bot commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

1 issue outstanding. See task

  • docs/technical-evaluations/walgit-repository-bootstrap.md:40 Existing setup-phase events do not record clone, fetch, or checkout/reset timing, so the proposed entry gate cannot be measured from current telemetry.

Reviewed 7cf2410

resumed filesystem snapshot. There is no cross-sandbox Git mirror, bundle
cache, alternates store, LFS bootstrap, or submodule bootstrap.

Repository clone, fetch, and checkout/reset stages already emit durations via

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Existing telemetry does not emit these stage-level durations. recordPhase reaches setup, which records initializeRepositories as one phase, but initializeRepositories and createWorkspaceManager do not pass that recorder into their nested timedStep calls; WorkspaceManager.timed therefore only writes debug logs for clone, fetch, and checkout. The stated entry gate cannot be calculated from existing setup events, so make stage-level event instrumentation a prerequisite rather than claiming this experiment needs no code change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant