GitHub Actions
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
A GitHub Actions workflow step calls the ContextQA API to trigger a test plan execution
The workflow polls ContextQA for the execution result (ContextQA handles the browser execution in the cloud)
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:
A ContextQA workspace with at least one configured test plan
Your ContextQA credentials stored as GitHub encrypted secrets:
Go to your GitHub repository → Settings → Secrets and variables → Actions → New repository secret
Add
CONTEXTQA_USERNAMEwith your ContextQA account emailAdd
CONTEXTQA_PASSWORDwith your ContextQA account password
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_IDwith 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:
In your GitHub repository, go to Settings → Branches → Branch protection rules
Create or edit the rule for your target branch (e.g.,
main)Enable Require status checks to pass before merging
Search for and add the job name from your workflow (e.g.,
ContextQA Test Planortest)Optionally enable Require branches to be up to date before merging
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:
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_USERNAMEandCONTEXTQA_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
Connect ContextQA to your CI/CD pipeline in 15 minutes. Book a Demo → — See the full integration walkthrough for your existing toolchain.
Last updated
Was this helpful?