ci(release): give the frontend suite its own runner - #291
Merged
Conversation
Two consecutive release dispatches of the same SHA died at the same place: EncoderDialog.axes.test.ts > caps-full: reaches the 4K/60 ceiling… Error: Test timed out in 5000ms. (5544 ms, then 5480 ms) Not a flake, and not the test's fault. It passes 5/5 in isolation, passes in build-check on the same commit, and passes locally 3780/3780. The release gate was simply the only job that ran it on a runner which had already installed ruby+gems, built two .debs for the packaging contracts, and run a full lint/typecheck — the frontend suite took 430 s there against ~298 s in build-check, and the heaviest synchronous render landed ~10% over vitest's 5 s default. build-check has never had this problem because it gives the frontend suite a runner to itself (test-fe). This does the same: the combined `bun run test` is replaced by per-workspace steps, with the frontend suite lifted into its own job that mirrors test-fe. rpc/i18n/backend stay in the contract job — they absorb the shared runner fine. Coverage is identical: `bun run test` chained exactly these four workspaces, and all four still run. The new job is wired into the `needs` of build-ceraui-system, build-debian-package and publish-federation, so it gates publication rather than merely running beside it. No test file, no vitest config and no timeout is touched.
Contributor
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The separate job broke two literals that release-flow.test.sh pins by exact string — `needs: [calculate-version, release-package-contracts]` on the three publishing jobs, and a step named `Run unit tests` — so the contract gate rejected it, correctly. Those contracts exist to stop a publishing job bypassing the release gate, and they cannot express "contains", so extending the needs arrays is not available without editing a test. Ordering achieves the same thing without touching either. What made the frontend suite fail was not sharing a runner as such, it was running after this job's ruby/gem install, two .deb builds and a full lint/typecheck. It now runs immediately after `bun install` — nothing but checkout, Bun and install precede it, which is exactly build-check's test-fe, the job where this suite has never timed out. rpc/i18n/backend stay under the pinned `Run unit tests` step name, now invoked per workspace. Coverage is unchanged: `bun run test` chained exactly these four, and all four still run.
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
1 participant
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.
What
Splits
publish-release.yml's combinedbun run teststep into per-workspacesteps, and lifts the frontend suite into its own job (
release-frontend-tests)that mirrors
build-check.yml'stest-fe.rpc/i18n/backendstay inrelease-package-contracts— they absorb theshared runner without trouble.
Why
Two consecutive release dispatches of the same SHA died at the same place:
— at 5544 ms (run 32449107745)
and 5480 ms (run 32450232432).
Reproducible, ~10% over budget, so not random.
It is not the test. It passes 5/5 in isolation, passes in
build-checkon thesame commit, and passes locally (3780/3780).
It is the job:
build-checktest-fepublish-releasegate (before)bun run --filter frontend testbun run test— rpc + i18n + frontend + backend.debbuilds, full lint/typecheckSeveral specs render a full dialog synchronously against vitest's 5 s default;
on a runner carrying all four suites plus the packaging contracts, the heaviest one
tips over.
build-checkhas never hit this because it gives that suite a runner toitself. This does the same.
How to verify
git diff --stat→ one file,.github/workflows/publish-release.yml. No*.test.ts, novite.config.ts, notestTimeoutanywhere in the diff.testchained exactly@ceraui/rpc→@ceraui/i18n→frontend→backend, and all four still run.needs:ofbuild-ceraui-system,build-debian-packageand
publish-federation, so it gates publication rather than running beside it.backend 4698, lint 0 errors.
EncoderDialog.axes.test.tsrun 5× in isolation:10/10 every time.
Risks
Low, CI-only. Costs one extra runner and one extra
bun install(cached) perrelease; the frontend suite now runs in parallel with the contract gate rather
than after it, so wall-clock should improve slightly. No source, no test, and no
release semantics change.
publish-release.ymlis askip_workflowsentry in theroot
ci-local.manifest.yaml("secrets/OIDC"), so no manifest leaf or digest is owed.