Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: unpin primary node version in ci #8167

Merged
merged 3 commits into from
Jan 30, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ concurrency:
cancel-in-progress: true

env:
PRIMARY_NODE_VERSION: '>=20.6.1'
PRIMARY_NODE_VERSION: 20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@auvred auvred Jan 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 😂

# Only set the read-write token if we are on the main branch
NX_CLOUD_ACCESS_TOKEN: ${{ (github.event_name == 'push' && github.ref == 'refs/heads/main') && secrets.NX_CLOUD_ACCESS_TOKEN || '' }}

Expand Down
Loading