ci: merge 9.1.x up into 9.2.x - #1891
Merged
Merged
Conversation
The repository has no Actions secrets, so `secrets.NPM_TOKEN` resolves to an empty string and any publish from this branch would fail to authenticate. master publishes via npm trusted publishing (OIDC) instead, which needs @semantic-release/npm >= 13.1.0 — it performs the OIDC token exchange itself rather than relying on the npm CLI version. The lockfile is deliberately kept at lockfileVersion 2 so npm 6 (bundled with Node 14) can still `npm ci` it. These packages require Node ^22.14 || >=24.10, but they are only installed — never executed — on the older Node versions in the test matrix, so the engine warnings there are harmless.
Every Windows job on this branch fails: `windows-latest` is now windows-2025, and potatoqualitee/mssqlsuite cannot install SQL Server there. Swap it for tediousjs/setup-sqlserver (already used from 9.2.x onwards) and pin the runner labels rather than tracking `*-latest`, so a future image migration is a deliberate change instead of a surprise breakage. Other changes, all aligning this branch with the 9.2.x workflow so merges up the maintenance line stay clean: - Run SQL Server as a job service container instead of hand-rolled docker pull/save/load. This drops actions/cache@v3, whose backing service has been shut down, and the readiness loop that shelled out to /opt/mssql-tools/bin/sqlcmd — a path that no longer exists in the images. - Bump checkout/setup-node to v7; v3 targets a Node runtime the runners now force-upgrade. - Drop the x86 leg of the Windows matrix. No branch from 9.2.x onwards tests x86, and it doubled an already large matrix. - Add windows-2025 alongside windows-2022, and set fail-fast: false so one bad combination no longer cancels the whole matrix.
This branch was master when 9.1.2 and 9.1.3 were cut, so `branches: [master]` in .releaserc used to be correct. Now that it is a maintenance branch that config means semantic-release exits without ever considering a release. Dropping the key falls back to semantic-release's defaults, which already include the `N.N.x` maintenance pattern — the same config 9.2.x onwards use. The release job itself: - Drop NPM_TOKEN. The repository has no Actions secrets at all, so it expanded to an empty string; authentication now comes from the OIDC id-token, as on master. - Pin Node to 22.x. `lts/*` happens to satisfy the new semantic-release engine range today, but only by luck of which line is current LTS. - Guard on `github.repository_owner == 'tediousjs'` so pushes to a fork do not attempt a release, matching every later branch.
package.json declares `engines.node: >=10`, so this branch claims support for every Node release since, but the matrix stopped at 18 — the last three LTS lines were entirely untested. Verified locally against Azure SQL Edge before widening: the tedious suite gives an identical 111 passing / 5 pending on Node 18, 20, 22 and 24. Widening the matrix forces a decision on msnodesqlv8, because v2 publishes no prebuilt binary above Node 19 and its install script falls through to a node-gyp source build when a prebuild is missing. Rather than adopting master's full v2/v3/v4/v5 fan-out, each Node version installs the single major that has a prebuild for it: v2.7.0 up to Node 18, v4.5.0 from Node 20. v3 is a strict subset of v4's prebuild coverage, and v5 has never shipped a Node 18 binary. Versions are pinned rather than ranged, which is the one deliberate departure from master. msnodesqlv8 5.2.2 removed the Node 20 prebuild from an existing major and broke master's CI without a commit to master; a branch that goes months between commits would instead discover that while trying to ship a security fix, since `release` needs `test-windows`.
The AppVeyor project still exists but has recorded zero builds, and appveyor.yml pins `image: Visual Studio 2015` — an image AppVeyor retired long ago — so nothing here has run in years. Windows coverage moved to GitHub Actions, which now tests more Node and SQL Server combinations than this ever did. 9.2.x onwards already deleted the config; only 9.1.x still carried it. The README badge outlived it on every maintenance branch and pointed at `/branch/master`, so it reported the status of a branch that has had no appveyor.yml since 9a08da0 rather than the branch you were reading. test/scripts/ contained nothing but the two AppVeyor helpers and nothing referenced them, so the directory goes with it. Mirrors master's 09c1e64.
ci: get 9.1.x building and releasable again
This was referenced Aug 11, 2026
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.
Merge-up of #1889 (
9.1.x) into9.2.x. Second rung of the ladder; 9.3.x, 10.x and 11.x follow.Supersedes #1890, which was cut the other way round (9.1.x as first parent). Same tree, correct parentage.
What changes on 9.2.x
No
lib/ortest/changes — the merge-base isfdf7b17, the pre-#1889 tip of 9.1.x, so 9.2.x already contained everything 9.1.x had and is ahead of it inlib/msnodesqlv8/connection-pool.js. Only the CI/release work moves forward.Why 9.2.x needed this
test-windowscould never complete. The matrix pinnedos: [windows-2019, windows-2022], and windows-2019 was retired in June 2025 — 21 of 33 Windows jobs sat permanently queued rather than failing, sotest-windowsnever finished andrelease(whichneedsit) never ran. The branch wasn't red, it was hung.Publishing was dead.
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}expanded to an empty string — the repository has no Actions secrets at all. master moved to npm trusted publishing in cef6873; the maintenance branches never followed.Inherited from #1889
tediousjs/setup-sqlserverpinned to the v4.0.1 SHA; SQL Server via a job service container; pinned runner labels; checkout/setup-node v7;fail-fast: false.@semantic-release/npm>= 13.1.0 performs the OIDC exchange itself, so the bundled npm version is irrelevant;NPM_TOKENdropped and the release job pinned to Node 22.x.engines.nodesays>=10while the matrix stopped at 18./branch/master).Resolved for this branch
SQL Server 2016 kept in the Windows matrix. 2008/2012/2014 are unrecoverable — they only install on windows-2019.
package-lock.jsonregenerated with--lockfile-version 2rather than left as a text merge, so it is internally consistent and npm 6 (Node 14) can still read it.Verification
npm ci+npm run test-unitpass under nvm on Node 14.21.3 (npm 6.14.18) and 24.18.0;npm run lintclean on 18. Lockfile checked:lockfileVersion: 2, and.devDependencies/.dependenciesmatchpackages[""]exactly. No conflict markers in any merged file.The tedious suite was previously run against Azure SQL Edge on Node 18/20/22/24 with identical results (111 passing / 5 pending), and msnodesqlv8 4.5.0 confirmed green on Node 20/22/24 across windows-2022 and windows-2025 on #1889's final run.
Windows matrix comes out at 48 jobs (2 images × 6 Node × 4 SQL). Happy to trim — dropping windows-2025 halves it — but 2025 passed cleanly on 9.1.x, so full coverage is in.