> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.qa.army/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.qa.army/_mcp/server.

# CI and Deployments

> Use a saved Web Test in a script, interpret its exit code, and distinguish a Run from deployment verification.

An authorized script can request an existing Web Test through the CLI. Automatic
CI setup, general deployment integrations, and local target connections are not
provided by this workflow. [GitHub Pull Request Testing](/github-pull-request-testing)
has separate availability and setup requirements.

## Prepare the target and access

Save a Test against the approved reachable Project target. Confirm the environment
and account role before running it. Install the pinned CLI package using the
[CLI guide](/interfaces/cli).

For a headless job, inject an authorized profile API key through your CI secret
store as `QA_ARMY_API_KEY`. Never print it or pass a key as a command argument.
Interactive agent registration requires a human claim step and a native
credential store; it is not unattended CI login.

## Wait for the Test result

Replace the Test ID with the saved Test you intend to execute:

```sh
qa-army tests run --test tst_... --wait --timeout 900000 --interval 2000
```

Keep the command's exit code in your job. With `--wait`, `0` means `PASSED`;
`1` includes `FAILED`, `ERROR`, `CANCELLED`, and command errors. Inspect the
receipt or stderr to distinguish them. A `REQUEST_CAPABILITY` response returns
`2` and means no supported operation was performed.

Without `--wait`, exit code `0` only confirms the Run started. Likewise,
`runs get` and `runs wait` can succeed while returning a failed Run. They are
read operations, not pass/fail gates.

## Recover without starting duplicate work

Save the returned Run ID and `run_url`. If waiting times out, inspect that Run
with `runs get` or `runs wait`; the remote execution may still be active. Review
Run history if the original response was lost. Do not retry the entire CI step
automatically: another `tests run` invocation requests another Run.

For explicit request-key control, use the API's idempotency contract described
in [Coding Agents](/interfaces/coding-agents). Define a fresh Run as a deliberate
decision after reviewing the previous attempt.

## Review before promotion

Promote only when the intended coverage has a `PASSED` result for the target
you meant to test. `FAILED` identifies a product assertion mismatch; `ERROR`
is inconclusive and needs investigation. Preserve the Run URL and available
evidence with the release record.

This CLI command does not deploy your application, bind the result to a pull
request commit, or publish a source-control check. Confirm that the tested
target contains your intended change before using the result to approve a release.