{"id":27315,"date":"2021-03-01T20:37:37","date_gmt":"2021-03-01T20:37:37","guid":{"rendered":"https:\/\/app14743.cloudwayssites.com\/?p=27315"},"modified":"2021-03-03T21:11:28","modified_gmt":"2021-03-03T21:11:28","slug":"github-actions-with-cypress-and-applitools","status":"publish","type":"post","link":"https:\/\/app14743.cloudwayssites.com\/blog\/github-actions-with-cypress-and-applitools\/","title":{"rendered":"How to Setup GitHub Actions with Cypress & Applitools for a Better Automated Testing Workflow"},"content":{"rendered":"\n

Applitools provides a number of SDKs that allows you to easily integrate it into your existing workflow. Using tools like Cypress<\/a>, Espresso<\/a>, Selenium<\/a>, Appium<\/a>, and a wide variety of others<\/a>, web and native platforms can get automated visual testing coverage with the power of Applitools Eyes<\/a>.<\/p>\n\n\n\n

But what if you\u2019re not looking to integrate it directly to an existing testing workflow because maybe you don\u2019t have one or maybe you don\u2019t have access to it? Or what if you want to provide blanket visual testing coverage on a website without having to maintain which pages get checked?<\/p>\n\n\n\n

We’ll walk through how we were able to take advantage of the power of Applitools Eyes and flexibility of GitHub Actions<\/a> to create a solution<\/a> that can fit into any GitHub-based workflow.<\/p>\n\n\n\n

Note: if you want to skip the \u201cHow it Works\u201d and go directly to how to use it, you can check out the<\/em> <\/em>Applitools Eyes GitHub Action<\/em><\/a> on github.com.<\/em> <\/em>https:\/\/github.com\/colbyfayock\/applitools-eyes-action<\/em><\/a><\/p>\n\n\n\n

What are GitHub Actions?<\/h2>\n\n\n\n

To start, GitHub Actions are CI\/CD-like workflows that you\u2019re able to run right inside of your GitHub repository.<\/p>\n\n\n\n

\"GitHub
Running build, test, and publish on a branch with GitHub Actions<\/em><\/figcaption><\/figure>\n\n\n\n

Using a YAML file, we can set up our project to run tests or really any kind of script based on events such as a commit, pull request, or even on a schedule with cron.<\/p>\n\n\n\n

name: Tests\n\non:\n  push:\n\tbranches: [ main ]\n  pull_request:\n\tbranches: [ main ]\n\njobs:\n  test:\n\truns-on: ubuntu-latest\n\tsteps:\n\t- uses: actions\/checkout@v2\n\t- uses: actions\/setup-node@v2\n\t  with:\n\t\tnode-version: '12'\n\t- run: npm ci\n\t- run: npm test<\/code><\/pre>\n\n\n\n
Setting up simpler workflows like our example above, where we\u2019re installing our dependencies and running our tests, is a great example of how we can automate critical code tasks, but GitHub also gives developers a way to package up complex scripts that can reach beyond what a configurable YML file can do.<\/p>\n\n\n\n
Using custom GitHub Actions to simplify complex workflows<\/h2>\n\n\n\n
When creating a custom GitHub Action<\/a>, we unlock the ability to use scripting tools like shell and node<\/a> to a greater extent, as well as the ability to stand up entire environments using Docker, which can allow us to really take advantage of our allotted environment just like we could on any other CI\/CD platform.<\/p>\n\n\n\n
\"GitHub
Building a container in a GitHub Action<\/em><\/figcaption><\/figure>\n\n\n\n
In our case, we want to allow someone to run Applitools Eyes without ever having to think about setting up a test runner.<\/p>\n\n\n\n
To achieve this, we can include Cypress<\/a> (or another test runner) right along with our Action, which would then get installed as a dependency on the workflow environment. This allows us to hook right into the environment to run our tests.<\/p>\n\n\n\n
Scaffolding a Cypress environment in a GitHub Action workflow with Docker<\/h2>\n\n\n\n
Setting up Cypress is typically a somewhat simple process. You can install it locally using npm<\/a> or yarn<\/a> where Cypress will manage configuring it for your environment.<\/p>\n\n\n\n
\"How
Installing Cypress with npm via cypress.io<\/em><\/figcaption><\/figure>\n\n\n\n
This works roughly the same inside of a standard YAML-based GitHub Action workflow. When we use the included environment, GitHub gives us access to a workspace where we can install our packages just like we would locally.<\/p>\n\n\n\n
It becomes a bit trickier however when trying to run a custom GitHub Action, where you would want to potentially have access to both the project and the Action\u2019s code to set up the environment and run the tests.<\/p>\n\n\n\n
While it might be possible to figure out a solution using only node, Cypress additionally ships a variety of publicly available Docker images<\/a> which let\u2019s us confidently spin up an environment that Cypress supports. It also gives us a bit more control over how we can configure and run our code inside of that environment in a repeatable way.<\/p>\n\n\n\n
Because one of our options for creating a custom Action is Docker<\/a>, we can easily reference one of the Cypress images right from the start:<\/p>\n\n\n\n
FROM cypress\/browsers:node12.18.3-chrome87-ff82<\/code><\/pre>\n\n\n\n
In this particular instance, we\u2019re spinning up a new Cypress-supported environment with node 12.18.3 installed along with Chrome 87 and Firefox 82.<\/p>\n\n\n\n
Installing Cypress and Action dependencies<\/h2>\n\n\n\n
With our base environment set up, we move to installing dependencies and starting the script. While we\u2019re using a Cypress image that has built-in support, Cypress doesn\u2019t actually come already installed.<\/p>\n\n\n\n
When installing Cypress, it uses cache directories to store download binaries of Cypress itself. When using Docker and working with different environments, its important to have predictable locations of where these caches exist, so that we\u2019re able to reference it later.<\/p>\n\n\n\n
\"Cypress
Cypress verifies that it can correctly identify an installation path from cache<\/em><\/figcaption><\/figure>\n\n\n\n
In our Docker file, we additionally configure that environment with:<\/p>\n\n\n\n
ENV NPM_CACHE_FOLDER=\/root\/.cache\/npm\nENV CYPRESS_CACHE_FOLDER=\/root\/.cache\/Cypress<\/code><\/pre>\n\n\n\n
When npm and Cypress goes to install, they\u2019ll use those directories for caching.<\/p>\n\n\n\n
We also need to set up an entrypoint which tells Docker what script to run to initiate our Action.<\/p>\n\n\n\n
Inside of our Dockerfile, we add:<\/p>\n\n\n\n
COPY entrypoint.sh \/entrypoint.sh\n\nENTRYPOINT [\"\/entrypoint.sh\"]<\/code><\/pre>\n\n\n\n
We\u2019ll use a shell script to initiate our initial installation procedure so we can have a little more control over setting things up.<\/p>\n\n\n\n
Finally, inside of our referenced shell script, we include:<\/p>\n\n\n\n
#!\/bin\/sh -l\n\ncd $GITHUB_WORKSPACE\n\ngit clone https:\/\/github.com\/colbyfayock\/applitools-eyes-action\ncd applitools-eyes-action\n\nnpm ci\n\nnode .\/src\/action.js<\/code><\/pre>\n\n\n\n
This will first navigate into our GitHub\u2019s Workspace directory, to make sure our session is in the right location.<\/p>\n\n\n\n
We then clone down a copy of our custom Action\u2019s code, which is referencing itself at this point, but it allows us to have a fresh copy in our Workspace directory, giving us access to the script and dependencies we ultimately need.<\/p>\n\n\n\n
And with our Action cloned within our working environment, we can now install the dependencies of our action and run the script that will coordinate our tests.<\/p>\n\n\n\n
Dynamically creating a sitemap in node<\/h2>\n\n\n\n
Once our node script is kicked off, the first few steps are to find environment variables and gather Action inputs that will allow our script to be configured by the person using it.<\/p>\n\n\n\n
But before we can actually run any tests, we need to know what pages we can run the tests on.<\/p>\n\n\n\n
To add some flexibility, we added a few options:<\/p>\n\n\n\n