Migrate from legacy triggers

​

What changes

• Where automation lives. A legacy trigger sits on one environment, so covering staging and production takes one in each. A trigger sits on the workspace, so one trigger can cover staging, production and every preview environment.
• How deploys are matched. A legacy deployment trigger matched an opaque deployment type your pipeline sent. A trigger matches what the deploy actually carries: its environment, URL, branch, repository and service. See Trigger fields.
• Who manages it. You create, edit and pause triggers yourself, on the workspace’s triggers page, through the API and CLI, or through your coding agent.

​

Migrate with your coding agent

Migrate my QA Wolf legacy triggers to triggers. First tell me which QA Wolf
workspace you're connected to, and confirm you've loaded QA Wolf's trigger
migration skill. Read everything and show me the full plan before you create
or pause anything.

​

What to check in the plan

• Times and timezones. Each schedule shows the time and timezone it will run in. Confirm them.
• Weekend runs. The plan may suggest running hourly and daily schedules on weekdays only. It calls that change out, so say so if you want to keep weekend runs.
• What runs. A legacy trigger with no tags ran every flow in its environment. A trigger has to name a tag or a list of flows, so pick one. A tag lets flows tagged later join.
• Deployment triggers created together. Every legacy deployment trigger has a replacement in the plan, or a decision to drop it. See When legacy triggers stop.
• Pipeline changes. Any change your deploy pipeline needs, and which legacy triggers stay on until that change ships. See Move your deploy reporting first.
• Behavior changes. Anything that won’t work exactly as before, such as on-demand pull request testing becoming automatic. See What doesn’t map one to one.

​

Migrate without a coding agent

​

When legacy triggers stop

• Legacy deployment triggers fed by GitHub deployment events stop running at that moment, replaced or not. Create every replacement deployment trigger in one sitting, so none is missing once the first is active. Any you haven’t replaced leave a gap.
• Legacy schedules keep running until you pause them. A schedule trigger doesn’t switch anything, so you can move schedules one at a time. Create the new schedule, then pause the legacy one, or both run.
• Legacy deployment triggers fed by deploy_success keep running until you pause them. Pause each one once your pipeline reports deploys the new way and a real deploy has started runs through the new triggers.

​

Move your deploy reporting first

​

A direct deploy_success call

curl -X POST https://app.qawolf.com/api/webhooks/deploy_success \
  -H "Authorization: Bearer $QAWOLF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "branch": "main",
    "sha": "de12adda500f2bc5a29dbd89f4fb1b0e1a31de81",
    "deployment_type": "staging",
    "deployment_url": "https://staging.example.com"
  }'

curl -X POST "https://app.qawolf.com/api/trpc/public.deployment.reportStatus" \
  -H "Authorization: Bearer $QAWOLF_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"json\": {
      \"workspaceId\": \"$QAWOLF_WORKSPACE_ID\",
      \"providerDeploymentId\": \"$DEPLOY_ID\",
      \"status\": \"success\",
      \"environment\": { \"name\": \"staging\" },
      \"deployTarget\": \"https://staging.example.com\",
      \"metadata\": { \"commitSha\": \"$GIT_COMMIT_SHA\", \"ref\": \"$GIT_BRANCH\" }
    }
  }"

​

The notify-qawolf-on-deploy-action GitHub Action

 - name: Notify QA Wolf
-  uses: qawolf/notify-qawolf-on-deploy-action@v2
+  uses: qawolf/notify-qawolf-on-deploy-action@v3
   with:
     qawolf-api-key: ${{ secrets.QAWOLF_API_KEY }}
-    deployment-type: "staging"
+    workspace-id: "YOUR_WORKSPACE_ID"
+    environment: "staging"
     deployment-url: "https://staging.example.com"

• For a pull request preview, leave environment out. The action reports into the pull request’s own environment.
• The run-id output is gone. Use the deployment-id output instead.

​

@qawolf/ci-sdk attemptNotifyDeploy

const { attemptNotifyDeploy } = makeQaWolfSdk({ apiKey });

const result = await attemptNotifyDeploy({
  branch,
  sha,
  deploymentType: "staging",
  deploymentUrl: "https://staging.example.com",
});

const { deployment } = makeQaWolfSdk({ apiKey });

const detected = detectProviderDeploymentId();
if (detected.outcome !== "detected") {
  throw new Error(`Could not identify this deployment: ${JSON.stringify(detected)}`);
}

const report = await deployment.reportStatus({
  workspaceId,
  providerDeploymentId: detected.id,
  status: "success",
  environment: { name: "staging" },
  deployTarget: "https://staging.example.com",
  metadata: { commitSha: sha, ref: branch },
});

​

fastlane-plugin-qawolf below 1.0.0

gem "fastlane-plugin-qawolf", git: "https://github.com/qawolf/fastlane-plugin-qawolf", tag: "0.4.8"

notify_deploy_qawolf(
  deployment_type: "staging",
  deployment_url: "https://staging.example.com"
)

gem "fastlane-plugin-qawolf", git: "https://github.com/qawolf/fastlane-plugin-qawolf", tag: "1.1.0"

notify_deploy_qawolf(
  workspace_id: ENV.fetch("QAWOLF_WORKSPACE_ID", nil),
  environment: "Staging",
  deploy_target: "https://staging.example.com"
)

• Remove deduplication_key.
• Replace hosting_service, repository_name, repository_owner and repository_namespace with one repository, such as "my-org/my-app".
• A later step that reads QAWOLF_RUN_ID reads QAWOLF_DEPLOYMENT_ID instead. It holds a deployment id, not a run id.

​

GitHub or GitLab deployment events

​

How legacy setups map

​

Schedules

​

Deployment triggers

​

PR testing and adaptive flow selection

• The PR testing button becomes automatic PR testing: a deployment trigger for your preview deploys that runs a Smart Smoke Suite. Tests run on every matching preview deploy instead of when someone presses the button.
• Adaptive flow selection becomes a Smart Smoke Suite on a trigger for preview deploys. A tag limit on the legacy trigger becomes an instruction to the Smart Smoke Suite.

​

What doesn’t map one to one

• A schedule other than hourly, twice a day, daily or weekly.
• A deployment type that mixes an environment with something else, such as staging-smoke.
• A deployment trigger limited to more than one branch pattern.
• A deployment trigger that ran when someone added a label to a pull request.

​

FAQ

​

Do I have to do the migration myself?

​

What if I don’t use a coding agent?

​

Will I lose runs or coverage during the switch?

​

What happens to my legacy triggers?

​

Can I undo the migration?

​

How do I know it worked?