The changelog calls every merged pull live, because production has no FORGE_REPO #7736

On a deploy with no FORGE_REPO, the changelog now treats the repository that holds the running commit as the forge's own. A merged pull that commit doesn't contain shows as on its way, and /changelog opens on this forge. I ran the changelog, no-release-alarm and terminal-changelog tests (13 pass) and tsc --noEmit, which is clean. I haven't looked at the page on a preview.

What changed (src/release/landings.ts)

• Finding the forge's own repo: a new ownRepo() uses FORGE_REPO when it is set. Otherwise it takes the first public repository with a merged pull whose history contains the running commit, checked with git cat-file -e. The result is remembered per running commit.
• On its way and live: with the forge's own repo known, askLive no longer returns early. A pull moves from on its way to live once production serves a commit that contains its merge commit.
• Opening view: Landings.own now comes back set, so /changelog opens on the forge's own repository, with "Everything" one click away (?repo=all).
• Listed once: mergedRows now drops duplicate repo and pull-number pairs, so each pull is listed once.
• Tests: test/changelog.test.ts has two new tests. One removes FORGE_REPO, checks the third pull shows as on its way, then moves production to the third commit and checks it goes live. The other checks a pull appears once.

What setting FORGE_REPO in production would do: I read the code that uses it and did not set it. It would do more than fix this page:

• src/checks/landing.ts cut() would start cutting a release on every landing to that repository.
• src/checks/gate_last.ts would start keeping the last gate result.
• src/main.ts would start the release-tag reader and the "production behind the newest release" watch.
• src/release/changelog.ts and src/release/gate.ts would start reading that repository.

Inferring the repo from the running commit is read-only and changes none of those.

What I did not do

• Pulls with no merge time: a pull with no merged_at never counts as merged anywhere in the code, so I did not list it. A pull with a merge time but no recorded merge commit was already placed by comparing against the running commit's date.
• Fork ambiguity: if two public repositories both hold the running commit, such as a fork of the forge, the one with the most recent merged pull wins. A deploy that needs a different choice can still set FORGE_REPO.

Try it: open /changelog on a deploy without FORGE_REPO. Pulls merged after the running commit sit under "On its way". They move to live after the next deploy.

Closes #7734

On a deploy with no FORGE_REPO, the changelog now treats the repository that holds the running commit as the forge's own. A merged pull that commit doesn't contain shows as on its way, and /changelog opens on this forge. I ran the changelog, no-release-alarm and terminal-changelog tests (13 pass) and tsc --noEmit, which is clean. I haven't looked at the page on a preview.

What changed (src/release/landings.ts)

• Finding the forge's own repo: a new ownRepo() uses FORGE_REPO when it is set. Otherwise it takes the first public repository with a merged pull whose history contains the running commit, checked with git cat-file -e. The result is remembered per running commit.
• On its way and live: with the forge's own repo known, askLive no longer returns early. A pull moves from on its way to live once production serves a commit that contains its merge commit.
• Opening view: Landings.own now comes back set, so /changelog opens on the forge's own repository, with "Everything" one click away (?repo=all).
• Listed once: mergedRows now drops duplicate repo and pull-number pairs, so each pull is listed once.
• Tests: test/changelog.test.ts has two new tests. One removes FORGE_REPO, checks the third pull shows as on its way, then moves production to the third commit and checks it goes live. The other checks a pull appears once.

What setting FORGE_REPO in production would do: I read the code that uses it and did not set it. It would do more than fix this page:

• src/checks/landing.ts cut() would start cutting a release on every landing to that repository.
• src/checks/gate_last.ts would start keeping the last gate result.
• src/main.ts would start the release-tag reader and the "production behind the newest release" watch.
• src/release/changelog.ts and src/release/gate.ts would start reading that repository.

Inferring the repo from the running commit is read-only and changes none of those.

What I did not do

• Pulls with no merge time: a pull with no merged_at never counts as merged anywhere in the code, so I did not list it. A pull with a merge time but no recorded merge commit was already placed by comparing against the running commit's date.
• Fork ambiguity: if two public repositories both hold the running commit, such as a fork of the forge, the one with the most recent merged pull wins. A deploy that needs a different choice can still set FORGE_REPO.

Try it: open /changelog on a deploy without FORGE_REPO. Pulls merged after the running commit sit under "On its way". They move to live after the next deploy.

I fixed points 1 and 2 and added the tests you asked for; I disagree with the dedupe in point 3 and removed it, and I've left points 4 and 5 for a person. bun x tsc --noEmit is clean and test/changelog.test.ts passes (9 tests). I did not re-run the other suites after these edits.

What changed

• Visibility (1): ownRepo now skips any repository that isn't public, so a private fork or mirror holding the running commit can't become the forge's own. A new test makes the forge repo private, points the running commit at it, and checks its pulls don't appear.
• Cached misses (2): when no repository holds the running commit, that is remembered per commit, so later requests skip the git cat-file calls.
• Fork case (5): a new test has a second public repo, fork, whose only commit is the running one. It checks fork is picked as the forge's own and the other repo's pulls are hidden. That is the one-repo-holds-the-commit case, not a true tie. I did not write a test for two repos holding the same commit. In that case the first repo in the newest-merged-pull order wins, and my earlier description of that case was loose.

Why I removed the dedupe (3) The old query reads one row per pull, because pull.issue_id is the primary key. Each join after that (issue, repo, user) is many-to-one, so no join can duplicate a pull. I could not find any duplicate to fix. A JS filter after LIMIT hides a cause that isn't there and can return fewer rows than the limit, as you said. I took out both the filter and the "listed once" test, since neither can fail. The third done-when item, a pull landed without a merge time, is still not shown, because a pull with no merged_at is not merged anywhere in the code.

Left for a person

• Priority against #6534 and #6611 (4): I can't judge it. The issue is the owner's own, #7734, and nothing in the code ties it to those two. If they want it held, hold the merge. The change is small and isolated to src/release/landings.ts.
• What the preview shows (5): I can't say, because I have not looked at it. The preview has no merged pulls to compare, so I can't state which are on its way and which are live. The behaviour is shown only by the tests, which use FORGE_COMMIT and the database. Someone should open /changelog on the preview once it deploys.

With no FORGE_REPO, /changelog now takes the forge's own repository to be the public one whose history holds the running commit. A merged pull that commit does not contain shows under On its way. It moves to live once production serves a commit that contains it. Nothing that reads FORGE_REPO changes: release cutting (src/checks/landing.ts), the release-tag reader and the gate keep their current behaviour, because the variable stays unset. The type check is clean, and the changelog, no-release alarm and terminal changelog tests pass (17).

Review fixes in this round (src/release/landings.ts)

• The cache of misses runs out: when no repository holds the running commit, that is remembered for one minute (MISS_MS). A miss is never kept while there are no merged public pulls, so a miss at boot does not last until the next deploy. forgetLive() now clears the cache as well.
• A tie has one winner: if a fork also holds the running commit, candidates() checks repositories by most merged pulls, then by name. Before, the repository with the newest merged pull won, so a fork with one recent pull could take over.
• Tests (test/changelog.test.ts):

- A fork whose own pull is the newest is given the forge's history. The forge still wins, and its third pull stays On its way; the old order would have picked the fork. - With every repository private there is a miss. Making them public is picked up on the very next request. - candidates() orders by count, then name. - Kept from the last round: the repository holding the running commit is found, and a private repository is never chosen.

Earlier rounds

• A private repository can no longer be chosen.
• I removed the duplicate filter I had added in JavaScript: the query returns one row per pull (pull.issue_id is its primary key, and every join from it is many-to-one), so there was no duplicate to remove.
• A pull with no merged_at is not counted as merged anywhere in the forge, so it is still not listed.

What the preview shows: I fetched /changelog on the preview of #7736, which runs commit 5c2daa3. It shows "Live: dev", the Everything filter and "Nothing has shipped yet". The preview has no merged pulls in its own data, so it can show neither On its way nor live, and no "This forge" filter. The behaviour is checked only by the tests, which set FORGE_COMMIT against real git repositories. Production will show it on the first merge after this deploys.

Order of work: I am not ranking this against #6534 or #6611. The issue was filed from a real observation of production. The change stays inside the changelog's read path and leaves the pipeline alone, so it does not compete with that work for anything. If the owner wants the pipeline first, hold the merge; nothing waits on it.

🤖 Generated with Claude Code