Introduction: Why Playwright CI/CD Knowledge Matters in 2026
Playwright CI/CD interview questions are increasingly important for QA Automation Engineers, SDETs, DevOps engineers, and QA Leads.
Knowing how to write a Playwright test locally is no longer enough. Modern automation engineers are expected to understand how tests execute inside GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Docker, and cloud environments.
A production-grade Playwright framework must answer practical questions:
- How are browsers installed?
- How are secrets managed?
- How are tests executed in parallel?
- How are failures diagnosed?
- How are traces and screenshots preserved?
- How are flaky tests controlled?
- How are multiple browsers tested?
- How can CI execution be made faster?
- How does the pipeline prevent a failed test from silently reaching production?
Playwright provides official CI guidance, including browser installation, dependency installation, test execution, and artifact collection patterns. (playwright.dev)
This guide covers Playwright CI/CD Interview Questions and Answers from beginner to Senior SDET and QA Lead level.
What Is CI/CD in Playwright?
CI means Continuous Integration.
Developers frequently push code to a shared repository, and automated checks run against that change.
CD means Continuous Delivery or Continuous Deployment.
After the required checks pass, software can be packaged, released, staged, or deployed automatically.
A Playwright CI/CD pipeline commonly looks like this:
Developer Push / Pull Request
↓
CI Pipeline Starts
↓
Install Node.js
↓
npm ci
↓
Install Playwright Browsers
↓
Run Playwright Tests
↓
┌─────────┴─────────┐
↓ ↓
Pass Fail
↓ ↓
Deploy / Merge Upload Artifacts
The key interview point is that Playwright is one component inside a larger CI/CD system.
Local Execution vs CI Execution
1. Why Can a Playwright Test Pass Locally but Fail in CI?
Question: A Playwright test passes locally but fails in CI. What would you investigate?
Interview-Ready Answer:
I would compare the local and CI environments systematically instead of immediately increasing the timeout. I would check browser versions, Node.js versions, environment variables, authentication state, viewport size, CPU and memory resources, test data, parallel workers, headless mode, network access, and timing dependencies.
Explanation:
Common causes include:
| Cause | Local | CI |
| Browser | Installed | Missing/wrong version |
| Display | Available | Usually headless |
| CPU | Faster | Shared/limited |
| Test workers | Low | Higher |
| Secrets | Local .env | CI secrets |
| Data | Personal/stable | Shared |
| Network | Direct | Proxy/firewall |
| Timing | Fast | Variable |
| Browser version | Current | Different |
YAML Example:
– name: Run Playwright tests
run: npx playwright test
env:
BASE_URL: ${{ secrets.BASE_URL }}
Interview Tip:
Use the phrase “environment parity”. Senior interviewers want to hear that CI should reproduce production-relevant conditions as closely as practical.
Playwright CI/CD Architecture
2. What Does a Typical Playwright CI/CD Pipeline Look Like?
Question: Explain a Playwright CI/CD architecture.
Interview-Ready Answer:
A typical pipeline checks out source code, installs the required runtime and dependencies, installs Playwright browsers, configures environment variables and secrets, runs tests, collects artifacts, publishes reports, and optionally gates deployment on test success.
Explanation:
Git Repository
↓
GitHub Actions / GitLab / Jenkins
↓
Node + npm ci
↓
Playwright Browser Installation
↓
Environment Configuration
↓
↓
Results + Traces + Screenshots
↓
Reports
↓
Deployment Gate
YAML Example:
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
– run: npm ci
– run: npx playwright install –with-deps
– run: npx playwright test
– uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/
Playwright’s CI documentation recommends installing dependencies and browser binaries in the CI environment before executing tests. (playwright.dev)
Interview Tip:
Explain the pipeline as stages rather than simply saying “GitHub Actions runs npx playwright test.
GitHub Actions Interview Questions
3. How Do You Configure Playwright in GitHub Actions?
Question: How would you create a GitHub Actions workflow for Playwright?
Interview-Ready Answer:
I would use a workflow triggered by pull requests and pushes, set up Node.js, cache npm dependencies, install project packages, install Playwright browsers with required system dependencies, execute tests, and upload reports or traces even when tests fail.
YAML Example:
name: Playwright
on:
pull_request:
push:
branches:
– main
jobs:
test:
timeout-minutes: 30
runs-on: ubuntu-latest
steps:
– name: Checkout
uses: actions/checkout@v4
– name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
– name: Install dependencies
run: npm ci
– name: Install Playwright
run: npx playwright install –with-deps
– name: Run tests
run: npx playwright test
– name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
Interview Tip:
Know why if: always() matters: without it, a later artifact-upload step may be skipped after test failure.
Playwright Installation and Browser Setup in CI
4. What Happens If Playwright Browsers Are Not Installed?
Question: Your CI job fails because the Playwright browser executable cannot be found. How do you fix it?
Interview-Ready Answer:
I would explicitly install Playwright’s supported browser binaries during the CI setup. If the environment is Linux-based, I would normally use –with-deps when required system packages are not already available.
YAML Example:
– name: Install Playwright browsers
run: npx playwright install –with-deps
For a specific browser:
– name: Install Chromium
run: npx playwright install –with-deps chromium
Playwright provides browser installation commands specifically for CI environments. (playwright.dev)
Interview Tip:
Mention that browser binaries and OS-level dependencies are separate concerns from installing the npm package.
Environment Variables and Secrets
5. How Do You Handle Environment Variables in Playwright CI/CD?
Question: How would you pass a staging URL to Playwright?
Interview-Ready Answer:
I would use environment variables rather than hard-coding environment-specific URLs into test code.
Playwright Configuration:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
use: {
baseURL: process.env.BASE_URL
}
});
GitHub Actions:
env:
BASE_URL: ${{ secrets.BASE_URL }}
Tests can then use:
await page.goto(‘/’);
Interview Tip:
Separate configuration from test logic. This makes the same test suite reusable across development, staging, and production-like environments.
6. How Should Credentials Be Stored in GitHub Actions?
Question: Where would you store login credentials used by Playwright tests?
Interview-Ready Answer:
Sensitive values should be stored in the CI platform’s secret-management mechanism rather than committed to source control.
YAML Example:
env:
TEST_USERNAME: ${{ secrets.TEST_USERNAME }}
TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
– name: Run tests
run: npx playwright test
await page.getByLabel(‘Username’).fill(
process.env.TEST_USERNAME!
);
await page.getByLabel(‘Password’).fill(
process.env.TEST_PASSWORD!
);
Interview Tip:
Never commit passwords, tokens, private keys, or production credentials to .env files tracked by Git.
Headless Execution and Browser Configuration
7. Why Does Playwright Run Headless in CI?
Question: Why are Playwright tests usually headless in CI?
Interview-Ready Answer:
CI runners typically do not have a normal graphical desktop environment, and headless execution reduces resource consumption. It also makes browser execution suitable for automated servers.
Playwright’s browser configuration supports headless and headed modes. (playwright.dev)
Configuration:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
use: {
headless: true
}
});
For debugging:
npx playwright test –headed
Interview Tip:
Do not assume that a headless failure is necessarily a Playwright bug. Check viewport, timing, browser rendering, overlays, and environment differences.
Parallel Execution and Test Sharding
8. How Do You Run Playwright Tests in Parallel?
Question: How would you configure parallel execution in CI?
Interview-Ready Answer:
I would use Playwright Test workers and ensure that tests are isolated. Increasing workers can reduce runtime, but excessive parallelism can overload the runner or create test-data conflicts.
Configuration:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
workers: process.env.CI ? 4 : undefined
});
Or from the command line:
npx playwright test –workers=4
Interview Tip:
Parallelization is not just a performance setting. Test independence and data isolation are prerequisites.
9. What Is Test Sharding?
Question: How is test sharding different from workers?
Interview-Ready Answer:
Workers execute tests concurrently within a job. Sharding distributes different portions of the overall test suite across separate CI jobs or machines.
For example:
Shard 1 → Tests 1–250
Shard 2 → Tests 251–500
Shard 3 → Tests 501–750
Shard 4 → Tests 751–1000
Playwright supports sharding through the –shard command-line option. (playwright.dev)
YAML Example:
strategy:
matrix:
shard: [1/4, 2/4, 3/4, 4/4]
steps:
– uses: actions/checkout@v4
– uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
– run: npm ci
– run: npx playwright install –with-deps
– run: npx playwright test –shard=${{ matrix.shard }}
Interview Tip:
Use sharding when the suite is large enough that distributing work across CI jobs provides meaningful savings.
Screenshots, Videos, Traces, and Test Artifacts
10. What Artifacts Should You Collect When a Playwright Test Fails?
Question: What Playwright artifacts are useful for CI debugging?
Interview-Ready Answer:
I typically collect the HTML report, trace files, screenshots, videos when configured, and relevant logs. The exact artifact strategy should balance debugging value against storage and execution cost.
Configuration:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
}
});
Playwright supports tracing and test artifacts that can be inspected after execution. (playwright.dev)
GitHub Actions:
– name: Upload Playwright artifacts
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-artifacts
path: |
playwright-report/
test-results/
Interview Tip:
A mature pipeline should preserve enough information to diagnose a failure without reproducing it locally.
HTML Reporting in CI/CD
11. How Do You Publish the Playwright HTML Report?
Question: How do you make Playwright reports available after a CI run?
Interview-Ready Answer:
I configure the HTML reporter and upload its output as a CI artifact.
Configuration:
export default defineConfig({
reporter: [
[‘html’, {
outputFolder: ‘playwright-report’,
open: ‘never’
}]
]
});
GitHub Actions:
– name: Upload Playwright report
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
Interview Tip:
Use open: ‘never’ in CI because there is normally no interactive desktop browser available.
Docker and Playwright CI/CD
12. Why Use Docker for Playwright CI/CD?
Question: What is the advantage of running Playwright in Docker?
Interview-Ready Answer:
Docker provides a controlled and repeatable execution environment. It can reduce differences between developer machines and CI runners by standardizing the OS, Node environment, browser dependencies, and supporting tools.
Playwright publishes Docker images intended for running its tests. (playwright.dev)
Example Dockerfile:
FROM mcr.microsoft.com/playwright:v1.55.0-noble
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD [“npx”, “playwright”, “test”]
Build and run:
docker build -t playwright-tests .
docker run –rm playwright-tests
Interview Tip:
Pin image versions rather than depending indefinitely on latest for reproducible CI.
13. What Would You Do If the Docker Container Fails to Start?
Question: Your Playwright Docker job fails before tests execute. How do you debug it?
Interview-Ready Answer:
I would check the image version, Node/npm compatibility, working directory, copied files, installed dependencies, browser availability, permissions, and the container’s command.
Debugging commands:
docker build –progress=plain -t playwright-tests .
docker run –rm -it playwright-tests bash
Inside the container:
node –version
npm –version
npx playwright –version
npx playwright install –dry-run
Interview Tip:
Separate container startup failures from Playwright test failures. They require different debugging paths.
Test Retries, Flaky Tests, and Failure Handling
14. How Do You Configure Retries in CI?
Question: How would you configure Playwright retries?
Interview-Ready Answer:
I would normally configure limited retries in CI while keeping local development fast. Retries should help diagnose transient failures, not hide legitimate defects.
Configuration:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
retries: process.env.CI ? 2 : 0
});
Interview Tip:
A test that passes only after retry should be tracked as a reliability problem, not considered healthy.
15. How Do You Prevent Flaky Tests From Consuming Excessive CI Time?
Question: Flaky tests are retrying multiple times and increasing pipeline duration. What do you do?
Interview-Ready Answer:
I would identify and classify flaky tests, measure their frequency, isolate common causes, and fix root causes. I would avoid simply increasing retries.
Common causes include:
- shared test data
- race conditions
- fixed sleeps
- unstable selectors
- external dependencies
- poor cleanup
- insufficient isolation
- resource contention
- network instability
Configuration:
export default defineConfig({
retries: process.env.CI ? 1 : 0,
timeout: 30_000
});
Interview Tip:
Use retries as a resilience mechanism, not as a substitute for test engineering.
Caching and CI Performance Optimization
16. How Can You Make Playwright CI Faster?
Question: What would you optimize if Playwright CI takes 40 minutes?
Interview-Ready Answer:
I would measure where the time is spent before changing configuration. Then I would optimize dependency installation, browser setup, test parallelism, sharding, test data setup, redundant authentication, and unnecessary browser launches.
GitHub Actions dependency caching:
– uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
Then:
– run: npm ci
Other optimization techniques include:
- parallel workers
- test sharding
- project-level browser distribution
- API-based setup
- reusable authentication state
- reducing unnecessary UI setup
- artifact optimization
- selective smoke suites for pull requests
Interview Tip:
Optimization should be data-driven. A higher worker count can actually make CI slower if the runner is resource constrained.
Multi-Browser and Multi-Environment Pipelines
17. How Would You Run Playwright Against Chromium, Firefox, and WebKit?
Question: Design a multi-browser CI pipeline.
Interview-Ready Answer:
I would use Playwright projects and a CI matrix where appropriate.
Playwright configuration:
import { defineConfig, devices } from ‘@playwright/test’;
export default defineConfig({
projects: [
{
name: ‘chromium’,
use: { …devices[‘Desktop Chrome’] }
},
{
name: ‘firefox’,
use: { …devices[‘Desktop Firefox’] }
},
{
name: ‘webkit’,
use: { …devices[‘Desktop Safari’] }
}
]
});
GitHub Actions approach:
strategy:
matrix:
browser:
– chromium
– firefox
– webkit
steps:
– run: npx playwright test –project=${{ matrix.browser }}
Interview Tip:
For large suites, don’t blindly run every test against every browser on every pull request. Use risk-based execution where appropriate.
Real-World GitHub Actions Workflow
18. Write a Production-Oriented Playwright GitHub Actions Workflow.
Question: Write a GitHub Actions workflow for Playwright including secrets, retries, artifacts, and reporting.
Interview-Ready Answer:
name: Playwright E2E
on:
pull_request:
push:
branches:
– main
jobs:
test:
timeout-minutes: 30
runs-on: ubuntu-latest
env:
BASE_URL: ${{ secrets.BASE_URL }}
TEST_USERNAME: ${{ secrets.TEST_USERNAME }}
TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
steps:
– name: Checkout
uses: actions/checkout@v4
– name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
– name: Install dependencies
run: npm ci
– name: Install Playwright browsers
run: npx playwright install –with-deps
– name: Run Playwright tests
run: npx playwright test
– name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
– name: Upload test results
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-test-results
path: test-results/
Interview Tip:
Be able to explain every step. Interviewers often use configuration questions to test whether you understand CI rather than whether you can copy YAML.
Scenario-Based Playwright CI/CD Interview Questions
19. Scenario: Browser Is Not Installed
Question: The pipeline reports that Chromium executable is missing. What do you do?
Interview-Ready Answer:
Verify that the Playwright package is installed and execute the browser installation command in the CI job.
Code:
– run: npm ci
– run: npx playwright install –with-deps
– run: npx playwright test
Interview Tip:
Check the Playwright package version and browser installation step before investigating the test itself.
20. Scenario: CI Job Times Out
Question: A Playwright job times out after 10 minutes. What do you investigate?
Interview-Ready Answer:
I would determine whether the timeout is caused by a single hanging test, excessive workers, slow application responses, browser startup, network calls, deadlocks, or insufficient job timeout.
Configuration:
export default defineConfig({
timeout: 30_000
});
GitHub Actions:
jobs:
test:
timeout-minutes: 30
Interview Tip:
Do not simply increase both timeouts. Identify what is consuming the time.
21. Scenario: Authentication Secrets Are Missing
Question: Tests fail because login credentials are undefined in CI.
Interview-Ready Answer:
I would verify that the required secrets exist, are available to the workflow context, and are mapped correctly into environment variables.
env:
TEST_USERNAME: ${{ secrets.TEST_USERNAME }}
TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
Then validate configuration without printing secret values.
Interview Tip:
Never log secret values for debugging.
22. Scenario: Tests Fail Only in Headless Mode
Question: Tests pass headed but fail headless. How do you debug?
Interview-Ready Answer:
I would inspect screenshots and traces, compare viewport dimensions, check overlays and animations, verify element actionability, and reproduce with the same browser/headless configuration locally.
Code:
await page.screenshot({
path: ‘debug.png’,
fullPage: true
});
Interview Tip:
Headless mode changes execution conditions; it should not be treated as merely “the same browser without a window.”
23. Scenario: Parallel Workers Cause Test-Data Conflicts
Question: Tests pass with one worker but fail with four workers.
Interview-Ready Answer:
This strongly suggests a test-isolation or shared-state problem. I would identify shared accounts, database records, files, ports, or mutable backend data.
Temporary diagnostic:
npx playwright test –workers=1
Then fix the underlying isolation issue rather than permanently disabling parallelism.
Interview Tip:
A good framework should be designed for parallel-safe tests.
24. Scenario: Trace Is Not Uploaded
Question: Tests fail, but the trace is missing from the CI artifact.
Interview-Ready Answer:
I would verify that trace collection is enabled, the output is written under the expected directory, and artifact upload runs even when tests fail.
use: {
trace: ‘retain-on-failure’
}
– uses: actions/upload-artifact@v4
if: always()
with:
name: test-results
path: test-results/
Interview Tip:
if: always() is a small but important GitHub Actions detail.
Advanced Enterprise CI/CD Architecture Questions
25. How Would You Design Playwright CI/CD for a Large Enterprise?
Question: Design a Playwright pipeline for thousands of tests.
Interview-Ready Answer:
I would divide execution into risk-based suites, use parallel workers and sharding, isolate test data, standardize browser versions, collect artifacts selectively, and establish CI quality gates.
A possible architecture:
Pull Request
↓
Smoke / Critical Tests
↓
┌──────────┴──────────┐
↓ ↓
Chromium API Checks
↓
Merge Quality Gate
↓
Full Regression
↓
┌──────┼──────┐
↓ ↓ ↓
Shard 1 Shard 2 Shard 3
↓ ↓ ↓
└──────┼──────┘
↓
Report + Trends
↓
Deployment
Interview Tip:
At enterprise scale, focus on observability, isolation, scalability, security, and cost, not just test execution.
26. How Would You Prevent Secrets From Leaking Through Playwright Artifacts?
Question: Screenshots, traces, and videos may contain sensitive information. How would you handle this?
Interview-Ready Answer:
I would avoid using production credentials, mask sensitive UI data where possible, restrict artifact access, minimize retention, and ensure secrets are not printed into logs. Artifact storage should follow the organization’s security and retention policies.
Interview Tip:
Treat test artifacts as potentially sensitive data.
27. Should Every Pull Request Run the Full Playwright Suite?
Question: Would you execute the entire regression suite on every PR?
Interview-Ready Answer:
Not necessarily. I would design a tiered strategy.
| Trigger | Suggested Tests |
| PR | Smoke + impacted tests |
| Main branch | Larger regression |
| Nightly | Full cross-browser suite |
| Release | Full critical regression |
| Scheduled | Extended reliability suite |
Interview Tip:
The goal is fast feedback without sacrificing release confidence.
Common Playwright CI/CD Failures and Debugging
| Failure | Likely Cause | First Investigation |
| Browser executable missing | Browser not installed | npx playwright install |
| Timeout | Slow/hanging test | Trace + logs |
| Auth failure | Missing secret | CI environment |
| Works locally only | Environment mismatch | Node/browser/config |
| Headless failure | UI/actionability issue | Screenshot/trace |
| Parallel failure | Shared state | Test isolation |
| Missing report | Upload skipped | if: always() |
| Docker failure | Image/dependency issue | Container shell |
| Flaky retries | Test instability | Root-cause analysis |
| CI too slow | Poor parallelization | Timing metrics |
| Out-of-memory | Too many workers | Reduce workers |
| Network failure | Proxy/firewall/service | CI network configuration |
Playwright CI/CD Coding and Configuration Questions
28. How Do You Enable Traces Only on CI Failures?
Question: Configure Playwright to collect traces only when useful.
Interview-Ready Answer:
export default defineConfig({
use: {
trace: process.env.CI
? ‘retain-on-failure’
: ‘off’
}
});
Explanation:
This keeps local execution lightweight while preserving CI diagnostics.
Interview Tip:
Artifact collection should be intentional. More artifacts are not automatically better.
29. How Do You Configure Different Base URLs?
Question: How would you run the same suite against staging and QA?
Interview-Ready Answer:
export default defineConfig({
use: {
baseURL: process.env.BASE_URL
}
});
CI:
env:
BASE_URL: https://staging.example.com
For another environment:
env:
BASE_URL: https://qa.example.com
Interview Tip:
Keep environment configuration outside test implementation.
Playwright CI/CD Best Practices Checklist
Before an interview, make sure you can explain:
- npm ci
- Playwright browser installation
- –with-deps
- Headless execution
- GitHub Actions workflow structure
- CI secrets
- Environment variables
- Playwright retries
- Workers
- Sharding
- Browser projects
- Screenshots
- Videos
- Traces
- HTML reports
- GitHub artifacts
- Docker
- CI timeouts
- Test isolation
- Flaky-test management
- Pipeline security
- Performance optimization
- Deployment gates
Playwright CI/CD Interview Preparation Roadmap
Freshers
Focus on:
- What is CI/CD?
- What is Playwright?
- How do you run Playwright in CI?
- What is headless mode?
- How do you install browsers?
- What are environment variables?
- What are CI secrets?
- What is GitHub Actions?
2–3 Years Experience
Prepare:
- GitHub Actions
- Browser installation
- Playwright configuration
- Retries
- Artifacts
- HTML reporting
- Screenshots
- Traces
- Docker
- Environment configuration
- Parallel execution
- CI debugging
4–5 Years Experience
Expect:
- Sharding
- Multi-browser matrices
- CI optimization
- Test isolation
- Flaky-test analysis
- Authentication strategies
- Docker architecture
- Pipeline gates
- Artifact retention
- Security
Senior SDET
Be ready for:
- Enterprise pipeline architecture
- Test-suite partitioning
- CI cost optimization
- Reliability metrics
- Flaky-test quarantine
- Cross-browser strategy
- Secrets governance
- Container standardization
- Test observability
- Release gating
- Failure triage automation
QA Lead
Focus on:
- Quality gates
- Risk-based testing
- PR versus nightly strategy
- Pipeline ownership
- Team standards
- CI reliability KPIs
- Failure trends
- Infrastructure costs
- Security policies
- Release confidence
FAQs: Playwright CI/CD Interview Questions
How do I run Playwright tests in CI?
Install Node dependencies, install Playwright browsers, configure the environment, and execute:
npx playwright test
For GitHub Actions, upload reports and test results as artifacts.
Do Playwright tests need browsers installed in CI?
Yes. The CI environment must have the appropriate Playwright browser binaries available. The standard installation approach is:
npx playwright install –with-deps
Playwright documents browser installation as part of CI setup. (playwright.dev)
Why do Playwright tests fail in CI but pass locally?
Common causes include environment differences, browser versions, headless execution, resource limits, missing secrets, network differences, timing, test data conflicts, and parallel execution.
How do I debug Playwright failures in GitHub Actions?
Collect traces, screenshots, videos when appropriate, HTML reports, console logs, and CI logs. Playwright Trace Viewer is particularly useful for reconstructing failed test execution. (playwright.dev)
Should I use retries in CI?
Limited retries can help with transient failures, but persistent retries should trigger flaky-test investigation.
What is Playwright sharding?
Sharding distributes the test suite across multiple CI jobs. It is useful for reducing wall-clock execution time on large suites. (playwright.dev)
Is Docker required for Playwright CI/CD?
No. Playwright can run directly on CI runners. Docker is useful when you want a standardized and reproducible execution environment.
How should Playwright secrets be managed?
Use the CI platform’s secret-management mechanism. Do not commit credentials to Git or expose them in logs or artifacts.
How many Playwright workers should CI use?
There is no universal number. It depends on CPU, memory, browser count, application capacity, test isolation, and CI runner limits.
Should I run all browsers on every PR?
Not necessarily. A common strategy is fast critical coverage on pull requests and broader cross-browser regression on main, scheduled runs, or release pipelines.