Someone copied their local command into the pipeline, including --headed, and the job now hangs and is killed at the 60-minute timeout. Removing the flag fixes it, so the immediate problem is solved, but I would like to understand what it was waiting for — and whether there is a legitimate reason to run headed on an agent.
--headed on the build agent just sits there until the job times out
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
1 answer
Accepted answer
Headless is the default and it is the right default for an agent.
--headedasks for visible browser windows and a build agent has no display, so the browser cannot launch at all.There is no legitimate reason to run headed in CI, because the thing people want it for — seeing what happened — is served better after the fact:
- the HTML report and the dashboard under
.sdods/runs/<runId>/, uploaded as artefacts, - the trace, which replays the run step by step with the DOM at each point.
Keep
--headed,--uiand--debugfor your own machine. They are all interactive.answered by Sunita Kale- the HTML report and the dashboard under
Know the answer?
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.
Related
- Installing onto a machine with no outbound internet at all0 answers
- Linting only the staged feature files in a pre-commit hook — is --json stable enough?0 answers
- har record printed no scrub line and the Cookie header is still sitting in the file0 answers
- Can --explain show the values a layer lost with, not just the winner?0 answers
- Six locales times dark and light means twelve env files — is there a per-scenario way?0 answers