github-action: wait-on "localhost" not resolving after upgrading Node.js 16 to 18

My project is upgrading from Node 16.14.2 to 18.12.1.

On my local machine using Chrome, going to our homepage (on port 8000) using the “localhost” name works without issue (http://localhost:8000/).

In our Github workflow, we have:

name: CI
on: [push]
env:
  [...]
  NODE_VERSION: 18

jobs:
  [...]
  e2e-test:
    timeout-minutes: 20
    runs-on: ubuntu-latest

    steps:
      - run: echo $HOME
      - name: Check out the code
        uses: actions/checkout@v3

      - name: Use node ${{ env.NODE_VERSION }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'yarn'

      - name: Cypress run
        uses: cypress-io/github-action@v4
        with:
          start: yarn develop
          browser: chrome
          wait-on: "http://localhost:8000/"
          wait-on-timeout: 300
          command-prefix: 'percy exec -- yarn'
      [...]

However, this wait-on ends up timing out, resulting in the error:

...
You can now view [website] in the browser.
⠀
  http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  http://localhost:8000/___graphql
⠀
...
success Building development bundle - 97.705s
success Writing page-data.json files to public directory - 0.791s - 257/257 324.90/s
http://localhost:8000/ timed out on retry 331 of 11, elapsed 330780ms, limit 330000ms
Error: connect ECONNREFUSED 127.0.0.1:8000

This was working on Node 16 but now breaks on Node 18.

Doing some digging, I came across this discussion in the Node repository, saying that starting with Node 17, the IPv4 address “127.0.0.1” would no longer be accepted by default.

But when I changed my Github config above to use wait-on: "http://[::1]:8000/" instead of localhost, the error went away. This leads me to believe that wait-on is not being “smart” about localhost.

Please let me know if this is an issue on my side that I should change or if you agree this is something to be tackled on the Cypress side.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 13
  • Comments: 19

Commits related to this issue

Most upvoted comments

@mraible

  • I’ve added a new issue https://github.com/cypress-io/github-action/issues/760 to be clearer about how to reproduce it. I wasn’t able to find a solution. I just found an additional workaround of using a different server.
  • I noticed that other servers will respond to both IPv4 127.0.0.1 and IPv6 ::1 whereas ng serve seems to respond to one or the other, but not both. The ideal situation would be for Angular and Cypress development engineers to look at this together.

I experienced this today. Changing my GitHub Actions workflow to use Node 16 (from 18) solved the problem. For Node 18, I had to use wait-on: 'http://[::1]:4200' for it to work. This value does not work with Node 16. So I ended up with this:

name: Demo CI

on: [push, pull_request]

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18]
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Use Node ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - name: Install latest Chrome
        run: |
          sudo apt update
          sudo apt --only-upgrade install google-chrome-stable
          google-chrome --version
      - name: Install dependencies
        run: npm ci
      - name: Run unit tests
        run: xvfb-run npm test -- --watch=false
      - name: Run integration tests
        uses: cypress-io/github-action@v5
        with:
          start: npm start
          install: false
          wait-on: ${{ matrix.node-version == 18 && 'http://[::1]:4200' || 'http://localhost:4200' }}

Since Node v17.0.0, you have to use the following node option on your pipeline (for me, bitbucket pipeline does not allow ipv6 adresses)

export NODE_OPTIONS=--dns-result-order=ipv4first

In my case problem was solved by updating Node.js from 16.11 to 16.13 and cypress 9.4 to 9.7.

  • GitHub has now switched the default Node.js version to 18 in GitHub hosted runners, so I expect that more related issues are going to start surfacing. This includes one set of examples here in the repository. See issue #802.

Edit: The examples are now fixed, in the sense that a workaround has been implemented. See PR https://github.com/cypress-io/github-action/pull/803.

@mraible

There is another alternative which I previously overlooked. It is documented in README: Wait-on.

Use the npm package wait-on to wait for the Angular server ng serve to come online.

Execute:

npm install wait-on

and replace

wait-on: 'http://localhost:4200'

with a 60 second wait for the server using wait-on

wait-on: 'npx wait-on --timeout 60000 http://localhost:4200'

The npm package wait-on behaves differently to the built-in wait-in, which is based on the npm package got, so this may be a useful workaround in other situations as well.

Hey @MikeMcC399, on the project where I found this we were using GatsbyJS v5 and starting a server with gatsby develop and no other arguments (no host or port overrides, no HTTPS or anything):

https://www.gatsbyjs.com/docs/reference/gatsby-cli/#develop

@mraible

There is another alternative which I previously overlooked. It is documented in README: Wait-on.

Use the npm package wait-on to wait for the Angular server ng serve to come online.

Execute:

npm install wait-on

and replace

wait-on: 'http://localhost:4200'

with a 60 second wait for the server using wait-on

wait-on: 'npx wait-on --timeout 60000 http://localhost:4200'

The npm package wait-on behaves differently to the built-in wait-in, which is based on the npm package got, so this may be a useful workaround in other situations as well.

Thanks, for me this was the solution. I was using a custom start command with pnpm and vite preview --port 8080, which also produced the ERRCONNREFUSED error in the CI - whereas locally the dev server started and was reachable.