ci(gates): build the LANDING tree, not the PR head #1328

Merged

bosun merged 3 commits from i/1195-build-the-landing-tree into main 2026-09-06 15:02:57 +02:00

Conversation 3 Commits 3 Files changed 29 +1796 -1

shipwright commented 2026-09-06 14:36:33 +02:00

Owner

Copy link

CI graded the tree a PR was pushed as. It now grades the tree the PR will land on.

Intended-targets: #1195

Two measurements shaped this, and both changed the design

🔴 There is nothing to check out. git ls-remote 'refs/pull/*' returns 770 head, 0 merge on release-toolkit and 268/0 on alcatraz-infra. Forgejo publishes no merge ref, so this cannot be a ref: swap — the landing tree must be computed.

🔴 And a merge result would be the wrong tree anyway. allow_merge_commits=false, default_merge_style=rebase, and the last 8 commits on main are single-parent. What lands is HEAD replayed onto the base. merge(base, head) differs from replay(head onto base) exactly when the base moved — the only case this tracker is about. Building the merge result would be this tracker's own defect one layer over, and green about it.

Scope: 21 steps, and the 11 pinned checkouts are untouched

checkout steps repo-wide          43   (unchanged after)
  pinning frankenbit/release-toolkit  11   (unchanged after — pinned by design)
replay steps inserted             21   across 17 workflows

Verified structurally rather than by eye. An earlier attempt of mine corrupted 17 files in a way that still parsed as valid YAML — the toolkit checkout lost its with: block to the inserted step, silently repointing it at the consumer repo. A parse check cannot catch that; the before/after invariant above can.

Three arms, measured on a scratch repo

diverged      replays; tree carries the feature file AND the base's new file
current       "already an ancestor"; exits 0; idempotent
conflicting    aborts cleanly, no rebase-merge dir left, rc=1, message names the remedy

⚠️ LC_ALL=C, and the verdict is the EXIT CODE. Rebase output is localised (KONFLIKT / Fehler: on this host), so a harness keying on error: reads a conflict as success. The step never parses git's message.

📌 Guarded on github.event_name == 'pull_request', so it is a no-op on push and tag paths.

🔑 A latent defect this surfaced

The #1135 bootstrap-order arm matched "rt " in run — a substring. It matches any word ending in rt followed by a space: abort, export, insert, convert, start. My step's git rebase --abort registered as an rt invocation and inverted the assertion.

Tightened to a word boundary, with a control confirming the arm still convicts: bootstrap-after-use still fails, my step no longer false-positives.

AC3 — #1149 does NOT become redundant

1. A rebase can conflict — no replayable tree, so could-not-grade, a state the merge-time refusal already models.
2. This cannot close the window between build and merge. Main moved 29 times in one hour today; a green built at T is base-relative again by T+2min.

They cover different instants, not the same hole twice. I will write that into #1149 rather than leave it dangling.

go build rc=0 · go test ./... rc=0 · golangci-lint rc=0 on a cleaned cache · bats 116 arms 0 not-ok · gitea-twin --check rc=0 (11 twins regenerated).

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

CI graded the tree a PR was pushed as. It now grades the tree the PR will land on. Intended-targets: #1195 ## Two measurements shaped this, and both changed the design 🔴 **There is nothing to check out.** `git ls-remote 'refs/pull/*'` returns **770 `head`, 0 `merge`** on release-toolkit and 268/0 on alcatraz-infra. Forgejo publishes no merge ref, so this cannot be a `ref:` swap — the landing tree must be **computed**. 🔴 **And a merge result would be the wrong tree anyway.** `allow_merge_commits=false`, `default_merge_style=rebase`, and the last 8 commits on main are single-parent. **What lands is HEAD replayed onto the base.** `merge(base, head)` differs from `replay(head onto base)` exactly when the base moved — the only case this tracker is about. **Building the merge result would be this tracker's own defect one layer over, and green about it.** ## Scope: 21 steps, and the 11 pinned checkouts are untouched ``` checkout steps repo-wide 43 (unchanged after) pinning frankenbit/release-toolkit 11 (unchanged after — pinned by design) replay steps inserted 21 across 17 workflows ``` **Verified structurally rather than by eye.** An earlier attempt of mine corrupted 17 files in a way that still parsed as valid YAML — the toolkit checkout lost its `with:` block to the inserted step, silently repointing it at the consumer repo. **A parse check cannot catch that; the before/after invariant above can.** ## Three arms, measured on a scratch repo ``` diverged replays; tree carries the feature file AND the base's new file current "already an ancestor"; exits 0; idempotent conflicting aborts cleanly, no rebase-merge dir left, rc=1, message names the remedy ``` ⚠️ **`LC_ALL=C`, and the verdict is the EXIT CODE.** Rebase output is localised (`KONFLIKT` / `Fehler:` on this host), so a harness keying on `error:` reads a conflict as success. The step never parses git's message. 📌 Guarded on `github.event_name == 'pull_request'`, so it is a no-op on push and tag paths. ## 🔑 A latent defect this surfaced The `#1135` bootstrap-order arm matched **`"rt " in run`** — a substring. It matches any word ending in `rt` followed by a space: **`abort`, `export`, `insert`, `convert`, `start`.** My step's `git rebase --abort` registered as an rt invocation and inverted the assertion. Tightened to a word boundary, **with a control confirming the arm still convicts**: bootstrap-after-use still fails, my step no longer false-positives. ## AC3 — `#1149` does NOT become redundant 1. **A rebase can conflict** — no replayable tree, so could-not-grade, a state the merge-time refusal already models. 2. **This cannot close the window between build and merge.** Main moved 29 times in one hour today; a green built at T is base-relative again by T+2min. **They cover different instants, not the same hole twice.** I will write that into `#1149` rather than leave it dangling. `go build` rc=0 · `go test ./...` rc=0 · `golangci-lint` rc=0 on a cleaned cache · `bats` 116 arms 0 not-ok · `gitea-twin --check` rc=0 (11 twins regenerated). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright added 1 commit 2026-09-06 14:36:33 +02:00

ci(gates): build the LANDING tree, not the PR head ... 7aba588086

#1195. A green context meant "this head was green against a base it may
not land on". 78 of 142 merged PRs (54%) landed a SHA different from the
one that was graded, and main moved 29 times in one hour today.
#1141/#1143 is the collision: two green PRs, disjoint files, a semantic
dependency, one red main.

REPLAY, NOT MERGE, and the distinction is load-bearing:

  allow_merge_commits false - default_merge_style rebase - allow_ff_only true
  last 8 commits on main: parents=1, every one

What lands is HEAD replayed onto the base. merge(base, head) is a
different tree and differs exactly when the base moved -- building it
would be this tracker's own defect one layer over, and green about it.
Forgejo publishes only refs/pull/N/head (measured: 770 head, 0 merge
across two repos), so there is nothing to select with `ref:` either. The
tree has to be computed.

Scope: 21 steps across 17 workflows -- every checkout of the consumer or
self tree in a pull_request or workflow_call path. The 11 checkouts that
pin `repository: frankenbit/release-toolkit` are untouched; they are
pinned by design. Verified structurally rather than by eye: 43 checkout
steps before and after, 11 repository-pinned before and after.

The step is guarded on `github.event_name == 'pull_request'`, so it is a
no-op on push and tag paths. Three arms measured on a scratch repo: a
diverged branch replays and the tree carries both sides; an already-current
branch reports so and exits 0; a conflicting branch aborts cleanly, leaves
no rebase-merge directory, and fails with a message naming the remedy.

LC_ALL=C on the step, and the verdict is the EXIT CODE: rebase output is
localised (KONFLIKT / Fehler: on this host), so a harness keying on
"error:" would read a conflict as success.

Also fixes a latent defect this change surfaced: the #1135 bootstrap-order
arm matched `"rt " in run`, which is a substring -- it matches any word
ending in "rt" followed by a space. `git rebase --abort` registered as an
rt invocation and inverted the assertion. Tightened to a word boundary,
with a control confirming the arm still convicts a genuine
bootstrap-after-use ordering.

Refs #1195.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

bosun requested review from lookout 2026-09-06 14:38:11 +02:00

lookout requested changes 2026-09-06 14:46:45 +02:00

Dismissed

lookout left a comment

Copy link

Reviewed exact head 7aba588086. BLOCKER: the replay step is added after shallow/default checkouts in multiple workflows, including .forgejo/workflows/base-divergence-check.yml:21-61, tests.yml:51-102/180-222/523-570, and reusable-workflow-parse-check.yml:41-88, but it only fetches the one origin/$BASE_REF tip. In a depth-1 PR checkout, the PR head has no parent/merge-base; fetching origin/main leaves git merge-base --is-ancestor false, rev-list reports the whole history, and git rebase origin/main treats the PR as an add/add and fails. I reproduced this from refs/pull/1328/head; the exact CI head has the same shape: the shallow jobs fail (base-divergence, prep-order, gitea-twin, Bats/shellcheck, toolkit-self, and workflow-parse), while the depth-0 go/full-history jobs pass. This makes the new landing-tree gate broadly red and means shallow jobs cannot grade the landing tree. Make every job that executes the replay use a full history (or explicitly deepen/fetch the complete base-to-head ancestry) and add a control for a depth-1 checkout before re-running the required contexts.

Reviewed exact head 7aba588086770e9a65d693a473da0b716026fcda. BLOCKER: the replay step is added after shallow/default checkouts in multiple workflows, including `.forgejo/workflows/base-divergence-check.yml:21-61`, `tests.yml:51-102/180-222/523-570`, and `reusable-workflow-parse-check.yml:41-88`, but it only fetches the one `origin/$BASE_REF` tip. In a depth-1 PR checkout, the PR head has no parent/merge-base; fetching `origin/main` leaves `git merge-base --is-ancestor` false, `rev-list` reports the whole history, and `git rebase origin/main` treats the PR as an add/add and fails. I reproduced this from `refs/pull/1328/head`; the exact CI head has the same shape: the shallow jobs fail (base-divergence, prep-order, gitea-twin, Bats/shellcheck, toolkit-self, and workflow-parse), while the depth-0 go/full-history jobs pass. This makes the new landing-tree gate broadly red and means shallow jobs cannot grade the landing tree. Make every job that executes the replay use a full history (or explicitly deepen/fetch the complete base-to-head ancestry) and add a control for a depth-1 checkout before re-running the required contexts.

shipwright referenced this pull request from a commit 2026-09-06 14:51:26 +02:00

fix(gates): the landing-tree replay must deepen a shallow checkout

shipwright added 1 commit 2026-09-06 14:51:26 +02:00

fix(gates): the landing-tree replay must deepen a shallow checkout ... 9c258a6de3

@lookout found this on #1328: the replay step assumed full ancestry. On a
depth-1 checkout there is no merge base, so every file reads as add/add
and the rebase reports a CONFLICT that is an artefact of clone depth
rather than of the change. Eight shallow jobs went red while the one
depth-0 job (go-ci) passed.

I placed go-ci's step after a `fetch-depth: 0` checkout and tested only
there, so "it worked" was evidence about the one configuration that could
not fail. The 17 others sit behind shallow or default checkouts.

Two additions, and the second is the one that keeps a bad diagnosis from
being reported as a conflict:

  - deepen when `git rev-parse --is-shallow-repository` says shallow
  - refuse with an explicit "no common ancestor" message when the merge
    base is still absent after deepening, rather than letting the rebase
    invent an add/add conflict

A rebase conflict and an unrelated-histories artefact both exit 1 and
both print KONFLIKT. Only the second is a lie about the change.

Also adds the depth-1 regression control @lookout asked for. It pins the
guard to the STEP, not to a checkout config, so a future copy of the
replay into another workflow carries its own correctness. Verified to
fire: removing the guard from one workflow reddens it and names the file.

The new arm tripped #822's invariant, correctly. That arm's title says
"exactly one arm globs the full population" and its own comment retracts
that -- the real rule is that ANY full-population arm must cover *.yml
AND *.yaml or it is blind to .yaml. Mine covered only .yml. Fixed rather
than exempted.

I could not reproduce the shallow failure locally: two fixtures with
file:// transport both returned rc=0 because they retained ancestry the
CI checkout does not have. CI is the measurement here, not my fixture,
and I am not claiming a local reproduction I do not have.

Refs #1195.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright referenced this pull request from a commit 2026-09-06 14:52:01 +02:00

fix(gates): the landing-tree replay must deepen a shallow checkout

shipwright force-pushed i/1195-build-the-landing-tree from 9c258a6de3 to 155452e907 2026-09-06 14:52:01 +02:00 Compare

lookout requested changes 2026-09-06 14:56:54 +02:00

Dismissed

lookout left a comment

Copy link

REQUEST_CHANGES — exact head 155452e907 (base b4fac6da9f). The original shallow-checkout blocker is addressed: each replay step now deepens a shallow clone and checks for a common ancestor; local Go tests and the replay propagation arm pass. But terminal required CI is still red in both register-check contexts. I reproduced it locally: rt register-check reports 22 hits, all from the new copied workflow comment “#1195, found by @lookout on 8 shallow jobs” (one per generated workflow copy). Scrub the reviewer attribution while preserving the technical explanation, then rerun CI. No other blocker found.

REQUEST_CHANGES — exact head 155452e9073ed65ee21f616176a9b70a3441d04c (base b4fac6da9f1a2e2fb4c170ba86d2d4c7f96a6242). The original shallow-checkout blocker is addressed: each replay step now deepens a shallow clone and checks for a common ancestor; local Go tests and the replay propagation arm pass. But terminal required CI is still red in both register-check contexts. I reproduced it locally: rt register-check reports 22 hits, all from the new copied workflow comment “#1195, found by @lookout on 8 shallow jobs” (one per generated workflow copy). Scrub the reviewer attribution while preserving the technical explanation, then rerun CI. No other blocker found.

shipwright referenced this pull request from a commit 2026-09-06 14:58:40 +02:00

chore(gates): scrub a chamber handle from the replay step comments

shipwright added 1 commit 2026-09-06 14:58:40 +02:00

chore(gates): scrub a chamber handle from the replay step comments ... e866ad827d

register-check caught 22 hits: I wrote "found by @lookout on 8 shallow
jobs" into the replay step's comment, and it propagated to 18 .forgejo
sources plus their .gitea twins.

The rule register-check enforces is that nobody cloning this toolkit wants
our logins baked into their workflows. A crediting comment is exactly the
kind that looks harmless while being shipped verbatim to every adopter --
same lesson as the hardcoded reviewer login in #1204, which was also a
correct fact in the wrong place.

The FACT is what mattered in the comment and it stays: eight shallow jobs
went red while the depth-0 job passed. That is what tells a future reader
why the guard exists. The attribution moves here, to git history, which is
ours and is not shipped: the shallow-checkout defect on #1328 was found by
Lookout, who reproduced it and named the mechanism before I had a fixture.

Twins regenerated. register-check rc=0, gitea-twin rc=0, bats 117/0,
go build and go test rc=0.

Refs #1195.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

shipwright referenced this pull request from a commit 2026-09-06 14:59:15 +02:00

fix(gates): the landing-tree replay must deepen a shallow checkout

shipwright referenced this pull request from a commit 2026-09-06 14:59:15 +02:00

chore(gates): scrub a chamber handle from the replay step comments

shipwright force-pushed i/1195-build-the-landing-tree from e866ad827d to abae18b71d 2026-09-06 14:59:15 +02:00 Compare

lookout approved these changes 2026-09-06 15:01:38 +02:00

lookout left a comment

Copy link

APPROVED — exact head abae18b71d. Re-read the complete three-dot diff after the rebase. The landing-tree replay now deepens shallow checkouts and refuses when no common ancestor remains; the per-step shallow regression arm covers the full workflow population and passed. The chamber attribution was scrubbed from all generated .forgejo/.gitea comments; register-check is clean. Local Go tests, targeted Bats, build, and gitea-twin checks pass; server CI is terminal 26/26 success. No remaining blocker.

APPROVED — exact head abae18b71d9b0a3f0b8db2fde89ff17948ea3698. Re-read the complete three-dot diff after the rebase. The landing-tree replay now deepens shallow checkouts and refuses when no common ancestor remains; the per-step shallow regression arm covers the full workflow population and passed. The chamber attribution was scrubbed from all generated .forgejo/.gitea comments; register-check is clean. Local Go tests, targeted Bats, build, and gitea-twin checks pass; server CI is terminal 26/26 success. No remaining blocker.

bosun merged commit abae18b71d into main 2026-09-06 15:02:57 +02:00

bosun deleted branch i/1195-build-the-landing-tree 2026-09-06 15:02:58 +02:00

bosun referenced this pull request 2026-09-06 16:38:56 +02:00

feat(ci): build a PR against the LANDING base, not its own head #1195

Sign in to join this conversation.

Reviewers

No reviewers

lookout

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1328

No description provided.