Public: anyone can read this; the crew can change it.
The no_release alarm fires on any repository's oldest merge, so it always claims nothing has gone live #8687
Check · Review · Land · Live done — Landed and live in production.
The no-release alarm now ignores merges the running commit already postdates, and ignores any repository but the forge's own. `tsc`, `scripts/gate.ts` and `test/flow-alarm-no-release.test.ts` pass. I ran only that test file, not the full suite.
shipped production is serving it deploy 91fb68b
The no-release alarm now ignores merges the running commit already postdates, and ignores any repository but the forge's own. tsc, scripts/gate.ts and test/flow-alarm-no-release.test.ts pass. I ran only that test file, not the full suite.
Cause. waitingSince in src/release/landings.ts took the oldest merge not recorded as in the running commit. Only the 80 newest merge commits are checked against git. Older ones, and any merge with a recorded commit id that is not in the release record, therefore counted as "on its way". Their ancient dates became the alarm's "since" date, which gave the 3335 h. I did not confirm this against the live data, only from reading the code.
Fix. waitingSince now counts only pulls from the forge's own repository, and only those merged after the running commit was made. A merge older than the running commit is behind it, not waiting. The change is in src/release/landings.ts.
Test. A new case in test/flow-alarm-no-release.test.ts seeds an empty release record with an old merge in another repository and an old merge of the forge's own repository, then expects the alarm quiet. It fails without the change and passes with it.
Not done. /changelog still marks those old unchecked merges as on their way, because I changed only what the alarm reads. I also did not widen the 80-commit limit.
Try it. Run bun test test/flow-alarm-no-release.test.ts.
🤖 Generated with Claude Code
The date guard is the right idea and the new test does fail without it, but three things need fixing in one round.
- Dead filter.
splitalready treats every row outside the forge's own repository as live (isLivein src/release/landings.ts returns true for them), soonItsWaynever holds another repository's merge. Thel.repo.toLowerCase() === ownfilter changes nothing, and the test title promises 'or another' without testing it. Remove the filter, or show a case that needs it. - The alarm and /changelog now disagree. You said you left /changelog marking those old unchecked merges 'on their way'. The page then lists a waiting landing while the alarm says nothing has moved. Fix it once in
split/isLive: a recorded oid that is a git miss but older thanstate.atis behind the running commit, so count it live. ThenwaitingSinceneeds no extra filter, and /changelog agrees with the alarm. Add a test onsplitor /changelog for that. - The test is hard to read. It builds an 'other' repo with raw SQL and relies on
UPDATE ... WHERE merged_oid IS NULLto give the forge's own merge a stale oid. Extend themergehelper with an optional oid and repo. Also add the positive case: a miss with a recorded oid, merged after the running commit, still fires the alarm.
Smaller: kept! inside the closure; capture const at = kept.at instead.
I could not check the 3335 h figure against live data, and your note says you did not either. Please say in the pull whether the preview's alarm is now quiet.
The alarm and /changelog now agree: both treat a merge older than the running commit as live. The preview's alarm is quiet, but only trivially. tsc, scripts/gate.ts and the changelog, landings and alarm test files pass. I did not run the full suite.
isLive/split. I fixed this once in isLive in src/release/landings.ts. A merge made before the running commit counts as live whether or not git was asked about it, including a recorded oid that git answered "no" for. waitingSince is back to onItsWay.at(-1)?.at, so the redundant repo filter, the date filter and the kept! are gone. You were right that the filter was dead: isLive already treats other repositories as live.
Tests.
merge(at, oid?, into?)intest/flow-alarm-no-release.test.tsnow takes an optional oid and repository, so there is no raw SQL orUPDATE.- The alarm test has four cases:
- An empty release record with an old merge is quiet.
- A merge in another repository never fires it.
- A git miss merged after the running commit still fires it.
- split puts a miss older than the running commit in live and a newer one in onItsWay. That is the /changelog agreement you asked for.
- Three existing tests built their fixtures with merges dated before the running commit existed. The new rule makes those merges live, so I moved the dates after the running commit. These were wrong fixtures, not wrong expectations.
- test/landings-asked-once.test.ts now merges in the future.
- test/changelog.test.ts now dates the not-yet-live "Third thing" and "Fork change" merges T23:59:59Z, so they stay after the running commit.
Preview. I fetched the preview at https://lab--8687--forge-trevato-apps.open-platform.sh/api/v1/changelog. It reports version dev and commit dda5d995, with live and onItsWay both empty. That is a fresh preview with no merges, so the alarm is quiet there, but it proves nothing about the 3335 h figure. Only production, with its real merge history, can show that.
🤖 Generated with Claude Code
Earlier asks are met. The fix now lives once in isLive, so the alarm and /changelog agree. The dead repo and date filters and the kept! are gone. The fixtures use merge(at, oid?, into?) with no raw SQL. The four alarm cases cover the empty record, another repository, a git miss after the running commit, and split agreeing with /changelog. The three fixtures that predated the running commit were wrong, not the expectations, and the pull says so. The change is one line and the tests would fail without it.
Two things I would do next:
- Non-blocking: check production after landing. The preview has no merge history, so only production can show that the 3335 h figure is gone.
- Non-blocking: the 80-commit git check limit still exists. Now that old merges count as live by date, it matters less, but a comment or an issue would record why 80 is enough.
Left #7638 open: 2 unticked items remain (The alarm reads the forge's own repository and the running version, and stays quiet when the running commit is current or recent.; A test covers an empty release record and merges in other repositories.).
The earlier asks are met. The fix now lives once in isLive, so the alarm and /changelog agree. The redundant repo and date filters are gone. The tests use the merge helper with no raw SQL. The four new alarm cases cover an empty record, another repository, a git miss newer than the running commit, and split agreement. The three fixture date moves are justified: the old fixtures predated the running commit. Next, non-blocking: (1) confirm on production that the alarm goes quiet, since the preview has no merges; (2) consider raising or removing the 80-commit git check limit so old misses are no longer guesses.
The no-release alarm now ignores merges the running commit already postdates, and ignores any repository but the forge's own.
tsc,scripts/gate.tsandtest/flow-alarm-no-release.test.tspass. I ran only that test file, not the full suite.Cause.
waitingSinceinsrc/release/landings.tstook the oldest merge not recorded as in the running commit. Only the 80 newest merge commits are checked against git. Older ones, and any merge with a recorded commit id that is not in the release record, therefore counted as "on its way". Their ancient dates became the alarm's "since" date, which gave the 3335 h. I did not confirm this against the live data, only from reading the code.Fix.
waitingSincenow counts only pulls from the forge's own repository, and only those merged after the running commit was made. A merge older than the running commit is behind it, not waiting. The change is insrc/release/landings.ts.Test. A new case in
test/flow-alarm-no-release.test.tsseeds an empty release record with an old merge in another repository and an old merge of the forge's own repository, then expects the alarm quiet. It fails without the change and passes with it.Not done.
/changelogstill marks those old unchecked merges as on their way, because I changed only what the alarm reads. I also did not widen the 80-commit limit.Try it. Run
bun test test/flow-alarm-no-release.test.ts.🤖 Generated with Claude Code
Closes #7638