ci: merge 9.2.x up into 9.3.x - #1892
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
ci: merge 9.1.x up into 9.2.x
Clean merge — 9.3.x's workflow was identical to 9.2.x's before the CI work, so there was nothing to reconcile. package-lock.json merged cleanly and is already canonical: `npm install --package-lock-only --lockfile-version 2` produces no diff, and .dependencies/.devDependencies match packages[""].
This was referenced Aug 12, 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 #1891 (
9.2.x) into9.3.x. Third rung; 10.x and 11.x follow.Cut from
9.3.xwith9.2.xmerged in, matching the repo's merge-up convention (Merge branch 'patch2/9.2.x' into patch2/9.3.x).Clean merge — no conflicts. 9.3.x's workflow was byte-identical to 9.2.x's before the CI work, so there was nothing to reconcile.
What changes on 9.3.x
No
lib/ortest/changes — 9.3.x's source is untouched.Why this branch needed it
Same as 9.2.x:
os: [windows-2019, windows-2022]meant 21 of 33 Windows jobs sat permanently queued against a label retired in June 2025, sotest-windowsnever completed andrelease(whichneedsit) never ran. AndNPM_TOKENexpanded to an empty string — the repository has no Actions secrets, publishing is npm trusted publishing only.Inherited from the ladder
tediousjs/setup-sqlserverpinned to the v4.0.1 SHA; SQL Server via a service container; pinned runner labels; checkout/setup-node v7;fail-fast: false.NPM_TOKENdropped; release job on Node 22.x.engines.nodeis>=10on tedious^15.0.1, so the Node 14 floor stays.Verification
npm ci+npm run test-unitpass under nvm on Node 14.21.3 (npm 6.14.18) and 24.18.0 — 31 passing on both;npm run lintclean on 18.The merged
package-lock.jsonwas checked rather than assumed:lockfileVersion: 2,.dependencies/.devDependenciesmatchpackages[""], and it is already canonical —npm install --package-lock-only --lockfile-version 2produces no diff, so no regeneration was needed.Heads-up, not caused by this PR
The release job on 9.1.x failed after #1889 merged, at
addChannel:OIDC itself works (
OIDC token exchange with the npm registry succeeded) — npm's trusted-publishing token authorisesnpm publish --tagbut not the standalone dist-tags endpoint (semantic-release/npm#1023). It only affects back-filling a channel onto an already-published version. 9.3.x will hit the same thing when this merges:v9.3.2's note is{"channels":[null]}, so semantic-release will try to addrelease-9.3.x. Being tracked separately.