GitHub Actions and Argos CI | Bondar Academy
Course: Playwright UI Testing with TypeScript
Module: Advanced Tricks and Techniques
Instructor: Artem Bondar
Lesson Summary
In this lesson, we will run the PwPracticeApp application on the GitHub CI pipeline using GitHub Actions and perform visual testing with Argos CI . Prerequisites Upload your PwPracticeApp project to your own GitHub repository. Use the command git remote set-url origin [repository URL] to set up your remote repository. Configuring GitHub Actions To configure your project for GitHub Actions: Create a folder .github/workflows in the root of your project. Create a file named playwright.yaml inside this folder. Paste the recommended configuration from the Playwright documentation. Modify the configuration to use Node 20 and set up the test commands. Push your changes to the master branch, and GitHub will automatically run your tests. Integrating Argos CI Argos CI is a tool for visual testing that integrates seamlessly with GitHub. To set it up: Create an Argos CI account using your GitHub account. Install the necessary package in your Playwright configuration. Adjust the playwright.config.ts to include the Argos CI reporter. Running Visual Tests After making UI changes, create a pull request to trigger the visual tests. Argos CI will compare new screenshots with the baseline and notify you of any changes. You can approve or reject these changes based on the visual differences detected. This integration ensures that visual changes are monitored, enhancing the quality of your application. For more details, refer to the provided documentation links.
Video Transcript
In this lesson, we will run our PwPracticeApp application on GitHub CI pipeline using GitHub Actions. And after that, we will use a second service called Argos CI to make a visual testing for our builds. So let's get into it. As a prerequisite, you need to upload your current PwPracticeApp project to your own repository on the GitHub. For this demonstration, I created a new repository called PwPracticeApp CI. You need to create your own and push your project to your own repository. How to do this, you can find in this blog post that I created with the git commands. So you need to know how to set up a remote repository. So when you create a new repository inside of your project, you will need to execute this command. git remote set url origin and put the URL to your repository. Then push your code to a remote repository and it will show up under GitHub. This is what you need to do. The link to this article will be attached to the lesson. All right, so next step, we need to configure our project to run in GitHub Actions. How to do that? We go to Playwright documentation and here is CI GitHub Actions article related to this. It is very straightforward process. So first of all, we need to create this folder .github-workflows in the root of the project. So going back to the project and I create a new folder. And inside of this folder, I need to create a new file and give it any name, but I will call it playwright.yaml. And then inside of this file, I need to paste the recommended configuration right here. So just copy this entire code. Control C and paste it right here. Control V. That's it. So now we need just to make a little configuration. The branches that will be used for the push and pull request main and master. So we will not change this. We are currently on the master branch. The next step here is the steps to install the node version. Instead of node 18, we will use node 20. Then command run npm ci. We need to add a force flag just to avoid the dependencies conflict inside of our project. Then here, the next step is install playwright. We need to add force as well. And here, instead of the command npx playwright test, I would like to run test for the single spec file just for demonstration. Use page object dot spec dot ts. And earlier, we created an npm script that is responsible for this execution. Is this npm script? So I will just use this page objects Chrome script. Go here and change it to npm run and the name of the script. And that's pretty much it. So now we need to push these changes to the master branch, and GitHub should automatically pick up this configuration file and run our test on the GitHub CI. And you know, one more thing. Instead of running both of those tests, let me create a simple placeholder single test. I will put it dot only with a name testing with Argos CI. And instead of navigating to all pages, we will just navigate to form layouts page and date picker page. For our demonstration, it will be more than enough. So when we push this code to the remote repository, this test have to be executed because we specified in the playwright YAML that we want to run npm run page objects Chrome script. So let's make a commit. Added new test. Commit and push. Okay, going back to GitHub. And if I navigate here to the action step, we have this new action is triggered in. Added new test. Clicking on this. Opening, and you can see the job is setting up. Installing the needed dependencies and all other required steps mentioned in the YAML file will be executed. Installation dependencies, browsers, then run the test, and then tear down process. So we need to wait a little bit. It takes some time. All right. So this job was completed successfully. We can see that one test was executed. It's passed, and everything worked as expected. And if we go back to the summary of this execution, let me open one more time, you can see the playwright report was attached as an artifact automatically, so you can download this report and review in case the tests were failed. So integration of the playwright and GitHub actions is a very straightforward process. And now let's add into this integration one more component, which is visual testing with Argos CI. So Argos CI is a very nice tool for visual testing. It has a great integration with GitHub and GitLab, and very nicely and seamlessly integrated with playwright, Cypress, and other popular frameworks. And also the pricing for this product is actually very attractive. So for the personal projects, it's free. It's up to 5,000 screenshots you can do for free. And if you are running, for example, a corporate project or something, then $30 per month is a very affordable option as well. So you need to create a new account. So you need to click sign up. And the best way would be to use your GitHub account. So you need to provide a name and continue with GitHub. That way you will integrate the Argos CI with GitHub account, and you will not need to do anything else by providing the tokens or something like this. And the process of doing this is very straightforward. So I will not show it over here. I just log into the account that I already created. So I log in, continue with GitHub, and log in into my dashboard. So when you create a new account and integrate with your GitHub account, you will see the project that you are integrated from the GitHub. In my example, I already integrated PwPracticeApp CI project, which is exactly the same project, which is this one, PwPracticeApp CI. Now we need to make some little adjustments to our playwright configuration to make this integration actually happening. And GitHub actions build will send the screenshots to Argos CI dashboard. So we need to open documentation. And here is quick start for the playwright. You can see the playwright, cypress, webdriver.io, and other projects. You can look for this documentation. So playwright, and the steps are pretty straightforward. First of all, we need to install this package into our framework. Going back to the framework, opening new. And also I will need to add command in my example, force, and hit enter. All right, first step is completed. The next step, we need to configure playwright.config.ts. So inside of the reporter, we need to add this process envci.enlistreporter. So let's open the playwright.config reporter. And we need to add inside of the reporters array. And then we need to add this second portion inside of the reporter as well. So hit enter and enter here as well. We don't need to provide token because we already integrated with GitHub directly, with GitHub actions. But if you use GitLab, for example, or any other CI, you may need to provide a token, not in our example. So I delete the token. It's not needed. So moving on, we need to add in the use block trace on first retry. I believe we already have it. Use block trace on first retry and screenshot only on failure. And we need to add screenshot only on failure. The next step. And the next step is pretty much use the screenshots inside of your test. So inside of the spec file where we want to use, we need to add the import. And we will use it right here. So I add import. And then we pretty much use this method after the step where we want to create the screenshot. So our test currently have two steps. So let's create this step over here. Form layouts page. And the second step will be here. And it will be date picker page. And yeah, I believe that's it. So let's push those changes to remote repository. And let's see what's going to happen on GitHub Actions. So I create a new commit. Edit Argus CI configuration. Commit and sync changes. Going back to GitHub Actions. And we can see that new build just started. So we need to wait the completion of this build. All right. This build was completed. It took about three minutes to complete. I just speed up the process to make it more engaging. And we going back to Argus CI. I opened the project. And we see the first build is pushed over here. And it called reference build. So let's open it. So the reference build created for us first two screenshots. The first screenshots of the date picker page. And the second screenshot of the form layouts page. So now for each new build, Argus CI will compare the new screenshots to this reference build. And if something went wrong, it will tell us, hey, there was a change. Please review those changes. And let me simulate this situation, how it would be done in the real life, on the real time development. So I will create a new branch, first of all. Create a new branch. And let's say I call it update UI. Let's say we want to modify some changes. And since we have access to the source code of our applications, let's make some changes. So application pages, forms. Where is form layouts? This is our form layouts page. Is it? Yeah. Inline form. This is form layouts page. So let's say that for the form layouts page, we will change the color of the button. So instead of the blue color, how it is right now. So first of all, let me run the application. So I will show you. NPM start. Okay. And I open on the localhost. Form, form layouts. So we are working with this inline form. So let's update the color of this submit button. Let's say our UX designer is working on some changes, and he decided to update from primary to success. So let's update this code going back. And now you see our button is changed this look and feel it. Now it's a green color. Now go back to the date picker page, and let's modify this page a little bit as well. So where's the date picker page? Date picker, date picker component HTML. Let's say we will delete this date picker with range. And refresh. Let's see. Okay, it's deleted. And we will make this date picker wider on this page. So let's modify this class. It should be eight and eight over here. And now it should become bigger. Here we go. So now we modified the design. We deleted one of the calendars, and we also increased the size of this calendar. And let's say the developer who was working on those changes decided this is design that we are needed, and create a new commit. Update it. Design. Commit. And we push this branch to GitHub. Update UI. Now going back to GitHub. Here's the GitHub going to the code. And we have a new branch which is just created, right, with the changes. On the GitHub actions, nothing yet happens. Because our GitHub actions triggered to run the test from the master branch on changes to the master branch and on pull request. So when we create a pull request, this modification will be triggered. The test execution will be triggered. So I create a pull request. And this is the changes of the code that were done. This one was changed, and the color was changed for the button. And I click create pull request. So now let's go back to actions. We can see that new action is triggered from update UI branch right now. And inside of the pull request, we see that this build is happening. So let's wait until it will be completed. All right. The build is completed. We can see the check mark over here. And also we see an update in the user interface. So Argus CI has a bot integrated in the GitHub which is saying the details about the execution and saying that two changes were detected. And because it was detected, the second check did not pass. And because the project is configured the way that all checks must be passed before you can merge the branch, this will not let you to merge the branch without approving the visual changes. So now you just can click on this review. And it will open there. Let me open this in a new tab. It will be better. So I click on the review. And now you can review what's actually changed. So screenshot number one and screenshot number two. So the screenshot number one is the baseline. This is how it's supposed to be. And this is the changes. Now you can see the red is highlighted what was changed. You can see the design is different. And you can see it like this baseline and the changes coming from the update UI. Or you can look at side by side. And the second example of the inline form. So this is the baseline on the master branch. And this is the updates coming from update UI. And now in this example, the submit is highlighted in red. Because Argos CI identified that something changed with this button. You need to review. Additionally, you have this kind of information. The page where it was located. The code where exactly it's located. So if you click on this URL, you can see exactly the test where it was executed. And you can review those changes. And this is how you compare the screenshots. And now the next step. You can see it also says changes detected. If I go back, the dashboard is showing the pull request. Showing the branch name and the commit SHA. And also the changes are detected. Now you're reviewing all those screenshots. And then it's up to you. Either approve those changes or reject those changes. So if this is something that is expected, for example, to change the design of the button, you say, all right, I approve the changes. You click approve. And these new screenshots becomes your new baseline. So we're going back. And yeah, those are approved. We're going back over here. And now we can see, show all checks. Now we can see that Argos also showing the check mark. So everything worked as expected. And we can safely merge this pull request. Or on the other side, you can reject those changes if you think that something is wrong. And then you can investigate and maybe ask the developer to update the changes to this UI branch. So this is how this integration works nicely. Now every time someone creates pull requests to update the changes to the application, the visual testing will protect the application from some of the changes that probably you forgot to put the assertions for, especially the visual changes. If something like that is broken, Argos CI will catch it for you. And you will see it in the pipeline on the GitHub Actions. All right, that's it, guys. And see you in the next lesson.