Skip to content

docs: secondary-repo work-branch materialization [doc-updater] #3453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jwbron merged 2 commits into from
Jul 2, 2026
Merged

docs: secondary-repo work-branch materialization [doc-updater] #3453

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
84a331f
Document secondary-repo work-branch materialization (#3393)
jwbron Jul 2, 2026
66fc1d1
Clarify work-branch materialization doc per review
egg-reviewer[bot] Jul 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions docs/architecture/slice-dag.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -773,6 +773,22 @@ with no slices gets neither. A single-repo pipeline gets exactly one work branch
and one context PR, byte-equivalent to the pre-multi-repo path. Context-PR
bodies cross-reference their sibling context PRs in the pipeline.

For a multi-repo pipeline (`len(repos) > 1`), `kubernetes_spawner` asks the
gateway to materialize each repo's work branch on its own remote right after
the worktree is created (`create_worktrees(..., push_branches=True)`, wired
through the gateway's `_materialize_work_branch_on_remote`, #3393 slice-7):
the fresh worktree HEAD is pushed to
`refs/heads/{assigned_branch or work-branch}`. The push runs for every repo in
the list — including the primary, where it's a no-op the orchestrator's
existing push path already covered. It is best-effort, non-forced, and
idempotent: a branch already present on the remote — even one whose tip has
diverged — is treated as already materialized (a non-fast-forward rejection is
swallowed rather than force-pushed, so the primary's contract-init commit is
never clobbered). This guarantees a secondary repo's context/slice PR always
has a head branch to open against instead of soft-failing on a missing one.
Single-repo pipelines pass `push_branches=False` and stay byte-identical to
the pre-#3393 path.

### Per-slice PR routing

`GatewayClient.create_slice_pr` is repo-parameterized; the run loop passes each
Expand Down
Loading