Skip to content

ci: bound the test workflow runtime - #102

Closed
nibzard wants to merge 1 commit into
mainfrom
ci/bound-workflow-runtime
Closed

ci: bound the test workflow runtime#102
nibzard wants to merge 1 commit into
mainfrom
ci/bound-workflow-runtime

Conversation

@nibzard

@nibzard nibzard commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

What changed

Add timeout-minutes: 30 to the existing CI job.

Why

This bounds a stalled runner or runtime well below the six-hour GitHub Actions default. Recent successful jobs finish in roughly 2–10 minutes, so the ceiling leaves ample headroom.

Scope

This is exactly one workflow line. No test command, timeout, Bun.spawnSync helper, retry, or output handling changed.

Validation

  • parsed .github/workflows/ci.yml and confirmed jobs.lint.timeout-minutes is numeric 30
  • git diff --check
  • hosted CI is the final workflow validation before merge

@vercel

vercel Bot commented Jul 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview Jul 30, 2026 7:01pm

Request Review

@nibzard nibzard mentioned this pull request Jul 30, 2026
Merged
@nibzard

nibzard commented Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

Closing this in favor of #103, which is the actual fix.

Diagnosis: CI has been red because a single lifecycle hook times out — the afterAll in tests/e2e/llm-endpoints.test.ts hangs on await server.exited for exactly 120s (setDefaultTimeout(120000)), failing the file on every run since #97. server.kill() only SIGTERMs the direct bunx child, so the next dev / Turbopack grandchildren survive and .exited never resolves.

This PR (timeout-minutes: 30) bounds the GitHub job timeout, but that's the wrong layer: the job already finishes in ~3–6 min, and the failure is Bun's per-hook timeout at 120s. The job is red because bun test exits non-zero, not because it ran out of wall-clock — so no job-level ceiling can turn it green.

#103 fixes it by making the teardown bounded (race .exited against a budget + SIGKILL escalation) and reaping the whole process group. Kept the timeout-minutes hygiene idea out of this since it's unrelated to the failure; happy to reopen as a standalone CI-hygiene change if you still want it.

@nibzard nibzard closed this Jul 31, 2026
nibzard added a commit that referenced this pull request Jul 31, 2026
@nibzard @claude
fix(tests): bound e2e dev-server teardown so afterAll can't hang CI (#…
245148b 
…103)

The `.md suffix end-to-end` suite boots `next dev --turbopack` via `bunx`
and tears it down with `server.kill(); await server.exited`. `kill()` only
SIGTERMs the direct bunx child; the next-server/Turbopack grandchildren
survive, so `.exited` never resolves and afterAll blocks until Bun's
setDefaultTimeout(120000) -- failing the file and turning CI red on every
run since PR #97 (the fragility was latent since the teardown landed in
PR #81). PR #102 (timeout-minutes: 30) does not help: that bounds the
GitHub job timeout, but the job finishes in ~3-6 min and the 120s is
Bun's per-hook timeout, a different layer.

Spawn the dev server detached so it leads its own process group, then tear
the whole group down: SIGTERM, race `.exited` against a 3s budget, escalate
to SIGKILL if it hasn't exited. The awaited exit is now bounded, so teardown
can no longer hang regardless of how the child handles SIGTERM -- and the
full tree is reaped, keeping the port/CPU free for the later Chromium tests.

Validated: bun run typecheck, biome check, and
bun test tests/e2e/llm-endpoints.test.ts (22 pass).

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@nibzard