@qawolf/ci-sdk 2.2.0 → 2.6.0

package/README.md

@@ -304,6 +304,11 @@ The iterator yields a discriminated union that can be either a status update or
 - `httpStatus`: HTTP status code if applicable, otherwise `undefined`
 - `elapsedMs`: Milliseconds elapsed since polling started
 
+When `abortReason` is `"run-canceled"`, the iteration also carries:
+
+- `message`: Human-readable copy explaining the cancellation, or `undefined` when QA Wolf sent none
+- `reason`: A stable code for the cancellation, or `undefined` when QA Wolf sent none. Treat this as an open set of strings, since new codes appear without an SDK release
+
 **Important**: Always check `iteration.isAborted` to determine which type of result you received. When `isAborted === true`, you should handle the abort reason and exit appropriately.
 
 <a id="notify-terminated-ephemeral-environment"></a>
@@ -469,6 +474,25 @@ This package follows the [SemVer](https://semver.org/) versioning scheme. Additi
 
 # Changelog
 
+## v2.6.0
+
+- `pollCiGreenlightStatus`: when QA Wolf explains why a run was canceled, the SDK now prints that explanation instead of asking you to contact support. Previously the `message` on a `canceled` status was readable only through `onRunStageChanged` or the iterator, so a default caller saw the run stop with no cause. A backend that sends no `message`, and cancellations that carry none, keep the previous copy. `makePollCiGreenlightStatusIterator` now carries `message` and `reason` on the `run-canceled` abort as well. `reason` is an open set of string codes; new ones appear without an SDK release.
+- `makePollCiGreenlightStatusIterator`: a `run-canceled` abort now carries optional `message` and `reason` fields, holding whatever QA Wolf sent on the canceled status. Both are added to the existing `PollCiGreenlightIteratorNonHttpAborted`, so no existing type or declaration changes. Both are `undefined` on a `poll-timed-out` or `network-error` abort, which never carry an explanation, and against a backend that predates the fields.
+- `pollCiGreenlightStatus`: QA Wolf now gives up on a run it never managed to create, so a poll that used to continue until your own timeout ends within about five minutes. The run reaches the `canceled` stage with `reason: "run-not-created"` and an explanation, which the SDK now prints for you as described above, and the top-level result is `outcome: "aborted"` with `abortReason: "run-canceled"`, exactly as for any other cancellation. Treat `reason` as an open set, as before. Nothing changes for a run that is created normally, and a backend that predates this keeps reporting the run as `initializing`.
+
+## v2.5.0
+
+- `attemptNotifyDeploy`: QA Wolf no longer sends `skipped_triggers` on the `deploy_success` response, so against a current backend `skippedTriggers` is absent and `failReason: "trigger-skipped"` does not occur. A trigger that matched the deployment but could not run now reaches you as `outcome: "skipped"` rather than `outcome: "failed"`, so a deploy step that used to fail in that case passes instead. This most often happens when the environment has no enabled tests, where there is nothing to run and nothing to retry. Both `skippedTriggers` and the `trigger-skipped` reason stay in the types and are still parsed, so no caller has to change and a self-hosted backend that predates the change keeps working. Note that this response no longer distinguishes a matched-but-unrunnable trigger from a deployment that matched nothing, and its log line reads as though nothing matched.
+
+## v2.4.0
+
+- `attemptNotifyDeploy` and `notifyTerminatedEphemeralEnvironment`: the response may now carry a `warning` about the request itself rather than its outcome, and the SDK logs it through `log.warn`. Today it is sent when an organization or user API key omits `workspaceId`, in which case QA Wolf uses your organization's first-created workspace and the warning names it. The warning never changes the outcome, and it is absent against a backend that predates it. `attemptNotifyDeploy` also exposes it as `warning` on `DeployStatus`.
+
+## v2.3.0
+
+- `attemptNotifyDeploy`: a failed suite result now carries `failureCode` and `failureMessage` alongside the existing `failureReason`. `failureCode` is a stable code to branch on, such as `billing-prevented`, `environment-terminated`, `environment-not-ready`, `test-configuration-error`, or `internal-error`; treat it as an open set, since new codes are added over time. Note that `environment-terminated` is permanent while `environment-not-ready` clears on its own, so retrying is worthwhile only for the second. `failureMessage` is human-readable copy for logs, and the SDK's own failure log line now prints it instead of the internal reason.
+- `attemptNotifyDeploy`: `failureReason` is deprecated. It still ships unchanged and is safe to keep reading, but it carries an internal diagnostic whose values change without notice. Branch on `failureCode` and display `failureMessage` instead. Both are `undefined` when the SDK talks to a backend that predates them.
+
 ## v2.1.0
 
 - `attemptNotifyDeploy`: the `deploy_success` response is now validated at runtime instead of being trusted. A response with a non-JSON body, or a body that does not match the expected shape, returns `outcome: "aborted"` with the new `abortReason: "invalid-response-body"`. This is distinct from `"network-error"`, which now covers only transport and body-stream failures rather than also masking unparseable responses. A result the SDK does not recognize (for example a new result kind sent by a newer backend) returns `outcome: "failed"` with the new `failReason: "unknown-result"` instead of being reported as a success. Recognized results are unchanged, and older backends that omit newer fields remain fully supported.