Setting up your CI/CD with Docket
Pre-requisites 🚨- Make sure you have a Github account (with admin access to repos you’d like to connect)
- Make sure you have a Docket account
- Make sure you have a Docket API Key
- Can’t find one? No worries, e-mail
boris@docketqa.comfor support!
- Can’t find one? No worries, e-mail
-
Add your Docket API key to your Github Org
- Open the repo you’d like to connect on Github
- Click on Settings > Security > Secrets and variables > Actions
- Create a new
Repository Secret, name it DOCKET_API_KEY
-
Log-in to app.docketqa.com and click on
CI/CD
-
You should see a big Connect GitHub button, click it

-
Follow the installation instructions & select your repo

-
After you click
Install, you should be re-directed back to Docket. ClickView Connected Repos. You should now see the connected repo
How the Gated Deployment Process Works
- Trigger: Your deployment workflow is typically triggered by an event like a tag push (e.g.,
v1.0.0). This kicks off a Test Suite run on Docket. - QA Status Check: The workflow identifies the specific commit associated with the trigger and polls GitHub for a commit status from Docket QA (e.g., a status with the context
ci/docket-qa). When Docket finishes running your test suite, it notifies Github about the pass/fail status of the commit. - Automated Path (QA Passes):
- If the Docket QA status for the commit is
success, the workflow proceeds to deploy your application automatically.
- If the Docket QA status for the commit is
- Manual Override Path (QA Fails or Times Out):
- If the Docket QA status is
failure,error, or if the check times out before asuccessstatus is received:- The workflow will not automatically deploy.
- Instead, a manual approval process is initiated which involves creating a GitHub Issue detailing the QA failure and asking for a decision.
- Designated approvers (specified in the workflow) can review the situation and comment on the issue (e.g., with
/approveor/reject). - If approved, the workflow proceeds with the deployment.
- If rejected or if the approval request times out, the deployment is halted, and the workflow job fails.
- If the Docket QA status is
.github/workflows/release-pipeline.yml
This is an example workflow for the release step of your CI/CD pipeline. In short, it assigns apendingstatus to the release commit and kicks off a Docket test run using: your Docket API Key + thetest_blueprint_category_idof your test group in docket (this id resembles a grouping of all the QA tests you want to run).
.github/workflows/docket-results-qa-listener.yml
When your test run completes, Docket sends a dispatch event to your Github repository. This workflow subscribes to such events and marks the release commit’s status to pass/fail depending on the outcome of the test run.
URL Overrides
Override starting URLs for tests during CI/CD runs to test against different environments. This is particularly useful when generating preview links (like Vercel preview deployments) and you want to test against those specific environments instead of your production URLs.Override Types
- Test Suite URL Overrides (
test_suite_url_overrides): All tests in the suite start from this URL - Test Suite Login URL Overrides (
test_suite_account_login_url_overrides): Account belonging to this test suite will use this login URL - Individual Test URL Overrides (
test_url_overrides): Override specific tests (takes precedence)
Vercel Preview Example
When deploying with Vercel, you might want to test your preview deployment before merging. Here’s how to override entrypoints for tests, test suites, and account login flows:- Test suite
17: All tests start from preview root, login at/auth/login - Test suite
23: All tests start from preview/dashboard, admin login at/admin/login - Tests
167and234: Override suite settings with specific feature URLs

