Public: anyone can read this; the crew can change it.
Terminal: a place to read an app's production deploys, showing what each carries #1901
Check · Review · Land · Live done — Landed and live in production.
The terminal now has a deploys screen that lists an app's production deploys, and each row shows `carries #3 #5` for the pulls that deploy carries. It's pushed. The new tests and the type check pass. One other terminal test, `repo rows wear issue and pull counts` in `test/tui-code.test.ts`, fails; it fails the same way without my change.
shipped production is serving it deploy 6da1e48
The terminal now has a deploys screen that lists an app's production deploys and shows what each one carries (#1762). This push only fixes the failed check.
The check failed because test/tui-deploys.test.ts was in neither GATE nor EXCLUDED in scripts/gate.ts. I added it to GATE, next to the other tui- tests.
scripts/gate.ts now passes locally and the 2 tests in test/tui-deploys.test.ts pass. I did not re-run the type check or the rest of the suite, since the forge runs those on the push.
I chose to gate the test rather than exclude it, because it is new and passes. The tui- tests in EXCLUDED are the older ones, listed as "not yet admitted" under #261.
To try it, open the app's terminal with the command in FORGE_APP_SSH and go to the deploys screen.
The screen is built the right way: it reads through listRepoRuns (so it is gated like the page), the carries join is one grouped read, and it is wired to d in the workspace. One thing blocks it: the README now says something false. Fix: replace the sentence at README.md:393 ("The terminal has no list of deploys yet, so it does not show this.") with how to reach it: in a repository, press d for production deploys, enter opens the log, r refreshes. The task requires the README to say how to use each door. Second, the tests never check that a guest or a user who cannot read a private repo sees nothing. Add a test that opens deploysScreen as a non-reader on a private repo and expects no deploys and no carries. Also assert that a pull-9 preview deploy does not appear by its own marker rather than only checking other.id differs, which is a no-op assertion (test/tui-deploys.test.ts, last line). I did not open the preview, so I cannot confirm it works there.
The README now says how to reach the deploys screen, and the tests cover a non-reader and a real preview marker. I did not add the guest case you asked for. tsc --noEmit is clean and the 3 tests in test/tui-deploys.test.ts pass; I did not run the rest of the suite.
- README: the sentence at line 393 is replaced. It now says to open a repository in the terminal and press
dfor its production deploys (each with what it carries),enterfor the log,rto refresh. - Non-reader test: a new test makes a private repo with a production deploy that carries #77. It opens
deploysScreenas a user who cannot read that repo and expects "No deploys", with no deploy line, noSECRET-MARKERand no#77. Alice, who owns the repo, does see#77, so the test fails if the read gate is removed. - Preview assertion: the preview deploy for pull 9 now carries
PREVIEW-MARKER, and the test asserts that text never appears. The oldother.idcheck is gone. - Guest not added: with no user,
createForgeAppthrows in the dashboard before the deploys screen opens. A guest cannot reach this terminal, so the non-reader case is the one that applies here.
You can try it over ssh with the FORGE_APP_SSH command, then d inside a repository.
The deploys screen reads through listRepoRuns, so it is gated like every other run read. The private-repo test shows a non-reader sees nothing and the owner sees #77. A preview deploy is filtered out, the screen is reachable with d from a repository, the README says how to use it, and the test is in the gate. I read the diff and the code it calls; I did not open the preview or the screenshots. Two things to do next: (1) the test loops over a one-element array, for (const who of [b.value]), which should be a plain call; the local open wrapper in deploys.ts could go the same way. (2) Add a short empty-state hint that r refreshes. The page has no way to list production deploys yet, so the terminal is the only place to see them. A web list would be the next step.
I merged main into this branch and pushed it. The merge had one conflict, in scripts/gate.ts.
Both sides had added a test to the gate's list at the same spot. main added test/tui-access.test.ts, and this branch added test/tui-deploys.test.ts. I kept both.
The type check came back clean. I ran only the two terminal test files (tui-deploys and tui-access), and all 8 tests pass. I did not run the full suite, since the forge runs the whole check on push.
The terminal now has a deploys screen that lists an app's production deploys, and each row shows
carries #3 #5for the pulls that deploy carries. It's pushed. The new tests and the type check pass. One other terminal test,repo rows wear issue and pull countsintest/tui-code.test.ts, fails; it fails the same way without my change.src/tui/screens/deploys.tsreadskind=deploy,env=productionruns throughlistRepoRuns, so they're gated the same as every other run read. It reuses the existing run rows.carriedByRunssupplies the carried pulls in one grouped read, andcarriesTextformats them.enteron a row hands over the run's log address, as the other run lists do.rrefreshes the list.dfor "production deploys". The key only appears for a repo that has a forge record.test/tui-deploys.test.tsdrives the screen. A repo with no deploys shows "No deploys". A production deploy with no issue is listed withcarries #3 #5. Apull-9preview deploy is left out.- Paging past the newest 50 deploys. - Filtering by environment. - Showing a pull's title next to its number.
To try it, open a repo's workspace in the terminal and press
d.🤖 Generated with Claude Code
Closes #1762