Run tests as a GitHub check

The mabl GitHub integration allows you to run end-to-end tests as part of your GitHub Pull Requests (PR) and commit checks. Thus, your team can get feedback earlier in the development process to ensure code changes don't introduce functional or visual UI regressions. You can also use GitHub checks to require that all tests are passing before a PR can be approved and merged.

Use cases

Teams that deploy GitHub commits to testing environments can take advantage of the mabl GitHub check to:

  • Run test checks as part of commits and PRs in GitHub to get early feedback
  • Require that the test check passes before a GitHub PR can be approved and merged

Integration setup

First follow the GitHub integration setup instructions to install the integration.

Note that you'll need to enable the Allow manually re-running GitHub checks option to allow Pull Request reviewers to manually trigger mabl test re-runs from GitHub (pictured below). See the GitHub integration settings for full details.

Using mabl Checks in GitHub

With the GitHub integration all setup, you can start running tests in mabl for your deployed GitHub commits by using the mabl CLI to create deployment events in mabl that will show up as a check in GitHub as shown on the image below.

mabl test results shown as a GitHub PR checkmabl test results shown as a GitHub PR check

mabl test results shown as a GitHub PR check

It is important that you use the --revision option with the mabl deployments create command and pass it the value of the code revision hash that is being deployed for testing. The revision hash is what makes the connection between the mabl tests being run and the GitHub check, so that you see the mabl check as part of your GitHub checks for the respective commit or PR.

The code revision hash is typically passed to your CI/CD tool and you can grab it from there to pass it to the mabl CLI command. If you manually create a deployment event in mabl via the mabl CLI, you can grab the hash from commit details in GitHub. Just make sure you copy anywhere between the first seven or all characters of the hash.

mabl GitHub check details

Within the mabl GitHub check details, you will see:

  • a list of all plans and tests that run as part of the check
  • the status of each test run: passed or failed
  • option to manually re-run the tests, if configured in the GitHub integration settings of the mabl app

Clicking on a test name within GitHub will take you to the mabl app where you can see the complete test run output details - screenshots, DOM snapshots, Network Activity, etc - for troubleshooting purposes.

mabl test details for a GitHub checkmabl test details for a GitHub check

mabl test details for a GitHub check

Running additional UI tests

Let's say that you automatically run your mabl smoke tests when deploying a commit pushed to GitHub. After you verify that all smoke tests pass, you may want to run all your regression plans to detect issues before merging the GitHub PR.

You can do so in three different ways:

  • Create a new deployment event in mabl via the mabl CLI with the mabl deployments create command by specifying the respective app ID, environment ID, URL, labels, mabl branch, etc.
  • Within the mabl app, click to manually run a plan on a branch and specify the respective URL
  • Manually run each test from the mabl app by specifying the respective URL

By default, you will not see results for these additional test runs in the mabl GitHub check and you will need to go into mabl to see them. You can also update your GitHub mabl check to show the additional test run results so everyone on your team can see them by using the mabl CLI and passing the revision hash for respective GitHub commit as a value to the --revision option of the mabl deployments create command. If you have a PR open, you should use the hash for the latest commit in the PR.

The revision hash value should include seven or more characters from the beginning of the string.

Creating and updating tests

Should need to create new tests, or update existing ones, to reflect changes in your code branch, we recommend that you save the test changes to mabl branch and merge them once your code gets merged to master and deployed to an environment. See the test branching docs to learn more about working with branches and version control in mabl.

Did this page help you?