-
Notifications
You must be signed in to change notification settings - Fork 486
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: use lts node version in CI #2259
base: main
Are you sure you want to change the base?
Conversation
…ablish-libp2p-webtransport-connections
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
building with 20 lgtm, but it fails to build for me with v22.4.1
, so the CI will break when 24 becomes LTS and someone will have to search for last working version and hardcode it again 😿
is lts/*
useful in CI of rarely-maintained apps? i remember the same breackage occuring 12→14→16→18 (nearly every time a change of LTS image broke CI in one of our legacy JS apps)
maybe hardcode to 20.x
to avoid headache? (not feeling strongly, i'd just rather not deal with problem once LTS breaks again)
most likely not, but we probably want to see a failure when it occurs right?
That is good with me, but we should probably target 22 now since it's going active very soon |
I think once I get ipfs/ipld-explorer-components#448 done, we will be closer to updating everything here. |
Updates all github workflows selections of node-version to be "lts/*"