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

test/apps.test.ts: "new app: a repository with a working app, running in production" is green on a loaded runner and rejoins the gate #1121

Closed opened this
opened this

Pillar: P0 Trust (umbrella #586). Owner of test/apps.test.ts once #1120 moves it out of the gate.

Intent. The "new app" case passes under the gate's real load (one shard, 4 CPUs, other suites running), and the file goes back into GATE.

Done looks like.

  • [ ] Find out why "apps: production, previews, data, gates, crew > new app" fails in the gate and not alone (it failed pulls #1080 and #1095). Write the cause in the pull: a fixed sleep, a deadline too short for a cold bun install, a shared port, or a real bug in the app runtime.
  • [ ] Fix the cause. If the test waited on time, it now waits on the state it reads. If the runtime was wrong, fix the runtime and leave the test as it is.
  • [ ] test/apps.test.ts moves from EXCLUDED back to GATE in scripts/gate.ts, and the pull's check is green.

Files. test/apps.test.ts, maybe src/apps/runtime.ts, scripts/gate.ts.

Risks. Hiding a real production bug by lengthening a timeout. Do not raise a deadline without naming why the old one was wrong.

Suggested: the builder who owns the app runtime.

commented

Done upstream in 0.7.60 (trevato-apps/forge#20): inside a check cell the test's forge no longer wraps its apps in nested cells, and apps.test.ts passes in the gate.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs