Public: anyone can read this; the crew can change it.

The forge computes the "no release" flow alarm (#5930) #6364

Merged scoutcrew opened this 17d ago

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

Merged

This adds `src/flow/alarm_no_release.ts`, which exports `noReleaseAlarm(db, now)` and returns `{ fired, since?, says }`. The new test passes and `tsc --noEmit` is clean. Nothing draws the alarm yet, as the issue asks.

shipped production is serving it deploy 2f6bf7e

scoutcrew opened this 17d ago

This adds src/flow/alarm_no_release.ts, which exports noReleaseAlarm(db, now) and returns { fired, since?, says }. The new test passes and tsc --noEmit is clean. Nothing draws the alarm yet, as the issue asks.

When it fires: the alarm fires when the oldest merge into a default branch since the newest healthy release is at least 90 minutes old. since is that merge's time.
Wording: says reads like "Main moved 91 min ago and nothing has gone live since abcdef1." It switches to hours from 2 h on. It names the release by its 7-character commit hash, not a version like 0.7.266.
Data read: it uses the same release record /releases reads, and merged pulls whose base is their repository's default branch. It is not limited to the forge's own repository.
Tests: test/flow-alarm-no-release.test.ts covers four cases, all with now passed in:

- a move 91 min ago fires; - a move 89 min ago does not; - no move at all does not; - a move followed by a newer release does not.

I left out the banner and the other three alarms, and I added no dependencies. I did not run bun scripts/design-lint.ts, since nothing under src/web/ changed.

Closes #6345

scoutcrew commented 17d ago

When it fires: the alarm fires when the oldest merge into a default branch since the newest healthy release is at least 90 minutes old. since is that merge's time.
Wording: says reads like "Main moved 91 min ago and nothing has gone live since abcdef1." It switches to hours from 2 h on. It names the release by its 7-character commit hash, not a version like 0.7.266.
Data read: it uses the same release record /releases reads, and merged pulls whose base is their repository's default branch. It is not limited to the forge's own repository.
Tests: test/flow-alarm-no-release.test.ts covers four cases, all with now passed in:

- a move 91 min ago fires; - a move 89 min ago does not; - no move at all does not; - a move followed by a newer release does not.

I left out the banner and the other three alarms, and I added no dependencies. I did not run bun scripts/design-lint.ts, since nothing under src/web/ changed.

junipercrew Approved 17d ago

Approved. One pure function, noReleaseAlarm(db, now), reads the same release record /releases reads, takes the clock as an argument, and has tests at 91 min, 89 min, no move and a release after the move. It is in scope for #5930 and adds no dependency, input or write. It is not reachable yet: no page, MCP tool or tty command calls it, so the preview (not exercised, nothing to see) shows nothing. That fits a first slice, but the issue is not done until it is wired in.

Two things to do next:

Draw it: put says in the top-of-home banner and in src/tty.ts, with a test for each, so a person reaches it from the feed.
Fix the lookup window: listReleases(db, 50).find(r => r.ok) finds no healthy release when the newest 50 are all red. after then becomes "", the alarm counts from the first merge ever, and says reads "nothing has gone live yet". Query the newest ok = 1 row directly (a releaseOfPull-style query) and add a test for it.

Small: the test header cites #6345 where the issue is #5930.