PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Run Playwright in CI/CD with a deliberately reproducible sequence: install the locked Node dependencies, install the matching Playwright browsers and Linux packages, run with one worker initially, enforce a Playwright-level globalTimeout, and publish reports and traces as artifacts. GitHub Actions expresses that sequence in workflow YAML; Harness uses the same commands inside a CI Build stage and Run steps. Once the single-job baseline is stable, add matrix jobs or --shard=x/y for throughput, write blob reports, and merge them into one HTML report. This guide shows the complete setup, including timeouts, artifact security, Harness shared paths, and recovery paths for common failures.
What does Playwright need in a CI/CD job?
A CI runner needs more than your test source. It must have a compatible Node runtime, the exact project dependencies from the lockfile, Playwright browser binaries, and the operating-system libraries those browsers require. A job that installs only npm packages can fail with missing executables or shared libraries even though the same tests pass on a developer laptop.
The minimum execution sequence
- Check out the repository. The runner needs the test code, lockfile, Playwright configuration, and any application fixtures.
- Install project dependencies. Run
npm ciso the lockfile, rather than a fresh dependency resolution, controls the install. - Install browsers and OS dependencies. Run
npx playwright install --with-depson a Linux runner, or use a Playwright Docker image that already contains the required system packages. - Run the suite. Start with
npx playwright testand one worker in CI for stable, reproducible execution. - Publish diagnostics. Upload the HTML report and, when configured, traces, screenshots, videos, and JUnit XML even when tests fail.
Keep the Playwright npm package and the browser image or installed browser revision aligned. Pinning both where practical prevents a base-image update from changing the browser independently of the package reviewed in your lockfile.
How should I make the Playwright environment reproducible?
Choose either a maintained Playwright Docker image or a clean Linux runner with npx playwright install --with-deps. The image reduces setup drift; explicit installation is easier when your CI platform controls the base image or when you need a custom toolchain.
#1 Best Overall
Playwright image versus dependency installation
| Approach | What the job does | Strength | Watch for |
|---|---|---|---|
| Playwright Docker image | Runs the job in an image containing browsers and their system libraries. | Fast, repeatable browser setup across runners. | Pin the image version alongside the Playwright package; changes to the image are still release changes that should be reviewed. |
| Linux runner plus install command | Runs npm ci, then npx playwright install --with-deps. |
Works with GitHub-hosted, Harness, Kubernetes, and self-hosted infrastructure without requiring a special image. | Browser downloads add setup time, and the runner must permit the package manager to install OS dependencies. |
Runner prerequisites
- A supported Node.js version that matches the project and the lockfile.
- Network access to the npm registry and Playwright browser downloads, or an internally managed cache or mirror.
- Permission to install Linux packages when using
--with-deps. - Enough disk space for browsers plus report attachments.
- A trusted artifact store for reports and traces.
Do not silently substitute a global Playwright installation for the project dependency. The npx command should resolve the version declared by the repository so local and CI runs use the same test runner.
Which Playwright settings are safe defaults for CI?
Start with one worker, a finite suite-wide timeout, an HTML reporter for a single job, and failure-only traces. These defaults favor a complete, inspectable result over maximum parallelism while you establish that the pipeline itself is sound.
Set workers and a global timeout
Playwright’s CI guidance recommends setting workers to 1 to prioritize stability and reproducibility. Parallel workers can contend for CPU, memory, test data, or a shared development server; add concurrency later through sharding or a controlled matrix.
Set globalTimeout in playwright.config.ts. Without an upper bound, the CI provider can terminate a hung or unexpectedly long suite before Playwright writes its report. Set the provider’s job timeout comfortably above this value so Playwright has time to finalize reporters and upload steps can run.
Use reporters that match the execution model
- One job: use the HTML reporter for an interactive report. Add JUnit if your CI test-results view consumes XML.
- Sharded jobs: use the
blobreporter in each shard. Blob output contains the data and attachments needed for a later merge. - Diagnostics: set
trace: 'retain-on-failure'(or the equivalent language setting) so failed tests retain a trace without generating a large trace for every passing test.
Example CI-oriented configuration
import { defineConfig } from '@playwright/test';
export default defineConfig({
testDir: './tests',
workers: process.env.CI ? 1 : undefined,
globalTimeout: 30 * 60 * 1000,
reporter: process.env.CI
? [['blob'], ['junit', { outputFile: 'test-results/results.xml' }]]
: [['html', { open: 'never' }]],
use: {
trace: 'retain-on-failure',
},
});The timeout in this example is a starting policy, not a universal limit. Set it from the suite’s expected duration and keep the CI job limit higher. If you use blob reports for every CI run, select that reporter through an environment variable or a separate configuration profile rather than accidentally generating incompatible output.
How do I run Playwright in GitHub Actions?
Create a workflow that triggers on pushes and pull requests, installs the lockfile dependencies and browsers, runs the suite, and uploads the report whether the tests pass or fail. The following baseline follows the official workflow pattern; action major versions and retention settings should be checked against current GitHub Actions documentation before rollout.
Single-job workflow
name: Playwright Tests
on:
push:
branches: [main, master]
pull_request:
branches: [main, master]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: lts/*
- name: Install dependencies
run: npm ci
- name: Install Playwright browsers
run: npx playwright install --with-deps
- name: Run Playwright tests
run: npx playwright test
- uses: actions/upload-artifact@v5
if: ${{ !cancelled() }}
with:
name: playwright-report
path: playwright-report/
retention-days: 30What each step accomplishes
- Triggers: pushes to the protected branches and pull requests run the same validation before merge.
- Checkout: obtains the exact commit being tested.
- Node setup: selects the project runtime; replace
lts/*with a pinned version when your support policy requires it. - npm ci: fails if the lockfile and package manifest disagree, exposing dependency drift early.
- Browser installation: installs Playwright’s browser binaries and Linux dependencies.
- Test command: uses the repository’s Playwright configuration and exits nonzero on a failed test.
- Artifact upload: the
!cancelled()condition preserves the report after ordinary test failures while skipping uploads for a manually cancelled job.
The example uploads the HTML directory for a single job. If your configuration writes JUnit XML, traces, screenshots, or videos outside that directory, add those paths as separate artifacts or include them in a deliberate artifact layout. Keep retention at the shortest period that still supports debugging and compliance; 30 days is only the example value shown above.
Recommended Free Tools
How do I shard Playwright tests in GitHub Actions?
Use a matrix to create identical jobs with different shard coordinates, invoke npx playwright test --shard=x/y in each job, and upload each shard’s blob directory under a unique artifact name. A dependent merge job downloads every blob and runs npx playwright merge-reports --reporter html ./all-blob-reports.
Shard workflow
name: Playwright Shards
on:
push:
branches: [main, master]
pull_request:
branches: [main, master]
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shardIndex: [1, 2, 3, 4]
shardTotal: [4]
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps
- name: Run shard
run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
- uses: actions/upload-artifact@v5
if: ${{ !cancelled() }}
with:
name: blob-report-${{ matrix.shardIndex }}
path: blob-report/
retention-days: 30
merge:
if: ${{ !cancelled() }}
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: lts/*
- run: npm ci
- name: Download shard reports
uses: actions/download-artifact@v5
with:
pattern: blob-report-*
path: all-blob-reports
merge-multiple: true
- name: Merge reports
run: npx playwright merge-reports --reporter html ./all-blob-reports
- uses: actions/upload-artifact@v5
with:
name: playwright-report
path: playwright-report/
retention-days: 30Why fail-fast: false matters
With fail-fast enabled, one failing shard can cancel its siblings before they upload their blobs. Set fail-fast: false when the merge job must collect diagnostics from every shard. The merge job should run after the matrix completes, including partial failures, so the combined report shows which shard failed and preserves the attachments that did arrive.
Shard sizing decisions
- Keep the total shard count small enough that each job has meaningful work; an excessive count increases setup and artifact overhead.
- Use the same browser and configuration in every shard unless you are intentionally combining sharding with a browser matrix.
- Ensure every artifact name includes the shard index. Reusing one name can overwrite or conflate outputs.
- Do not open the HTML report in each shard. Generate it once after merging to avoid duplicated reports and confusing links.
How do I set up Playwright in Harness CI?
In Harness, map the same shell commands into a CI Build stage: choose build infrastructure, add Run steps for dependency installation, browser installation, and testing, then publish the resulting directories. Shared Paths keep reports and blobs available to later steps during that stage.
Build the single-job pipeline
- Create a CI Build stage. Select the repository and commit or branch source, then choose the build infrastructure: Harness Cloud, Kubernetes, or another supported target available to your organization.
- Provide a Node-capable image or runner. Use a Playwright image, or a Linux environment where
npx playwright install --with-depscan install system packages. - Add the install Run step. Run
npm cifrom the repository root. - Add the browser Run step. Run
npx playwright install --with-deps. If the image already contains the required browsers and libraries, keep the step as an explicit version check or omit the download only when that image is pinned and governed. - Add the test Run step. Run
npx playwright test, or use the shard command described below. - Define Shared Paths. Point them at
playwright-report,blob-report,test-results, and any trace directory that a later step must read. - Publish artifacts. Configure the Harness artifact or output mechanism to collect those paths after the test step, including failed-test cases.
Shared Paths persist files between steps for the lifetime of the stage; they do not automatically make files available to a later pipeline stage or an unrelated job. If a later stage needs the report, explicitly publish it from the Build stage and download it there.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsRepresent the pipeline as YAML when governance matters
Harness offers Visual and YAML editors. The Visual editor is useful for inspecting a pipeline, while YAML stored in Git gives code review, history, branch-based changes, and repeatable promotion. Whichever editor you use, keep the Playwright command in one Run step and pass browser, shard index, and shard count as variables rather than copying slightly different commands into many steps.
How can Harness split browsers, platforms, or shards?
Harness looping strategies can create a matrix for browser and platform combinations or split a test suite across multiple jobs. Define the dimensions once, expose them as stage or matrix variables, and let one Run step consume those variables.
Typical matrix variables
| Variable | Example value | Use in the command |
|---|---|---|
| Browser | chromium, firefox, or webkit |
Select the Playwright project or environment variable used by your configuration. |
| Shard index | 1 through the selected total |
First part of --shard=${SHARD_INDEX}/${SHARD_TOTAL}. |
| Shard total | A fixed total such as 4 |
Second part of the shard coordinate. |
| Platform | A runner or image label | Select infrastructure or a platform-specific project. |
Do not combine every browser, operating system, and shard count by default. A four-browser by three-platform by four-shard matrix creates 48 executions before retries and setup. Start with the dimension that answers a real compatibility question, then expand when the reporting and artifact costs are understood.
What should Playwright CI publish, and how should it be secured?
Publish the HTML report for human diagnosis, JUnit XML when a CI test-results view consumes it, and failure diagnostics such as traces, screenshots, and videos according to your retention policy. Playwright’s CI guidance warns that reports and traces must go only to trusted artifact stores or be encrypted before upload.
Artifact layout that stays understandable
playwright-report/— the final HTML report for a single job or merged shards.blob-report/— per-shard input tomerge-reports; do not present this as the final human report.test-results/— JUnit XML and per-test attachments when configured.trace/or the configured test-results subdirectories — retained traces, screenshots, and videos.
Security checks before upload
- Keep API keys, cookies, bearer tokens, and credentials in CI secrets, never in test output.
- Review authenticated-page screenshots and traces for customer data before making artifacts broadly visible.
- Restrict artifact access to the repository or project roles that need it.
- Use encryption when the artifact store is not already trusted by your security policy.
- Set expiration and deletion rules; indefinite retention increases exposure and storage obligations.
A trace can contain the full DOM, network details, and page content from the failed test. Treat it as sensitive application data, not as a harmless log file.
How should timeouts, retries, and provider limits interact?
Playwright should own the suite deadline, while the CI provider’s job timeout remains higher. This lets Playwright stop cleanly, write the report, and execute upload steps instead of being terminated by the provider mid-test.
Set the three relevant limits
- Per-test timeout: catches an individual test that is waiting on a page, locator, or fixture.
- Playwright global timeout: caps the complete suite, including all tests in that job or shard.
- Provider job timeout: must exceed the global timeout plus installation, report finalization, and upload time.
Retries can help distinguish transient infrastructure failures from deterministic defects, but they also increase runtime and can hide flaky tests. Keep retries intentional, record them in your test-results view, and use traces on the final failure so a retry does not erase the useful first failure context.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What are the most common CI failures and fixes?
| Symptom | Likely cause | Fix |
|---|---|---|
Executable doesn't exist or browser launch failure |
Browser binaries were not installed, or the package and image revisions do not match. | Run npx playwright install --with-deps or use a matching Playwright image; verify the project package is the one resolved by npx. |
| Missing shared-library errors on Linux | The runner lacks browser OS dependencies. | Use --with-deps with permission to install packages, or move to an image that includes them. |
| Tests pass but no HTML report appears | The reporter path differs from the uploaded path, or the job was cancelled before the upload condition ran. | Check the reporter configuration and upload the actual directory; use a failure-safe condition such as !cancelled() for ordinary failures. |
| Merge job reports no tests | Shard jobs uploaded HTML instead of blob output, used inconsistent directories, or artifact downloads were incomplete. | Set the CI reporter to blob, give each shard a unique artifact name, download all blobs into one directory, and merge that directory. |
| Only one shard’s files are present | Artifact names collided or matrix jobs were cancelled early. | Include the shard index in every artifact name and set fail-fast: false when complete collection is required. |
| Harness step cannot find a report | The file was written outside a Shared Path or a later stage assumed stage-local files were global. | Place report and blob directories under Shared Paths for same-stage consumers; publish and explicitly transfer files for later stages. |
| CI kills the job without a report | The provider timeout is shorter than the suite or the suite has no Playwright global timeout. | Set globalTimeout and make the provider limit longer than it, including setup and upload overhead. |
| Local run passes while CI is flaky | Too many workers, shared test data, resource contention, or an environment difference. | Use one worker as the baseline, make test data isolated, pin the runtime and browser environment, then add controlled sharding. |
Which CI execution model should I choose?
Use the simplest model that meets your feedback-time requirement. A single worker is the stability baseline; sharding and matrices add throughput or coverage but also multiply setup, artifact, and infrastructure work.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Model | Best fit | Diagnostics | Main trade-off |
|---|---|---|---|
| One job, one worker | New pipelines, small suites, or unstable environments. | One HTML report, optional JUnit and failure traces. | Longest wall-clock runtime. |
| Sharded jobs | A large suite that uses one browser configuration. | Blob reports merged into one HTML report. | More jobs, downloads, and artifact coordination. |
| Browser matrix | Cross-browser compatibility is the primary question. | Separate reports per combination or a deliberate aggregation step. | Each browser multiplies execution and retention. |
| Browser plus platform matrix | You must validate distinct operating systems or runner images. | Label artifacts with both dimensions and preserve failed combinations. | Highest infrastructure and maintenance cost. |
Infrastructure ownership is another deciding factor. GitHub-hosted runners minimize server administration; Harness Cloud and Kubernetes integrations centralize pipeline controls; self-hosted runners provide network and hardware control but make patching, browser dependencies, capacity, and isolation your responsibility.
How should I govern the pipeline over time?
Store the workflow or Harness YAML with the application code, review changes to browser and action versions, and keep the command path identical between local development and CI. Treat the Playwright package, browser image, Node version, runner image, and action majors as a tested set rather than unrelated upgrades.
Review checklist for every change
- Does
npm cistill install from the updated lockfile? - Do the selected image or
--with-depspackages provide the browsers required by the Playwright version? - Is
globalTimeoutlonger than the normal suite but shorter than the provider job limit? - Will failed tests still upload reports and traces?
- Are artifact paths and retention appropriate for the data they contain?
- For sharding, do all jobs use the same shard total and a unique artifact name?
- For Harness, are files that cross Run steps under Shared Paths?
- For matrices, can an engineer identify browser, platform, and shard from the job and artifact names?
How can GitHub Actions metadata be sent to Harness SEI?
Harness documents a GitHub Actions step that posts artifact metadata to its SEI endpoint with an API key stored in GitHub secrets. Use that integration only when your organization needs cross-tool artifact or engineering-insight reporting; it is separate from running Playwright itself.
Keep the API key in repository or organization secrets, restrict its permissions, and avoid printing the request or response body in logs. The Playwright test and artifact steps should remain useful even if the metadata-posting step is unavailable, so make the integration nonessential to test execution.
Frequently Asked Questions
Can I cache Playwright browsers between CI jobs?
Caching can reduce repeated downloads, but the cache key must include the Playwright package or browser revision and the runner environment. If a cache is stale or unavailable, the pipeline should still be able to run the explicit browser-install step rather than failing on a missing executable.
Should pull requests run the full browser matrix?
Many teams run a fast, representative job on every pull request and reserve the complete browser or platform matrix for protected branches or scheduled validation. Make that policy explicit so a green pull request does not imply coverage that the workflow did not execute.
How do I diagnose a failure that happens only on one shard?
Open the merged report and identify the shard and test project, then inspect that shard’s retained trace and video before rerunning the entire matrix. Reproduce with the same shard coordinate and browser configuration locally or in a temporary CI job to separate ordering and data-isolation defects from runner-specific problems.
What should be versioned with a Harness pipeline?
Keep the pipeline YAML, Playwright configuration, lockfile, and any Docker image reference under reviewable version control. Also document the selected build infrastructure and required secret names so a new project or runner can be recreated without relying on settings hidden only in the Visual editor.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
