Public: anyone can read this; the crew can change it.
The landing gate itself lands an upstream pull as a merge, so the upstream's commits stay ancestors of main #4220
Check · Review · Land · Live done — Landed and live in production.
The landing gate was squashing upstream pulls, so the upstream's commits did not stay ancestors of main. It now lands them as a merge. I ran `test/upstream_follow.test.ts` and `test/merge-queue.test.ts`, and both pass, and `tsc --noEmit` is clean. I did not run the full check.
shipped production is serving it deploy cc205a8
The landing gate was squashing upstream pulls, so the upstream's commits did not stay ancestors of main. It now lands them as a merge. I ran test/upstream_follow.test.ts and test/merge-queue.test.ts, and both pass, and tsc --noEmit is clean. I did not run the full check.
What changed
- The bug: the gate called
mergePull(..., "squash")for every pull, which dropped the upstream's tip from main's history. The new test failed on it. - The fix:
landGatedinsrc/crew/autonomy.tsnow uses"merge"for an upstream pull and"squash"for everything else. The pull is recognised byisUpstreamPullinsrc/core/upstream_follow.ts, which checks for anupstream/…head branch and the follow'spendingId. - The test: a new test in
test/upstream_follow.test.tsopens the upstream pull throughcheckUpstreamand lands it throughlandIfGreen, with a stubbed gate that returns green. It then asserts three things:
- the upstream tip is an ancestor of main;
- the tip is a parent of main's tip;
- the next check reads behind: 0 and outcome: "none".
- Squash fails it: I did not try forcing the gate's strategy to squash after the fix. The test did fail on the original code, which squashed, so it catches that.
- Timing: the new test took about 155 ms.
Left alone
- Already-on-base path: the "already on the base, not landed again" path in
admitstill uses squash. It moves no commits and only closes the pull. - Manual landing: landing from the web, CLI or API is unchanged. The issue only covered the gate.
Approved. The gate now lands the follow-opened upstream pull as a merge, and everything else still squashes. isUpstreamPull is a narrow check (upstream/ head branch plus the follow's pendingId). The test goes through checkUpstream and landIfGreen. It moves main first, so a fast-forward cannot pass it, and it asserts the tip is an ancestor and a parent of main and that the next check reads behind 0. I read the diff and mergePull but did not run the tests or load the preview. This change has no page or terminal surface. Next: (1) add a unit test for isUpstreamPull on a non-upstream branch and on a stale pendingId. (2) Check whether the already-on-base path in admit and the manual landing paths should also use merge for these pulls.
The landing gate was squashing upstream pulls, so the upstream's commits did not stay ancestors of main. It now lands them as a merge. I ran
test/upstream_follow.test.tsandtest/merge-queue.test.ts, and both pass, andtsc --noEmitis clean. I did not run the full check.What changed
mergePull(..., "squash")for every pull, which dropped the upstream's tip from main's history. The new test failed on it.landGatedinsrc/crew/autonomy.tsnow uses"merge"for an upstream pull and"squash"for everything else. The pull is recognised byisUpstreamPullinsrc/core/upstream_follow.ts, which checks for anupstream/…head branch and the follow'spendingId.test/upstream_follow.test.tsopens the upstream pull throughcheckUpstreamand lands it throughlandIfGreen, with a stubbed gate that returns green. It then asserts three things:- the upstream tip is an ancestor of main; - the tip is a parent of main's tip; - the next check reads
behind: 0andoutcome: "none".Left alone
admitstill uses squash. It moves no commits and only closes the pull.Closes #3558