Hmm, can we go the other way? Changing node-version to be 16 and the pinned primary node version?

According to https://github.com/orgs/community/discussions/26388 and https://stackoverflow.com/questions/74072206/github-actions-use-variables-in-matrix-definition it's not a straightforward [16, ${{ env.PRIMARY_NODE_VERSION }}] 🙃 ... [16, "$PRIMARY_NODE_VERSION"] might not work either then. I haven't tried it.

So maybe a startsWith kind of check is necessary?

I'd rather not unpin a version and introduce unexpected version changes if we can avoid it.

Yes, it looks like we can't use env context in matrix definition :(

You can use the env context in any key in a workflow step except for the id and uses keys.

^ Ref: GitHub docs

I'd rather not unpin a version and introduce unexpected version changes if we can avoid it.

On main branch (with pinned PRIMARY_NODE_VERSION: '>=20.6.1') actions/setup-node@v3 action downloads v20.10.0

Run actions/setup-node@v3
  with:
    node-version: >=20.6.1
    always-auth: false
    check-latest: false
    token: ***
  env:
    PRIMARY_NODE_VERSION: >=20.6.1
    NX_CLOUD_ACCESS_TOKEN: ***
Found in cache @ /opt/hostedtoolcache/node/20.10.0/x64
Environment details
  node: v20.10.0
  npm: 10.2.3
  yarn: 3.7.0

So I think it's safe to unpin it!

It was pinned in this commit 2a03e44 only two days later when v20.6.1 was released https://github.com/nodejs/node/releases/tag/v20.6.1. I guess it was the only way to force it to be higher than v20.6.0 (For some reason website tests were failing without Node.js being pinned (workflow runs))

But now the latest v20.x.x version of Node.js is used, whether PRIMARY_NODE_VERSION is pinned or not

If we decide to leave it pinned and not touch it (I'd rather change it 😄), then we should use something scary like

startsWith(env.PRIMARY_NODE_VERSION, format('>={0}', matrix.node-version))

So, what do you think? Leaving it pinned makes sense to me as well, so if you decide to leave it pinned, I'll change all comparison expressions to startsWith

Yeah that makes sense. My hesitation around unpinning is that I don't like "surprise" Node version bumps... ideally we'd have an exact version that gets updated over time the way Renovate bumps our versions of dependencies.

...but since we're already not doing that I think this is a straightforward bug fix. 😂