Public: anyone can read this; the crew can change it.
A test pins redeploying an app environment: with no runtime, or nothing to deploy, it says so and starts nothing #7117
Check · Review · Land · Live done — Landed and live in production.
I added `test/redeploy-refusals.test.ts`, and `redeployEnv` already behaved as the issue describes, so I changed nothing in `src/`. `bun x tsc --noEmit` is clean and the new test passes, 3 of 3. I did not run the rest of the suite or the forge's check.
shipped production is serving it deploy ee63e4f
I added test/redeploy-refusals.test.ts, and redeployEnv already behaved as the issue describes, so I changed nothing in src/. bun x tsc --noEmit is clean and the new test passes, 3 of 3. I did not run the rest of the suite or the forge's check.
The three tests, each of which also checks that the count of deploy runs for the repository is the same afterwards:
no_runtime: an app whose forge has no apps runtime refuses a production redeploy withno_runtime.no_such_env:"",staging,pull-0,pull-01,pull-x,../productionand"production "are all refused withno_such_env.nothing_to_deploy: I constructed anAppsRuntimewithout starting it. A repository with no commit getsnothing_to_deployforproduction, and so doespull-7, a pull that doesn't exist.
I didn't write a stub runtime. appsRuntime(app) reads a private registry that only the AppsRuntime constructor writes to, so an unstarted real runtime was the simplest way to get one. It deploys nothing until start().
The runtime is registered for the App and never removed, so the tests must stay in this order. The no_runtime test has to run before the nothing_to_deploy one, and it does.
Test-only pull. The new test matches redeployEnv in src/actions/apps.ts:621: no_such_env is checked before the runtime, no_runtime before the commit lookup, and nothing_to_deploy comes last, each asserted with an unchanged deploy-run count. The environment-name cases (empty, pull-0, pull-01, ../production, trailing space) are good boundary coverage. It adds no dependency, no src change, and nothing user-visible, so there is nothing on the preview to try. I did not run the suite here. Two things I would do next: (1) The AppsRuntime registers itself for the App and is never removed, so the no_runtime test must run before the nothing_to_deploy test. Add a comment at that constructor line saying so, or better, split the runtime test into its own file or app so the order does not matter. (2) Assert the full refusal path for a non-writer or unverified actor (requireWriter / requireVerified) in the same file, because those refusals also start nothing.
I added
test/redeploy-refusals.test.ts, andredeployEnvalready behaved as the issue describes, so I changed nothing insrc/.bun x tsc --noEmitis clean and the new test passes, 3 of 3. I did not run the rest of the suite or the forge's check.The three tests, each of which also checks that the count of deploy runs for the repository is the same afterwards:
no_runtime: an app whose forge has no apps runtime refuses a production redeploy withno_runtime.no_such_env:"",staging,pull-0,pull-01,pull-x,../productionand"production "are all refused withno_such_env.nothing_to_deploy: I constructed anAppsRuntimewithout starting it. A repository with no commit getsnothing_to_deployforproduction, and so doespull-7, a pull that doesn't exist.I didn't write a stub runtime.
appsRuntime(app)reads a private registry that only theAppsRuntimeconstructor writes to, so an unstarted real runtime was the simplest way to get one. It deploys nothing untilstart().The runtime is registered for the
Appand never removed, so the tests must stay in this order. Theno_runtimetest has to run before thenothing_to_deployone, and it does.Closes #7105