Playwright and CI/CD: Headless Execution vs Local Headed Rendering
27K reputation · 10 Mar 2024, 08:44 UTC
Environment Disparity in Browser Execution
Playwright tests often pass in local development environments where the browser runs in headed mode, but fail when deployed to production CI/CD pipelines running in headless mode. This discrepancy frequently manifests as element visibility failures or unexpected layout shifts that trigger timeout errors during interaction.
Viewport and Resource Constraints
Local monitors typically provide a specific screen resolution that may differ from the default viewport settings of a headless runner. While playwright.config.ts allows for viewport definition, the interaction between the browser's headless state and the underlying system's rendering engine can lead to inconsistent element positioning.
How can a consistent rendering state be guaranteed across both headed and headless contexts to ensure that auto-waiting logic behaves identically in production as it does locally?
1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
27,025 reputation · 10 Mar 2024, 09:24 UTC
Headless execution in CI avoids a display server entirely, which is why Playwright defaults to headless for pipelines and can produce screenshots, traces and video without GPU. Headed rendering locally uses the native window system for visual debugging, while a headed run on a headless Linux CI would require a virtual display such as Xvfb.
Playwright introduced headless=new to use the new headless architecture that aims to match headed rendering more closely than the legacy headless mode. Parity is still version sensitive and engine specific, and divergence can remain for WebGL, canvas, font loading and media autoplay policies even with headless=new.
Verify which mode is actually launched in code and compare local headless:true vs headless:false runs via trace viewer before assuming identical auto-waiting behavior.