Generate Playwright Snapshots on your CI Server

Share this video with your friends

Send Tweet
Published a year ago
Updated 11 months ago

In this lesson we look at why you would need to generate snapshots on your CI server. We follow this up by creating a simple Github Action that will generate new snapshots against a pull request once you leave a specially formatted "slash command" style comment.

Instructor: [0:00] When we only generate screenshots on our Mac OS X system, and then push those changes over to GitHub, the test will not pass because when we look at the test details, you can see that it's looking for a screenshot with a Linux suffix.

[0:13] Now, in order to generate the screenshots, we could run Ubuntu locally in a Docker container or alternatively, we can update our test runner to run Mac.

[0:21] The simplest solution is actually to use the test runner on GitHub to generate the screenshots and provide them in a new commit.

[0:27] That is what we will do in this lesson. We want this new commit to automatically trigger a rebuild of the Playwright tests and that will not happen, if this commit comes from GitHub actions.

[0:37] It has to come from our account, so we will generate a new personal access token, give the token, whatever name you want.

[0:44] I'm just calling it the same name as the repo and then give it repo access in order to allow it to make commits to our repositories.

[0:50] Now, once we've generated this token, you can go ahead and copy it and then move it into your repository, go into the settings, secrets, actions, and then add a new secret.

[1:02] Now, we are going to securely store the token that we copied under the name, ghactiontoken. Now, when we will commit the screenshots with this particular generated token, it will trigger a rebuild of the Playwright tests.

[1:14] Now, we will be triggering a build that will generate the snapshots by leaving a comment on any given pull request. Now, by default, these actions will run against the main branch.

[1:23] As you can see, over here with the GitHub ref, so we will need to add some simple logic within our workflow file so that we check out the pull request branch.

[1:32] Let's jump back to our IDE and create this update snapshots workflow. We give it a decent name and then we want to trigger it, whenever there is a new comment created on an issue.

[1:43] Within the workflow, we have a simple job called /command, and the first thing that we will do is to make sure that it is a pull request and not an issue.

[1:52] The comment that was added is /update snapshots. We will use the same time out as a standard built, which is 60 minutes. We will use the same OS, which is Ubuntu latest.

[2:02] Now, the first few steps are going to be managing Git as we discussed. We will use our own personal token and not use the default GitHub action because when we make the commit, we want it to trigger another build.

[2:14] The other thing that we are going to do is that we are going to check out the branch that is related to this particular issue comment.

[2:20] With these steps run, the rest of the workflow is going to be pretty simple. You set up node with the same version as the standard build, run npm-ci as the standard built, npx playwright installed with deps as the standard build.

[2:34] Then, here's the modification, we run npx playwright test, but this time with update snapshots. Additionally, we're using the list reporter, just we can see any issues in line instead of having to download the artifacts.

[2:48] Finally, we use this GitHub action provided by Stefan, which automatically commits any changes that are in the current Git directory. We are providing a custom message called update snapshots.

[2:59] To demonstrate the workflow of updating the snapshots from GitHub, let's modify our button and add a row after playwright is awesome.

[3:07] Now, when we push this over to GitHub and create a pull request, with just this particular code change, the standard playwright build will get initiated.

[3:15] Of course, we expect this particular build to fail as the existing snapshots do not contain these rows. Of course, after a certain amount of time, the build fails exactly how we expected.

[3:27] Now, to generate new snapshots using the GitHub test runner, we leave a comment with the text /update-snapshots. This comment will trigger the workflow that we just created.

[3:39] We can see that, within the actions panel and within the actions, the particular workflow we are looking for is update snapshots. It contains the one job that we created which is the /command.

[3:49] You can see that it is already running through the steps that we created in the workflow file. Now, once this command completes, it pushes a new commit back to our pull request with the text update snapshots.

[4:00] Because this is pushed with our GitHub token, it will trigger a rebuild in the Playwright test. Of course, this time, those Playwright tests will pass because this pull request contains the updated snapshots.

[4:12] We can see this Linux image within the update snapshot commit, which is exactly what we wanted.

[4:19] Now, we can jump back to our pull request, and if we are happy with everything, we can merge it into main so that it continues to be validated in future work.

[4:29] Now, one final note, we are using this update snapshots just to update the Playwright snapshots, which you could easily extend it to update snapshots for any other testing framework that you might also be using within your code.

[4:41] You don't need to memorize this workflow file. You can copy it from the project that is linked in the video description.