Allow confirming runs on a stack locked by a push policy lock

Workaround

Partial. We’ve removed locking from the PR deploy path: /spacelift deploy <stack> on an approved, mergeable PR queues a tracked run without taking a lock, so a person can confirm it after reviewing the plan. That gives up serialization: nothing stops a second unmerged PR from applying to the same stack in between and undoing the first PR’s change, so we rely on people checking a stack’s recent runs before deploying. The alternative was to keep the lock and unlock the stack before each confirm (then relock if needed), which leaves the stack unprotected while the run waits and adds several manual steps to every change. We judged that too much friction.

Problem

We use the push policy’s lock / unlock rules to serialize applying from PRs before merge: a PR takes the stack’s lock (PR_ID_<n>), then a /spacelift deploy <stack> comment queues a tracked run for that PR (gated on pull_request.approved and mergeable). Our stacks don’t autodeploy, because we want a person to confirm after reviewing the plan. But the lock is owned by its key, not by a person, so while it’s held nobody can confirm the run the same policy queued, admins included: “This stack was locked for exclusive use by PR_ID_24528.” The only way through is unlock, confirm, and relock if needed, which loses the protection the lock was there for. So push policy locking effectively only works with autodeploy.