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

Go back to using explicit node verisons in CI #51965

Merged
merged 3 commits into from
Dec 19, 2022

Conversation

jakebailey
Copy link
Member

@jakebailey jakebailey commented Dec 19, 2022

Fixes #51943

We were using "*" and "lts" assuming that one would be the most recent node release, and the other be LTS. This turns out to be wrong because "*" means "whatever is newest in GHA's cache", not the actual latest.

We could switch to say "current" or "latest", which would ensure we always get the actual current Node version. However, the current setup has another problem; it assumes that there are only two LTS versions out at one time. This isn't accurate; right now, Node 14, 16, and 18 are all LTS, and we are now suddenly not testing Node 14, which is scary.

I don't see a way to solve this, because at some points of the year, there will be two LTS releases, and sometimes, there will be three.

Just go back to explicitly listing the versions we test with. This will make us definitely run on all of our intended targets, but also mean old release branches won't suddenly test on the wrong versions, which is good.

We'll have to remember to update these, but I am personally confident that is fine. I also imagine that we don't want to drop Node 14 anytime soon, because it's the last version with stack restarting in debugging, a feature that many on the team use (including me).

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Dec 19, 2022
@jakebailey
Copy link
Member Author

Well, that's disconcerting; our tests fail on Node 19. I guess it's good we didn't get upgraded...?

@jakebailey
Copy link
Member Author

Okay, so, Node 19 (probably v8) changed the formatting of Dates; instead of just 12:00:00 AM with a space character between them, toLocaleTimeString in en-US now returns a string where the space is \u202F, the narrow non-breaking space. Wow.

@rubiesonthesky
Copy link

Okay, so, Node 19 (probably v8) changed the formatting of Dates; instead of just 12:00:00 AM with a space character between them, toLocaleTimeString in en-US now returns a string where the space is \u202F, the narrow non-breaking space. Wow.

You probably already found this issue but linking it in case you did not spot it, nodejs/node#45171

@jakebailey
Copy link
Member Author

jakebailey commented Dec 19, 2022

Yikes, I guess it's an icu change, not even a node change. This is just a testing bug, so I'll just change the helper to fix the character. This sort of thing could happen to any version of Node, I'm guessing.

Cross linking:

@ddzz
Copy link
Contributor

ddzz commented Dec 19, 2022

node-version: "*" is still used in other parts of .github/workflows/ci.yml. We may want to update/remove all uses of "*" in this PR.

@jakebailey
Copy link
Member Author

node-version: "*" is still used in other parts of .github/workflows/ci.yml. We may want to update/remove all uses of "*" in this PR.

There's no major need to do this; all of the tasks which don't pin a version of Node don't care about the particular version other than that it's new enough.

- "19"
- "18"
- "16"
- "14"
bundle:
- "true"
include:
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can take out L27 here?

Copy link
Member Author

Choose a reason for hiding this comment

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

No node-version means "use whatever random version is installed on the runner on $PATH", and is used if you want to set up other Node stuff like proxies or auth, but keep the version active on the runner. I don't think that's what we want.

Copy link
Contributor

Choose a reason for hiding this comment

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

L27 re-introduces the duplication problem from the original issue. There are now Node * and Node 18 jobs, which are duplicates.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is an entirely different build with --bundle=false. It's not a duplicate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I missed that, never mind! Thanks for jumping on my bug report so quickly.

@jakebailey jakebailey merged commit ef70a28 into microsoft:main Dec 19, 2022
@jakebailey jakebailey deleted the workflow-node-version branch December 19, 2022 23:20
@jakebailey jakebailey mentioned this pull request Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Node * and Node lts/* CI jobs are duplicates
6 participants