Problem description
With the GitHub migration of runners to use Node.js 18 as default on Feb 18, 2023, some workflows using the built-in wait-on parameter of cypress-io/github-action are now were failing: for example, #760 with Error: connect ECONNREFUSED 127.0.0.1:4200. Edit: no longer failing due to workaround implementation.
This affects development webservers which are not listening on both IPv4 and IPv6. Some, like vite, can be set to start and listen on 0.0.0.0 which solves the issue. Others don't seem to be so flexible.
It also affects the alternate method of using start-server-and-test as an argument to the built-in wait-on parameter. Due to the fact that start-server-and-test depends on the separate npm module wait-on and this external wait-on also trips up on Node.js 18 in certain configurations, it also becomes a problem for start-server-and-test.
Workarounds can be found, such as using the IPv6 loopback address ::1 instead of the more generic localhost hostname. The workarounds differ depending on the dev webserver and the environment it is being run under.
Questions
- Is it necessary for cypress-io/github-action to adapt to dev webservers which are not listening on both IPv4 and IPv6, or is the onus on the dev webserver providers to make changes and on users to find suitable workarounds?
- If changes are made to cypress-io/github-action, is the older got v11 still the right choice for src/ping.js?
- Should cypress-io/github-action migrate to the current got
v12 v13 version? This is a breaking change due to the migration from CommonJS to native ESM.
- Or should another technology be used to check if a webserver is running?
Problem description
With the GitHub migration of runners to use Node.js 18 as default on Feb 18, 2023, some workflows using the built-in
wait-onparameter of cypress-io/github-actionare nowwere failing: for example, #760 withError: connect ECONNREFUSED 127.0.0.1:4200.Edit: no longer failing due to workaround implementation.This affects development webservers which are not listening on both IPv4 and IPv6. Some, like vite, can be set to start and listen on
0.0.0.0which solves the issue. Others don't seem to be so flexible.It also affects the alternate method of using start-server-and-test as an argument to the built-in
wait-onparameter. Due to the fact that start-server-and-test depends on the separate npm module wait-on and this externalwait-onalso trips up on Node.js 18 in certain configurations, it also becomes a problem for start-server-and-test.Workarounds can be found, such as using the IPv6 loopback address
::1instead of the more genericlocalhosthostname. The workarounds differ depending on the dev webserver and the environment it is being run under.Questions
v12v13 version? This is a breaking change due to the migration from CommonJS to native ESM.