feat(workflow): replace dispatch-based ci-ready with centralized CI status poller

[BYK]

Summary

Replace per-release idle polling inside Docker containers with a cron-based CI status poller gated by a repo variable. Zero changes needed in craft or target repos.

How it works

Two new workflow files:

ci-pending.yml — triggered on issues: opened

When a new publish issue is created, adds the ci-pending label and sets CI_POLLER_HAS_PENDING repo variable to true to activate the cron poller.

ci-poller.yml — cron every 5 minutes

• Job-level if: vars.CI_POLLER_HAS_PENDING == 'true' — when false, no runner is provisioned. Zero cost.
• When true: fetches all ci-pending issues, extracts the commit SHA from the "View check runs" link in each issue body, checks CI status via GitHub API
• When all checks pass: replaces ci-pending with ci-ready label (using GitHub App token so the label event triggers publish.yml)
• When all pending issues are resolved: sets the variable back to false, disabling the cron until the next release

Existing publish.yml gate (merged in #7664)

• accepted + no ci-pending → publish (old repos with legacy polling, or new repos where CI passed)
• accepted + ci-pending → skip (waiting-for-ci job comments)
• accepted + ci-ready → publish

Why

craft publish currently polls GitHub's commit status API every 30 seconds for up to 60 minutes inside a Docker container. This idle polling is billed as GitHub Actions minutes and steals from our available capacity — a publish job that waits 45 minutes for CI burns 45 minutes of runner time doing nothing. For repos like sentry-native (~1h 23m CI), it also exhausts the 1-hour GitHub App token lifetime, causing expired-token failures (getsentry/craft#788).

With the poller, the publish job doesn't start at all until CI passes — the expensive Docker job gets a fresh token and runs only for the actual publishing.

Cost

• Idle (no pending releases): zero — the cron job is skipped at the if level, no runner provisioned
• Active: ~30 seconds per cron tick to check CI status, every 5 minutes, only while there are ci-pending issues
• Current approach for comparison: 30-60 minutes of continuous in-Docker polling per release

Pre-deploy

Create the CI_POLLER_HAS_PENDING repo variable with initial value false:

gh variable set CI_POLLER_HAS_PENDING -R getsentry/publish -b "false"

Backward Compatibility

• Issues without ci-pending label (created before this deploys) → publish.yml gate treats them as old-style, runs with legacy in-Docker polling. Zero behavioral change.
• New issues (created after deploy) → get ci-pending from ci-pending.yml, poller handles them.

[cursor]

Pending commit status conflated with absent statuses

Medium Severity

The condition allows commit_status == "pending" to pass through, but the GitHub combined status API returns "pending" both when no statuses exist (repo uses only check runs) and when an actual status context is still pending. For repos that use both commit statuses and check runs, this could mark CI as ready while legacy status checks are still running.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[Jeffreyhung]

save us those 💸 💸 💸