GitHub Actions

circle-info

Who is this for? SDETs, developers, and engineering managers who want to run ContextQA tests automatically on every pull request or push from their GitHub Actions workflow.

Trigger ContextQA tests automatically from your GitHub Actions CI/CD pipeline. When a developer opens a pull request or pushes to a protected branch, ContextQA runs the configured test plan on its cloud infrastructure, reports results back to the workflow, and can block merges when tests fail — all without requiring any browser installation on the GitHub Actions runner.


How It Works

  1. A GitHub Actions workflow step calls the ContextQA API to trigger a test plan execution

  2. The workflow polls ContextQA for the execution result (ContextQA handles the browser execution in the cloud)

  3. When execution completes, the workflow reports the result:

    • If tests passed: the workflow step exits with code 0 (success)

    • If tests failed: the workflow step exits with code 1, failing the workflow job

Because ContextQA runs tests on its own infrastructure, your GitHub Actions runner needs no browser, no Playwright installation, and no X display server — just the ability to make outbound HTTPS requests.


Prerequisites

Before setting up the workflow:

  1. A ContextQA workspace with at least one configured test plan

  2. Your ContextQA credentials stored as GitHub encrypted secrets:

    • Go to your GitHub repository → Settings → Secrets and variables → Actions → New repository secret

    • Add CONTEXTQA_USERNAME with your ContextQA account email

    • Add CONTEXTQA_PASSWORD with your ContextQA account password

  3. Your test plan ID (visible in the ContextQA UI under Test Execution → Test Plans)

    • Store this as a repository variable: Settings → Secrets and variables → Actions → Variables → New repository variable

    • Add CONTEXTQA_PLAN_ID with your plan ID


Workflow: Run Tests on Push and Pull Request

The following workflow triggers a ContextQA test plan on every push to main and on every pull request targeting main. It authenticates, starts the execution, polls for completion, and fails the workflow if tests fail.


Workflow: Generate Tests from a Pull Request Diff

For teams that want to automatically generate and run tests specifically targeting the code changes in a PR:


Posting Results as a PR Comment

Add a step after the test run to post the result back to the pull request as a comment, giving reviewers a direct link to the full ContextQA report:


Blocking Merges on Test Failure

To require ContextQA tests to pass before a PR can be merged:

  1. In your GitHub repository, go to Settings → Branches → Branch protection rules

  2. Create or edit the rule for your target branch (e.g., main)

  3. Enable Require status checks to pass before merging

  4. Search for and add the job name from your workflow (e.g., ContextQA Test Plan or test)

  5. Optionally enable Require branches to be up to date before merging

  6. Save the rule

With this configuration, GitHub blocks the merge button until the ContextQA workflow job reports a successful exit.


Running Specific Suites or Test Cases

To run a specific test suite instead of a full plan, modify the API call in the workflow:

The polling pattern is identical — use the returned execution_id to poll for the result.


Matrix Builds: Running Across Multiple Browsers

To run the same test plan across multiple browsers in parallel:

Each browser runs in its own parallel job. If the fail-fast: false option is set, all browsers run to completion even if one fails, giving you a complete cross-browser result set.


Using the ContextQA MCP Server in CI

For CI workflows that use an AI agent or need access to the full 67-tool interface (not just plan execution), you can install and run the ContextQA MCP server on the GitHub Actions runner:


Environment-Specific Runs

For workflows that deploy to different environments (staging vs. production), pass the environment ID to target the correct base URL:

This ensures your CI tests run against the environment that was just deployed, using the correct base URL and configuration.


Storing Credentials Securely

Never hardcode ContextQA credentials in workflow files. Always use GitHub's encrypted secrets:

Secret Name
Value

CONTEXTQA_USERNAME

Your ContextQA account email

CONTEXTQA_PASSWORD

Your ContextQA account password

For organization-wide use, store these as organization-level secrets rather than per-repository secrets so they are available across all repositories without duplication.

For extra security, create a dedicated ContextQA service account for CI (not your personal login). This allows you to revoke CI access independently and keeps the audit log clean.


Troubleshooting

Authentication fails in CI but works locally:

  • Verify the secrets are named exactly CONTEXTQA_USERNAME and CONTEXTQA_PASSWORD (case-sensitive)

  • Check that the secrets are available to the repository (organization secrets may require explicit repository access)

  • Test the credentials manually: curl -X POST https://api.contextqa.com/auth/login -d '{"username":"...", "password":"..."}'

Workflow times out before tests complete:

  • Increase the polling duration or the number of polling attempts

  • Check if the test plan contains very long-running tests — consider splitting into multiple plans

  • Verify ContextQA execution infrastructure is reachable from the GitHub Actions runner network

Tests pass locally but fail in CI:

  • Check if the application is deployed and accessible at the URL being tested before the tests run

  • Add a health check step before triggering ContextQA to verify the staging environment is up

  • Check if the application requires VPN or IP allowlisting — GitHub Actions runners use ephemeral IPs that change each run

circle-info

Connect ContextQA to your CI/CD pipeline in 15 minutes. Book a Demo →arrow-up-right — See the full integration walkthrough for your existing toolchain.

Last updated

Was this helpful?