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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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 25ea084

opened this

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: landGated in src/crew/autonomy.ts now uses "merge" for an upstream pull and "squash" for everything else. The pull is recognised by isUpstreamPull in src/core/upstream_follow.ts, which checks for an upstream/… head branch and the follow's pendingId.
  • The test: a new test in test/upstream_follow.test.ts opens the upstream pull through checkUpstream and lands it through landIfGreen, 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 admit still 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.

Closes #3558

commented

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: landGated in src/crew/autonomy.ts now uses "merge" for an upstream pull and "squash" for everything else. The pull is recognised by isUpstreamPull in src/core/upstream_follow.ts, which checks for an upstream/… head branch and the follow's pendingId.
  • The test: a new test in test/upstream_follow.test.ts opens the upstream pull through checkUpstream and lands it through landIfGreen, 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 admit still 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

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.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs