chore: use node 21 for github actions #5842
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Ignored Deployments
|
|
riqwan
changed the title
|
@olivermrbl @adrien2p works with some minor changes! |
There was a problem hiding this comment.
pretty awesome!
only thing I can think of is whether the github actions should be run with the minimum node version we support to ensure we are not "accidentally" approving changes that are only compatible with the latest version of node
that said, if this reduces CI time, I think we can solve this concern elsewhere, e.g. with a release pipeline
|
In the ci, we can also specify multiple versions of node and the ci will run for each of them, but then it will be longer but ensure it works for all the versions tested |
|
We are currently experiencing an issue related to an old node version in our CI, so I think we should try to make this land on develop soon. My suggestion for the above "issue" would be to include a separate workflow, we can dispatch every time we release with our minimum required node version as input. It can be the same workflow with defaulting to v21 unless specified otherwise. I am not comfortable running our actions with one version, while officially supporting a different one. We need to ensure the minimum required version is stable. What do you think? |
|
@olivermrbl why dont we provide an array of versions with min and 21 in the current workflow? |
Wouldn't that make the pipeline take significantly longer time to complete? Update: I am keen to give this a try, but if it extends the CI time too much, I'd rather go with a different approach. |
They should run in parallel, at least from my experience with the extender, all versions ran at the same time. We just need to provide the matrix |
|
If we are experiencing an issue with our current version, would the other workflow even run successfully? |
Nice, I didn't know that. But I guess that makes the whole idea of the PR redundant? |
|
The only left question is the one from riqwan, the 16.14 will likely create memory issues (jest + v8 update) and 16.10 is currently creating issues with some packages. |
|
Yes this pr would slight change to use strategy: matrix: node: [] |
No, you're right – this would have to be fixed. From what I can tell, updating the Node version used in one of our workflows resolves the issue, we are facing. It seems to be a dependency requiring a minimum Node version of 16.14 and we default to 16.10. Did you experience issues with 16.14 specifically @riqwan or would this be an OK change to resolve it here and now? |
|
There is the jest memory issues above 16.10 and under 20 something. Because of a v8 update that occurs at that time |
But since this workflow is not testing anything with jest, it should be fine no? We are just cloning our starter to ensure our CLI works as expected. |
|
The integration tests are likely to fail often Override: you mean for the specific cli workflow. Should be fine 👌 |
Yes exactly. I am only using 16.14 for this specific workflow. None of the integration test flows should be affected. |
|
No issues with 16.14, this would be fine. I was more interested in the integration tests for the performance gains. |
Do you have an idea of how much it cuts off? If it's significant, I think it's worth trying to find a way to make it land. |
|
@olivermrbl I could only run it without cache to test, and it was only about a minute faster. |
I've personally had great boost in local dev time and memory consumption moving from 16 to 21.
Let me know if there might be issues with release actions with the bump to 21