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?"
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
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
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
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.
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,
},
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).
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].