ci: pin bun to 1.3.14 in the quality gate - #585
Merged
Conversation
`ci.yml` used `oven-sh/setup-bun@v2` with no version, so the main gate ran against whatever bun was latest at the time. A bun release could then break CI with no change in the repo, and CI could disagree with what contributors run locally — the worst kind of red build, because bisecting the repo finds nothing. `mcp-ci.yml` already pinned, but to 1.3.0, so the two workflows tested different runtimes. `packageManager` also said 1.3.0 while the committed lockfile is produced by 1.3.14. All three now name one version. Also adds `permissions: contents: read` to the quality job, matching mcp-ci. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Housekeeping. Three files, one version number.
.github/workflows/ci.ymlusedoven-sh/setup-bun@v2with nobun-version, so the gate that decides whether every PR is mergeable ran against whatever bun happened to be latest. That's a build that can go red with no change in the repo — and it can also go green on a runtime no contributor is using.mcp-ci.ymldid pin, but to1.3.0, so the two workflows exercised different runtimes on overlapping code.packageManagerin the rootpackage.jsonalso readbun@1.3.0while the committedbun.lockis produced by 1.3.14. Now all three say1.3.14.Also adds
permissions: contents: readto thequalityjob.mcp-ci.ymlalready scopes its token that way; the default is broader than a lint-typecheck-test-build job needs.No behaviour change for contributors already on 1.3.x. Anyone on an older bun will now get a clear version mismatch from
packageManagerrather than a confusing lockfile diff.Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Note
Low Risk
CI and toolchain version alignment only; no application, auth, or runtime behavior changes.
Overview
Aligns Bun to 1.3.14 across the main quality workflow,
mcp-ci, and rootpackageManagerso CI, lockfile tooling, and local dev agree on the same runtime.The
qualityjob inci.ymlnow pinsoven-sh/setup-bunto 1.3.14 (previously floated to latest) and addspermissions: contents: read, matching the tighter token scope already used inmcp-ci.mcp-ci.ymlbumps its pin from 1.3.0 to 1.3.14. Rootpackage.jsonpackageManagermoves from bun@1.3.0 to bun@1.3.14 to match the committed lockfile.Contributors already on 1.3.14 see no behavior change; older Bun installs should hit a clearer
packageManagermismatch instead of surprise CI or lockfile drift.Reviewed by Cursor Bugbot for commit af9a85d. Bugbot is set up for automated code reviews on this repo. Configure here.