CI: three hand-maintained Node pins, and nothing that keeps them in step

[sgort]

Raised after ronl-business-api#36 was closed by ronl-business-api#115, which moved that repository to a single .nvmrc read by every workflow. This is the question of whether the same is worth doing here.

It is a weaker case here than it was there, and this issue says so up front rather than arguing by analogy.

What this repository actually declares

source	says
azure-backend-acc.yml, azure-backend-production.yml	22.23.2	matches the host — see below
azure-frontend-acc.yml, azure-frontend-production.yml	20.20.2	two majors behind the backend, same repo
zizmor.yml	24.19.0	deliberate, and should stay
engines.node	>=20.20.2	a floor, permitting all three

azure-ropa-site-acc.yml and azure-ropa-site-prod.yml declare nothing, correctly: packages/ropa-site is three static files with no package.json, is not an npm workspace, and those workflows have no setup-node step.

Why RONL Business API's argument does NOT transfer

There, eight workflows built the deployed backend artifact on Node 20 and shipped it to an App Service running NODE|22-lts. A genuine build/host mismatch.

Neither half of that holds here:

• The backend already agrees. ronl-linkeddata-backend-acc and ronl-linkeddata-backend-prod both run NODE|22-lts, and both backend workflows pin 22.23.2.
• The frontend pin does not build the shipped bundle. app_build_command: "npm run build:acc" hands the build to Oryx inside the action's container — as azure-frontend-acc.yml's own comment puts it, "there is no build step". So 20.20.2 governs lint, typecheck and test only.

So nothing here is currently shipping an artifact built on the wrong major.

What is still worth fixing

The pins drift, because three literals are maintained by hand and nothing reconciles them. #80 is open right now demonstrating it: it moves engines.node to >=24.20.0 while the workflows stay at 24.19.0 and 22.23.2. That is the same shape as the (×N) register drift check-supply-chain was written for — a number that is true in one file and stale in another, with every gate green.

Two smaller points:

• Frontend tests run on a different major than backend tests, in one repository, for no recorded reason. If 20.20.2 is deliberate it deserves a comment; if it is leftover it is a silent inconsistency.
• engines.node >=20.20.2 permits a combination nothing tests.

The option

.nvmrc with an exact version, and node-version-file: .nvmrc in the four workflows that set up Node. Renovate's node manager parses .nvmrc, so it stays maintained rather than hand-bumped, and #80's class of drift stops being possible.

zizmor.yml keeps its literal either way: renovate-config-validator needs Node 24 because renovate@44.50.3 declares engines.node ^24.11.0, and npm accepts a mismatch with an EBADENGINE warning rather than refusing — so that pin is load-bearing.

The open question this issue cannot answer on its own: whether backend and frontend should share one version at all. RONL Business API could collapse to one because its host settles it. Here, deciding that is the work; the mechanism is trivial afterwards. If the answer is "no, they differ on purpose", then the fix is a comment in each workflow saying why, not a shared file.

Worth sequencing after #80 lands, since that PR moves two of the three numbers.