-
Notifications
You must be signed in to change notification settings - Fork 206
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
test: Add Node.js 18.x to workflows #6599
Conversation
Be advised, Mergify should be adjusted to pick up on 18.x tests, and they should be also marked as "Expected"/"Required". |
|
Running locally with Node.js v18.12.1, I seem to get test execution in
|
Will try to understand what could be different between the CI worker and my local installation, resulting in |
a083890
to
31a1395
Compare
|
It looks like |
Bug in |
Could someone check that the runner |
I can't look at this this week, maybe @michaelfig can lend a hand? |
Running that test on a clean Ubuntu 20.04 (Focal) image deployed in Azure on D8s_v5 (8 vCPUs, 32G RAM) seems to work. This feels more and more like a runner-specific issue, but I am not sure why this one package's test would be affected. 😐 Here is the minimal scenario: curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/nodesource.gpg >/dev/null
echo "deb [signed-by=/etc/apt/trusted.gpg.d/nodesource.gpg] https://deb.nodesource.com/node_18.x $(lsb_release -s -c) main" | sudo tee /etc/apt/sources.list.d/nodesource.list >/dev/null
sudo apt update
sudo apt --yes dist-upgrade
sudo apt --yes install chromium-browser gcc g++ jq make nodejs perl
sudo corepack enable yarn
sudo wget -O /usr/local/go1.19.3.linux-amd64.tar.gz https://go.dev/dl/go1.19.3.linux-amd64.tar.gz
sudo tar -C /usr/local -xf /usr/local/go1.19.3.linux-amd64.tar.gz
eval $(echo 'export PATH=$PATH:/usr/local/go/bin' | sudo tee /etc/profile.d/golang.sh)
go version
# go version go1.19.3 linux/amd64
node --version
# v18.12.1
yarn --version
# 1.22.19
git clone -b maint/test-node-18.x https://github.com/sigv/agoric-sdk.git
cd agoric-sdk
yarn install
yarn build
cd packages/solo
yarn test
# 6 tests passed
# Done in 218.96s. |
dda6cca
to
21072b8
Compare
Slowly learning more about how this is interconnected. Right now it seems the Websocket connection in packages/solo/test/captp-fixture.js keep failing and looping - resulting in the observable mix of dots ( Latest run does imply that the service itself comes online - as signaled by "Deployed Wallet!" - just that the test scenario never kicks off. I also noticed that on Node 14.x the log output says
however, on Node 16.x it does not list the origin and instead says "unknown" as
I am locally observing "unknown" on Node 18.x as well, but just seemed a bit strange. |
Node.js 17.0.0 enables native DNS result priority, which can result in IPv6 being preferred in many scenarios. I wonder if the IPv6 stack is the issue for the CI runner! Node.js 16.x tests report I did not enable IPv6 stack on my test VMs, and when testing locally the Linux box was only hooked up to IPv4 too. The test runner must have a native IPv6 address and prefers to use it then! |
2b6f92f
to
a6fa12f
Compare
Sorry for the messy investigation and various rebases. @mhofman, @michaelfig, this is ready for review and potential merge. |
a6fa12f
to
da9e778
Compare
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.
Thanks for investigative work you did on this PR. Once we revert to 16 on the deployment test I believe this can be merged.
Please also allow edits from maintainers for your branch so mergify can rebase as necessary before merging.
With Node.js 17+ defaulting to IPv6, hosts that have native IPv6 stacks might have resolved `localhost` to `::1`. (See: nodejs/node#39987) This would generally be fine for most applications, but seems here listening only happens on the IPv4 stack. This was not observed as an issue on Node.js <= 16, because it prioritized IPv4 addresses historically. This commit replaces `localhost` with `127.0.0.1` because there is a `connections.json` which gets written the IPv4 address as well. At a later time, the package should theoretically be re-checked, to better handle (and use) the IPv6 stack.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Ubuntu version on the agent running Deployment Test should be upgraded, so that it is compatible with Node 18. Reverting in the meantime. Co-authored-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
87f06fe
to
b09c2d6
Compare
@mhofman, don't forget about marking the 18.x tests as "Expected"/"Required" so they are visible clearly in the GitHub UI, as well as adding them to Mergify checks! |
And big thanks for the review! 🎉 |
Yup, planning on making them required, and removing the 14 ones from required |
Thanks so much for your contribution. |
refs: #6489
Description
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30).
This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used.
This finishes up the bulk of #6489, however manual testing of compatibility should be conducted further before that.
Security Considerations
N/A. This is a change to test scenarios, to support the Current LTS of Node.js.
Documentation Considerations
Backwards compatibility should not be affected. As result of manual testing in #6489, it may be decided to inform users that Node.js 18.x is now officially supported. Upgrade of Node.js versions is breaking for compiled blobs, in which case users need to rebuild project when upgrading from Node.js 16.x to 18.x, similar to how they would do when upgrading from 14.x to 16.x.
Testing Considerations
The test suite is expanded to support Node.js 18.x. Additional manual testing is out of scope for this PR and can be evaluated/discussed in #6489.