chore: state the smoke-helper and CI wall-clock budgets (#2333)

The five rows #2323 left as "assess", each either stated with its
reasoning and measurement, or shared with a constant that already has one.

- F4/F5: `driveAppFlow` and `connectViaDeepLink` default to
  `BROWSER_TIMEOUTS.ui` / `.roundTrip` instead of restating 30_000 /
  45_000 by hand; values unchanged, now one place to raise. A test in each
  helper pins the defaults.
- F1: `announced-child.mjs` states `DEFAULTS` ({ timeoutMs: 30_000,
  pollMs: 250 }) with the measurement — boot-to-announce of the composable
  test server is 135ms median at load average 15, and a passing start pays
  one poll interval, not the budget.
- F7: `pty.mjs` names `SCRIPT_PROBE_TIMEOUT_MS` (5s; the probe spawns in
  1.3ms median, 3.6ms max under load) and stops folding ETIMEDOUT into
  "no script(1)": a starved probe now fails `smoke:tui` loudly instead of
  turning it into an exit-0 skip.
- G1: every job in `.github/workflows/main.yml` declares
  `timeout-minutes` as a hung-job guard — roughly twice the slowest run
  observed over the last 40 push runs (and the last three releases for the
  publish jobs), rounded up to the next five minutes, with the range stated
  per job.

AGENTS.md's timeout section now points at where these live instead of at
this issue.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-09-13 01:50:33 -04:00
commit 3f7ba20ae6

View file

@ -17,9 +17,22 @@ on:
permissions:
contents: read
# Every job below declares `timeout-minutes` (#2333). It is a HUNG-JOB GUARD,
# not a flake remedy: GitHub runners are not the contended machine the local
# gate runs on, and nothing measured implicates them — so no value here is
# sized for load. The rule, for every job in this file, is roughly TWICE the
# slowest run observed, rounded up to the next five minutes: real headroom for
# a slow runner, and a hang cut off in minutes instead of at GitHub's
# 360-minute default. Each job states the range it was read from; when one
# legitimately outgrows its number, raise it here with the new range.
jobs:
build:
runs-on: ubuntu-latest
# Observed 7.6–11.8 min across the 40 push runs before this landed
# (2026-09-11 → 09-13), all since the coverage split (#2159). A release run
# before that split reached 15.6 min, with the coverage gate still inside
# this job — that shape no longer exists.
timeout-minutes: 25
steps:
- name: Checkout code
@ -150,6 +163,8 @@ jobs:
# time tests out at the 5s default. Separate jobs get separate runners.
coverage:
runs-on: ubuntu-latest
# Observed 5.9–8.5 min across the same 40 push runs as `build`.
timeout-minutes: 20
steps:
- name: Checkout code
@ -195,6 +210,11 @@ jobs:
concurrency:
group: publish-npm
cancel-in-progress: false
# Observed 2.3–2.8 min across the last three releases (2.4.0–2.6.0), of
# which `pack:verify` is about half and the only step that reaches the
# registry. The publish itself is atomic on npm's side, so a cut-off here
# leaves nothing half-published.
timeout-minutes: 10
permissions:
contents: read
# Required for npm provenance (`--provenance` mints a signed attestation
@ -283,6 +303,9 @@ jobs:
if: github.event_name == 'release'
environment: release
needs: [build, coverage]
# Observed 14.5–15.4 min across the last three releases (2.4.0–2.6.0);
# the linux/arm64 half of the build runs under QEMU and is most of it.
timeout-minutes: 35
permissions:
contents: read
packages: write