fix(ci): isolate HTTP end-to-end suites and stop the SCIM readiness flake - #8544
Merged
Merged
Conversation
…lake The SCIM step cold-compiles the app under next dev before its first request; readiness took 42-150s on 8 vCPU runners against a fixed 120s deadline, so the slow tail failed. It also ran on both provisioning legs of the integration matrix, which are the PR critical path (~13 min). - Move SCIM and the four search HTTP suites into their own job with its own database, off the integration legs and run once against migrate. - Readiness waits up to 300s, fails fast if the server exits, prints the server log tail, and uploads the server log with the reports. - Factor Bun/Node/cache/install setup into a setup-workspace action.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
next devand waits for/api/health, whose first request cold-compiles the app under Turbopack. Across 40 recent green runs readiness took 42–93s (step totals up to 209s), and today's staging push hit >120s — the fixed 120s deadline failed on the slow tail. The server log was never uploaded, so failures were undiagnosable.End-to-end over real HTTPjob holds SCIM + the four search HTTP suites, on its own Postgres (provisioned viadb:migrate, the production path). Previously SCIM ran on both integration matrix legs, which are the PR critical path (~13 min avg vs 7.6 min Lint and Test); the search suites were gated bymatrix.provision == 'push'. Isolation also matters: the SCIM app boots hosted, which starts background usage replay againstDATABASE_URL.timeout-minutes: 12, fail-fast on server exit, server log tail printed inline, and the fullscim-next.loguploaded with the reports (one artifact instead of five upload steps).setup-workspacecomposite action replaces four copies of Bun/Node/cache/install setup. Cache keys are unchanged (existing sticky disks are reused); the integration legs now also mount the lockfile-keyednode_modulesdisk.Expected effect: ~2 min off each integration leg (the PR critical path), SCIM run once instead of twice, and the readiness flake gone.
ci-score (StarSling) rates the repo 91/100 before and after; its one failing check (
fetch-depth: 0in helm.yml) is a false positive —ctdiffs against the PR base.Test plan
actionlint— no new findingsEnd-to-end over real HTTPjob green; integration legs no longer run SCIM