Rayrun
← Back to Discord Forum

GH action is failing & timing out

alistair09197posted in #help-playwright
Open in Discord
alistair09197

Tests all passing when run locally but i'm having an issue where my GH action is taking an hour and then fails all tests. Any advice on how to debug? I'm not able to see the relevant error

This thread is trying to answer question "How can one debug a GitHub Action that is failing and timing out, where tests pass locally but fail on GitHub Actions?"

16 replies

you should store report somewhere to debug that's the only way

Yeah, ok. I'm finding the slow paced feedback while debugging GH Actions hard to deal with.

Here is the error being logged

[WebServer] [10:41:57] [WebServer] 'templates' errored after 527 ms
[10:41:57] Error: premature close
    at onclosenexttick (/__w/www-templates/www-templates/node_modules/end-of-stream/index.js:53:86)
    at processTicksAndRejections (node:internal/process/task_queues:78:11)
[10:41:57] 'ci' errored after 529 ms

Error: Process from config.webServer was not able to start. Exit code: 1

Seems like you're using webServer in your configuration. Check what timeout you're using for it, perhaps it's abnormally long and because of that your GH actions takes an hour?

Also web server fails to start

yes, here is the webServer config I have in playwright.config.js :

webServer: {
    command: 'gulp ci',
    url: 'http://localhost:3000',
    reuseExistingServer: true // !!process.env.CI
  },

gulp ci generates a set of static HTML pages, and then starts up the browsersync web server

I have timeouts set elsewhere in the config which affect the test durations, I haven't changed these from the default as yet:

timeout: 30 * 1000,
  expect: {
    timeout: 5000
  },

I'll look into adding a timeout on the webServer. Locally the gulp ci task takes 5-6 seconds to start. I've tried to optimise the speed of this to see if that made any difference

See in my error, I noticed the directory is repeated e.g. /__w/www-templates/www-templates/node_modules. I thought that looked a bit strange

GG @alistair09197, you just advanced to Playwright community level 1! Keep up the amazing work.

alistair09197

I see it's common to use reuseExistingServer: !process.env.CI

I understand !process.env.CI prevents a web server from running on the GH instance. Mine is set to true. I don't really understand how the tests can be run without the server for the headless browser to use. When/why would you use !process.env.CI ? Feel like i might be doing it wrong, although I think I certainly will need the gulp ci command to run to generate the static HTML pages

!process.env.CI doesn't prevent from starting the server. This is useful for local development because usually you don't need to start a new server every time you start your tests - you can reuse already running server.

alistair09197

I've pared my project down by creating a new fresh repo with a simple Hello World setup, and it's working fine using the same tools and commands. I'm going to port across features until it breaks. Quite frustrating and time-consuming but at least I've got a pathway forward. Thanks for your advice.

Hey @alistair09197 , i know this was a while ago but did you ever fix this issue? I am having a similar issue, although my CI was working a couple weeks ago with the exact same config

I did increase the webServer timeout, as well as the root-level timouet config without any difference (it fails instantly)

Not exactly the same, but:

[WebServer] error: script "dev" exited with code 1 (SIGHUP)

Error: Process from config.webServer was not able to start. Exit code: 1

Works fine locally (just not GitHub Actions). Config:

webServer: {
    command: "bun dev",
    port: (process.env.PORT as unknown as number) || 3000,
    timeout: ms("2m"),
    // do not use an existing server on CI
    reuseExistingServer: !process.env.CI,
  },
refactoreric

Many cases can be analyzed/troubleshooted with the trace files and trace viewer: https://playwright.dev/docs/trace-viewer-intro

Just wanted to mention this here for completeness. I suspect this case is one where the problem is 'elsewhere' (not in automating the app via browser or api).

Related Discord Threads

TwitterGitHubLinkedIn
AboutQuestionsDiscord ForumBrowser ExtensionTagsQA Jobs

Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].