A new CI run cancelled a deployment: separate stale tests from live changes

Locate the last external action

A product owner notices that pushing a second change cancelled an in-progress release. Retain the cancelled run and identify whether it had only built files or had already changed a deployment target, database or external service. Cancellation stops execution; it does not establish that earlier side effects were reversed. Have the authorised operator inspect the target before retrying.

• Keep the run ID, revision and last completed release step.
• Do not treat a Cancelled label as proof that nothing went live.

Read the group as a shared lock name

Compare concurrency at both workflow and job level. Group names are case-insensitive and shared across workflows in a repository. A broad group can unexpectedly join unrelated jobs; a group separated by branch or workflow can allow two releases to the same target simultaneously. Define the resource being protected, such as an environment, before choosing the expression.

• Compare every workflow capable of changing the same target.
• Separate cheap superseded test runs from consequential deployment jobs.

Turning cancellation off is not a full queue design

Under the default single-pending policy, a newer arrival can replace a pending run even when the active run is allowed to finish. Decide whether intermediate releases may be discarded or each approved release must execute. Review the supported queue options in the current documentation, and do not promise dispatch-order processing. Any change to sequencing needs a recovery and approval policy as well as YAML.

• Use a disposable target to inspect the planned ordering.
• Reconcile an interrupted database or release step separately from rebuilding code.

Acceptance uses two competing runs

Trigger two authorised safe releases close together and record what executes, waits or is replaced. Verify the target ends on the intended revision, with no unexamined partial operation. Repeat the interrupted-step case if it is in scope. First contact needs only redacted run context; live inspection, account changes and price require separate agreement. This guide makes no automatic rollback or zero-downtime claim.