Skip to main content

Setting up your CI/CD with Docket

Pre-requisites 🚨
  1. Make sure you have a Github account (with admin access to repos you’d like to connect)
  2. Make sure you have a Docket account
  3. Make sure you have a Docket API Key
    1. Can’t find one? No worries, e-mail boris@docketqa.com for support!
Set-up Process 🚀
  1. Add your Docket API key to your Github Org
    1. Open the repo you’d like to connect on Github
    2. Click on Settings > Security > Secrets and variables > Actions
    3. Create a new Repository Secret, name it DOCKET_API_KEY
  2. Log-in to app.docketqa.com and click on CI/CD Screenshot_2025-05-21_at_7.17.39_PM.png
  3. You should see a big Connect GitHub button, click it Screenshot_2025-05-21_at_7.20.31_PM.png
  4. Follow the installation instructions & select your repo Screenshot_2025-05-21_at_7.30.00_PM.png
  5. After you click Install , you should be re-directed back to Docket. Click View Connected Repos . You should now see the connected repo Screenshot_2025-05-21_at_7.33.05_PM.png

How the Gated Deployment Process Works

  1. 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.
  2. 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.
  3. Automated Path (QA Passes):
    • If the Docket QA status for the commit is success, the workflow proceeds to deploy your application automatically.
  4. Manual Override Path (QA Fails or Times Out):
    • If the Docket QA status is failure, error, or if the check times out before a success status 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 /approve or /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.
This ensures quality control via Docket QA while providing the necessary flexibility for authorized manual overrides. Add .github/workflows/release-pipeline.yml
This is an example workflow for the release step of your CI/CD pipeline. In short, it assigns a pending status to the release commit and kicks off a Docket test run using: your Docket API Key + the test_blueprint_category_id of 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.
Lastly, take a look at your deploy action, and optionally, add Docket QA runs as a blocking step (with manual unblocking if it does fail)!

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:
In this example:
  • 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 167 and 234: Override suite settings with specific feature URLs