Webhook

When your pipeline cannot create a GitHub or GitLab deployment, it can notify QA Wolf of the deploy itself. The deployment.reportStatus route takes the same information a deployment event carries, and a trigger evaluates it the same way. Pick this path when your code host is not GitHub or GitLab, when the deploying repository is not connected, or when the deploy happens somewhere your code host never sees. A pipeline that runs Node.js can make the same report through the Node.js SDK, which also waits for the verdict.

Requirements

An API key, created under Workspace Settings → API Keys. A workspace, organization or user key all work. A workspace key reports into its own workspace, so workspaceId has to name that workspace.
The ability to make an authenticated HTTPS request from your pipeline.

What a report carries

Field	Description
`workspaceId`	The workspace to report the deployment into.
`providerDeploymentId`	Your identifier for the deployment. Reports carrying the same one update a single deployment.
`status`	`pending`, `success`, `failure` or `inactive`.
`environment`	Either `{ id }` for an existing environment, or `{ name }`, which resolves by alias or name and creates an environment when nothing matches. A `{ name }` selector also takes `ephemeral` and `baseEphemeralEnvironment`.
`environment.ephemeral`	`true` for a preview deploy. Defaults to `false`, which creates a permanent environment.
`environment.baseEphemeralEnvironment`	The alias or name of the environment a created ephemeral environment copies from. Only valid alongside `ephemeral`. Defaults to the workspace’s base environment.
`deployTarget`	The URL the deployment serves. Required whenever the report creates an environment — without it the runs point at the base environment’s URL instead of at what you deployed.
`environmentVariables`	Overrides for the runs this deployment requests, as a flat map of string to string. A report that sends them replaces the stored values; one that omits them keeps them.
`service`	Which application was deployed, such as `checkout-api`, when several applications deploy into one environment, or when one pipeline ships more than one build such as an Android and an iOS build. A trigger’s `servicePattern` matches on it. A report that omits it keeps the stored value.
`metadata`	Details about the deployed revision, such as the commit.

Send environment.ephemeral: true for every preview deploy. A report that omits it is accepted and creates a permanent environment, one per pull request, that is never torn down.

Example:

"environment": { "name": "preview/pr-42", "ephemeral": true }

The request

Example:

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 input goes inside a json wrapper, and the reply carries the deployment under result.data.json. Replace $DEPLOY_ID with whatever your pipeline calls this deploy — a build number or a pipeline id — and $QAWOLF_WORKSPACE_ID with the id from Workspace Settings → API Keys.

Metadata

metadata describes the revision you deployed. Every field is optional, and each one QA Wolf receives makes the deployment easier to recognize and to link back to your code.

Field	Description
`commitSha`	The commit sha of the deployed revision.
`ref`	The branch or ref that was deployed.
`repository`	The `owner/name` of the repository, such as `acme/web`.
`pullRequestNumber`	The pull request the deployment belongs to. Requires `repository`, and a connected integration covering that repository.
`commitMessage`	The deployed commit’s message. The deployments list shows its first line.
`commitAuthorName`	The display name of the commit’s author.

repository and pullRequestNumber only link the deployment to its pull request when a connected GitHub or GitLab integration covers that repository. QA Wolf reads the pull request from the code host. Without the integration the report succeeds and the deployment carries no pull request. See PR testing.

When a report starts a run

A deployment’s first success report evaluates triggers, and it is the only report that does. To evaluate a deploy again, report it under a new providerDeploymentId.
The response carries the deployment only, never the resulting runs.
A deployment stays bound to the environment resolved on its first report, so later reports may omit the selector. Report a promotion as a new deployment under a new providerDeploymentId.

How the environment name resolves, and what a preview deploy needs, is covered in Deployments.

Create a trigger

Reporting a deploy starts nothing on its own. Create a deployment trigger whose conditions match the deployments you now report. See Triggers.

CI/CD

VPN

Test Management Systems

Issue Trackers

Communication

Legacy triggers

Requirements

What a report carries

The request

Metadata

When a report starts a run

Create a trigger

​Requirements

​What a report carries

​The request

​Metadata

​When a report starts a run

​Create a trigger

Requirements

What a report carries

The request

Metadata

When a report starts a run

Create a trigger