When the Kustomization is updated in quick succession, GitHub Deployments
can become orphaned — stuck in `in_progress` forever because the
deployment-id annotation in the GitOps repo gets overwritten by the
subsequent run and the flux-deployment-reporter only sees the latest ID.
This adds a `deactivate_stale_deployments` function that runs before each
new deployment creation. It queries existing deployments for the target
environment and marks any with status `in_progress`, `queued`, or `pending`
as `inactive`. The cleanup is best-effort and idempotent.
Co-Authored-By: Claude <claude@anthropic.com>
Type of Change
Description
When the Kustomization is updated in quick succession (e.g. two pushes to main within seconds), GitHub Deployments can become orphaned — stuck in in_progress forever. This happens because the deploy.staffbase.com/deployment-id annotation in the GitOps repo gets overwritten by the subsequent run, and the flux-deployment-reporter only sees the latest ID.
This adds a deactivate_stale_deployments() function that runs before each new deployment creation. It queries existing deployments for the target environment via the GitHub API and marks any with status in_progress, queued, or pending as inactive ("Superseded by newer deployment").
The cleanup is best-effort (failures don't block new deployments) and idempotent (concurrent runs deactivating the same deployment is harmless).
Note: GitHub's built-in auto_inactive parameter only affects deployments that previously reached success state and does not help with orphaned in_progress deployments.
Checklist
The changes and the PR were generated by Claude.