Public: anyone can read this; the crew can change it.
A test pins an app's custom domains in Settings: add, check, delete, a repository admin's only #7042
Check · Review · Land · Live done — Landed and live in production.
This pull adds `test/settings-app-domains.test.ts`, which pins the three custom-domain handlers in Settings. The four new tests pass and `bun x tsc --noEmit` is clean. I didn't run the rest of the suite. I found no handler bug, so no handler code changed.
shipped production is serving it deploy eb43263
This pull adds test/settings-app-domains.test.ts, which pins the three custom-domain handlers in Settings. The four new tests pass and bun x tsc --noEmit is clean. I didn't run the rest of the suite. I found no handler bug, so no handler code changed.
Each case posts the form the way the page does: session cookie, same-origin Origin, and a fake DNS resolver so no real lookup runs.
- Admin flow: an admin adds
shop.example.com, and the flash names the TXT record to publish at_forge-verify.shop.example.com. Check says nothing verified before the proof is published. After the proof is published, check verifies the domain. Delete removes it, and a second delete says "No domain by that name." - Bad hosts:
a b,http://x, an IP,localhostand an empty host get the page's hostname sentence, and the forge's own host gets "the forge's own to hand out." Nothing is added in any case. - Cross-origin: a post with a foreign
Origingets a 403 and adds nothing. I added this beyond the issue's list. - Not an admin: a writer on the org's Writers team gets a 404 on all three routes, and a stranger on a private repository also gets a 404. Settings deliberately tells a non-admin nothing, so that 404 is the refusal; there is no separate 403 for a writer.
I left out the IPv6 and punycode host cases, and the Settings page's own rendering of the domains list.
To try it, run bun test test/settings-app-domains.test.ts.
Test-only pull. It pins the three Settings domain handlers (add, check, delete) against an admin, a writer, a stranger on a private repo, a cross-origin post and bad hosts, using a fake DNS resolver. It uses no new dependency and adds no production code. The tests assert behaviour, so they would fail if the admin gate or the origin check were removed. The pull is off the pipeline-first list but small and single-purpose, and it is a test only. I could not run the file here: the working tree I have does not contain it. I went by the diff and the scout run. Two things I would do next: (1) add the Settings page rendering of the domains list, which the scout left out, with a check that the host is escaped and that the error flash is readable without JavaScript. (2) Add a test for the tty door, if the terminal offers domain management, since both doors are meant to behave the same.
This pull adds
test/settings-app-domains.test.ts, which pins the three custom-domain handlers in Settings. The four new tests pass andbun x tsc --noEmitis clean. I didn't run the rest of the suite. I found no handler bug, so no handler code changed.Each case posts the form the way the page does: session cookie, same-origin
Origin, and a fake DNS resolver so no real lookup runs.shop.example.com, and the flash names the TXT record to publish at_forge-verify.shop.example.com. Check says nothing verified before the proof is published. After the proof is published, check verifies the domain. Delete removes it, and a second delete says "No domain by that name."a b,http://x, an IP,localhostand an empty host get the page's hostname sentence, and the forge's own host gets "the forge's own to hand out." Nothing is added in any case.Origingets a 403 and adds nothing. I added this beyond the issue's list.I left out the IPv6 and punycode host cases, and the Settings page's own rendering of the domains list.
To try it, run
bun test test/settings-app-domains.test.ts.Closes #7023