Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore: unpin primary node version in ci #8167

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Jan 30, 2024
Merged

chore: unpin primary node version in ci #8167

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b81b483
chore: unpin primary node version in ci
auvred Jan 2, 2024
8e8cbaa
Merge branch 'main' into chore/8166
auvred Jan 4, 2024
0812265
Merge branch 'main' into chore/8166
auvred Jan 8, 2024
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
View file
Open in desktop
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 •
edited
Loading

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