fix(ci): unmask release build failures and fix the ui:lint synckit crash - #46
Merged
Conversation
Both release workflows set `continue-on-error: true` on the matrix build
job, which forces every row's conclusion to success even when the build
dies. cli@1.1.0 shipped that way: the two Windows rows failed on an
unexpanded `${PLATFORM}`, published nothing, and the run still reported a
green check, so the release sat with 4 of its 6 assets for hours.
Drop it, and add `fail-fast: false` in the same move. fail-fast is what
keeps the rows independent once continue-on-error is gone -- without it
the first failing target would cancel the healthy rows still in flight,
including the ~20 minute darwin-x64 build, and strand the release
half-published. The result is the behaviour that was intended all along:
every platform still gets its chance to build, and a platform that cannot
produce an asset now fails the run that publishes it.
`ui:lint` fails intermittently on main with Internal error: Atomics.wait() failed: timed-out Rule: "better-tailwindcss/enforce-canonical-classes" eslint-plugin-better-tailwindcss resolves the Tailwind design system in a synckit worker and blocks on Atomics.wait(). Building that context for packages/ui/src/styles/index.css is a cold, CPU-bound compile, and the plugin caps the wait at 30s. On a 4-vCPU runner with several lint targets in flight that ceiling gets crossed and ESLint aborts outright -- a hard crash, not a lint finding, so `task lint` fails and --nxBail skips the rest of the run. 4.3.2 passes `timeout: 30000` explicitly to createSyncFn, which overrides synckit's own default, so SYNCKIT_TIMEOUT was silently ignored and there was no way to raise it. 4.4.0 is the first release that reads the env var; its recommended preset is otherwise unchanged (the two rules it adds are both `recommended: false`), so the effective rule set does not move. Raise the ceiling to 120s for lint targets. It is a deadline, not a budget: a healthy run never waits any longer than it does today.
Clears every remaining actionlint finding across .github. The benchmark PR comment job guarded on `github.com.event_name == 'pull_request'`. There is no `com` property on the github context, so the expression evaluates to null, never equals 'pull_request', and the job has silently never run. Use `github.event_name`. sql.yml still pinned actions/checkout@v3, whose runner GitHub no longer supports; every other workflow is already on v4. The three composite actions carried empty `description` fields, which actionlint reports against each workflow that uses them.
Repairing the `github.event_name` guard makes this job execute for the first time. The workflow declares no `permissions:` block and the repository default for GITHUB_TOKEN is read-only, so the job would have run straight into a 403 on issues.createComment -- trading a silently skipped job for a visibly failing one. Grant `pull-requests: write` at the job level, which is all it needs: its only step reads and writes PR comments, and it never checks out the repo.
Contributor
📊 Performance ComparisonGenerated on 2026-08-09 13:55:08 UTC Detailed Results
📈 Summary Statistics
✅ Stable Performance: All benchmarks within acceptable range |
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.
Fixes the two failing Windows release jobs from run 31281026143, the reason nobody noticed them, and the flake that has been reddening
main.1. Release runs reported green while builds failed
Both release workflows set
continue-on-error: trueon the matrix build job, forcing every row's conclusion to success even when the build died.cli@1.1.0shipped that way — the two Windows rows failed on an unexpanded${PLATFORM}, published nothing, and the run still showed a green check.Dropped it, and added
fail-fast: falsein the same move. That pairing matters:fail-fast: falseis what keeps rows independent oncecontinue-on-erroris gone. Without it the first failing target would cancel the healthy rows still in flight — including the ~20 minutedarwin-x64build — and strand the release half-published.Applied to
release-electron-builder.yamltoo, which had the identical latent bug.The underlying build bug is already fixed (
454fd20f) and shipped ascli@1.1.1. Verified by downloading every published asset:Correct architectures, not mislabeled x64 copies. This PR fixes the reporting, so the next partial release fails loudly instead of publishing quietly.
2.
ui:lintcrashing on mainNot a lint finding — a hard ESLint abort:
eslint-plugin-better-tailwindcssresolves the Tailwind design system in a synckit worker and blocks onAtomics.wait(). Building that context forpackages/ui/src/styles/index.cssis a cold, CPU-bound compile capped at 30s. On a 4-vCPU runner with several lint targets in flight, that ceiling gets crossed and ESLint aborts, failingtask lint(and--nxBailskips the rest of the run).4.3.2 passed
timeout: 30000explicitly tocreateSyncFn, which overrides synckit's own default — soSYNCKIT_TIMEOUTwas silently ignored and there was no way to raise it. 4.4.0 is the first release that reads the env var. Its recommended preset is otherwise unchanged: the two rules it adds are bothrecommended: false, so the effective rule set does not move.Verified the plumbing by falsification — forcing
SYNCKIT_TIMEOUT=1reproduces the exact CI error locally, proving the var now reaches the plugin and controls that timeout.3. Benchmark PR comments have never worked
The comment job guarded on
github.com.event_name == 'pull_request'. There is nocomproperty on the github context, so the expression evaluates to null, never matches, and the job has silently never run.Fixing the guard alone would have made things worse: the workflow declares no
permissions:block and this repo's defaultGITHUB_TOKENis read-only, so the job went straight to403 Resource not accessible by integration— observed on the first push of this branch. Grantingpull-requests: writeat the job level fixes it; the job only reads and writes PR comments and never checks out the repo.The performance-comparison comment on this PR is that job working for the first time.
4. Remaining actionlint findings
.githubis now actionlint-clean.sql.ymlstill pinnedactions/checkout@v3, whose runner GitHub no longer supports, and the three composite actions carried emptydescriptionfields.Verification
task lint— green, 15 projects,lint+lint:format, includingserver:lint(golangci-lint, norawsql, notxread)actionlint— clean across all workflowsprettier --check— clean on every changed fileNot addressed, deliberately
cli@1.1.0remains published with 4 of 6 assets, and already carries a release note pointing Windows users atcli@1.1.1(which is marked Latest and complete). Backfilling would mean uploading locally-built binaries with different provenance than the rest of the release, and re-cutting a shipped tag is worse. Left as an accurate historical record.No visual surface — CI configuration and a dependency bump only.