GitHub Actions
Use the GitHub Actions integration when a deployment should automatically run a HiTest test plan. The workflow calls the Webhook URL configured under the plan's Automatic runs section.
Before you start
Create or edit a test plan and enable Webhook under Automatic runs. The form generates a Webhook URL automatically. Copy it, save the plan, and keep the plan Active. Store the URL as a GitHub Actions repository secret named HITEST_WEBHOOK_URL.
If each deployment has a different URL, also store that URL in a repository or environment variable named HITEST_BASE_URL. HiTest will use this value for the run when the workflow sends overrideBaseUrl.
Workflow file
Save this file as .github/workflows/hitest-post-deploy.yml:
name: HiTest post-deploy
on:
deployment_status:
permissions:
contents: read
jobs:
test:
if: >-
github.event.deployment_status.state == 'success' &&
github.event.deployment.environment == 'production'
runs-on: ubuntu-latest
steps:
- name: Trigger HiTest
env:
GH_TOKEN: ${{ github.token }}
WEBHOOK_URL: ${{ secrets.HITEST_WEBHOOK_URL }}
OVERRIDE_BASE_URL: ${{ vars.HITEST_BASE_URL }}
REPOSITORY: ${{ github.repository }}
COMMIT_SHA: ${{ github.event.deployment.sha }}
run: |
COMMIT_MESSAGE="$(gh api "repos/$REPOSITORY/commits/$COMMIT_SHA" --jq '.commit.message')"
jq -n \
--arg message "[github] $COMMIT_MESSAGE" \
--arg overrideBaseUrl "$OVERRIDE_BASE_URL" \
'{ message: $message } + if $overrideBaseUrl == "" then {} else { overrideBaseUrl: $overrideBaseUrl } end' |
curl --fail-with-body \
-X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
--data-binary @-What the workflow sends
The webhook payload includes:
message: source context included with Run notifications so reviewers can connect results to the GitHub deployment.overrideBaseUrl: optional. When present, HiTest tests this URL instead of the project's default Base URL.
Use a message that is meaningful during failure review. Commit messages, release names, deployment IDs, or environment names are usually enough.
Deployment timing
The example listens for GitHub deployment_status events and only runs after GitHub reports a successful production deployment. This avoids testing the previous version immediately after code is pushed.
If your host does not report deployment status back to GitHub, trigger HiTest after your deploy step instead:
- name: Deploy
run: ./scripts/deploy.sh
- name: Trigger HiTest
env:
WEBHOOK_URL: ${{ secrets.HITEST_WEBHOOK_URL }}
run: |
jq -n --arg message "[github] $GITHUB_SHA deployed" '{ message: $message }' |
curl --fail-with-body \
-X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
--data-binary @-Preview and staging environments
For preview deployments, set overrideBaseUrl to the preview URL:
jq -n \
--arg message "[github] preview $GITHUB_SHA" \
--arg overrideBaseUrl "$PREVIEW_URL" \
'{ message: $message, overrideBaseUrl: $overrideBaseUrl }'Only point a test plan at an environment where its test accounts, test data, and permissions are prepared to run. A production test plan may fail against a preview app if the preview environment does not have the same users, billing state, or feature flags.
Verification
Action: Merge or deploy a change that should create a successful GitHub deployment status.
Expected result: GitHub Actions runs HiTest post-deploy, and the curl step receives 202 Accepted with accepted: true. This confirms dispatch, not test success. With active coverage and sufficient credits, a new Run then appears with trigger Webhook.
Action: Open the HiTest run and review the failed or passed test cases.
Expected result: The Run shows case results and any available recording or linked Issue. Configured Run notifications include the GitHub message as source context.
Troubleshooting
404: verify the plan and project still exist, the plan is Active, Webhook is enabled under Automatic runs, and the saved URL matchesHITEST_WEBHOOK_URL. If the URL changes, update the repository secret.curl: (22): inspect the response body printed by--fail-with-body.- No Run appears: check the workflow condition, Active plan status, matching coverage, workspace credits, and workflow dispatch. A 202 response can precede the worker deciding not to create a Run.
- Run targets the wrong app: check whether
overrideBaseUrlis being sent, and verify the project's Base URL.
