Merging Playwright Reports in GitHub Actions Workflows After Sharding

In this video, we show you how to use Playwright to run tests in parallel and combine the resulting reports into a single report. Running tests in parallel can significantly speed up your test execution, but the challenge is that you end up with multiple reports that need to be combined in order to get a complete overview of the test results.

We demonstrate how to use GitHub Actions and the "merge-playwright-reports" library to automate this process, allowing you to easily merge your Playwright reports within a continuous integration workflow. This is especially useful when running tests on GitHub Actions, as it provides access to a wide range of computing resources that can be used to run tests in parallel.

By the end of this video, you will have a better understanding of how to use Playwright's sharding feature to parallelize your test execution, and how to merge the resulting reports using GitHub Actions and the "merge-playwright-reports" library.

If you want more content, check out website!

Want to skip learning Playwright and have us help out? Reach out today!

[olegpe]

Great one, Thanks! Hope to see more playwright/githubActions tricks. Maybe you have a solution of having some kind of a dashboard or something to be able to see and compare the history of test runs 🙂

[nikolaypetrov]

Hi, is there any way of Github showing directly the output (in my case only .html) instead of zip-ing the file/s?

[chrisoneal]

Thanks for sharing this video plus the other one about publishing reports:

I have a question about how you determine when to introduce sharding to the CI workflow? I ask because I've been able to run 8-10 parallel workers in headless mode with consistent success and have felt like that's 'efficient enough'. Doing some research there's not a lot of info out there to indicate when you've maxed your compute power locally, or on a VM. I've always thought I might introduce sharding once the machine couldn't handle what I asked... similar to Performance testing. Unless you've structured a test project to utilize almost as many unique users on your app as you do total workers, I would think running an enormous amount of parallel workers would introduce significant data collision on the front-end (ie user expects something on the page, it changes index or is no longer there bc the same user from a test run in parallel updated the page etc). (I know Playwright discourages using the same user multiple times in a test suite, it's just not always practical).

Anyway, love to hear your thoughts!