feat(workflow): add event-driven CI-ready gate for publish by BYK · Pull Request #7664 · getsentry/publish

BYK · 2026-04-01T12:58:50Z

Summary

New ci-ready.yml workflow that handles repository_dispatch events from target repos when CI passes
Modified publish.yml with a gate step that checks label state before publishing
Added concurrency control to prevent duplicate publish runs
Created ci-pending and ci-ready labels

Context

craft publish currently polls GitHub's commit status API every 30 seconds for up to 60 minutes. This polling time 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 but sleep 30 in a loop. For repos like sentry-native (~1h 23m CI), this also exhausts the 1-hour GitHub App token lifetime, causing expired-token failures.

This PR replaces the polling wait with an event-driven label state machine. Instead of starting the publish runner and idling until CI passes, the job doesn't start at all until CI signals readiness — zero wasted runner minutes.

Label	Meaning
`ci-pending`	CI signal expected but not yet received
`ci-ready`	CI passed, ready to publish
`accepted`	Approved for publishing (unchanged)

Gate Decision Matrix

`accepted`	`ci-pending`	`ci-ready`	Action
yes	no	no	Old repo: publish with polling (unchanged)
yes	yes	no	Waiting for CI: comment on issue, skip
yes	—	yes	Ready: publish immediately
no	—	yes	CI ready, waiting for approval: skip

Cross-Repo Dependency

This is Phase 1 of a three-phase rollout:

Phase 1 (this PR): Gate logic + ci-ready.yml workflow — safe to deploy, no impact on existing repos
Phase 2 (getsentry/craft#789): ci_ready input + signal-ready action
Phase 3 (target repos): Opt-in one repo at a time

Old repos (without ci_ready: true) are completely unaffected — they keep the existing polling behavior.

Add a ci-ready.yml workflow that handles repository_dispatch events from target repos when their CI passes. It adds a "ci-ready" label to the publish issue, replacing the "ci-pending" label set at issue creation. Modify publish.yml with a gate step that checks label state: - Old repos (no ci-pending/ci-ready): publish with polling (unchanged) - New repos with both accepted + ci-ready: publish with --no-status-check - New repos with accepted but no ci-ready: comment and wait for CI - ci-ready without accepted: wait for approval Add concurrency control to prevent duplicate publish runs when both labels arrive near-simultaneously. This is Phase 1 of a cross-repo change. Phase 2 (getsentry/craft#789) adds the ci_ready input and signal-ready action.

Use contains(labels, accepted) so the job only runs when accepted is present. The || still allows ci-ready to trigger the job, but only when accepted is already on the issue — preventing wasted runs.

All label state is available in github.event.issue.labels at event time. The publish job if-condition now directly encodes the decision matrix: - accepted + no ci-pending → run - accepted + ci-ready → run (with --no-status-check) - accepted + ci-pending → skip (waiting-for-ci job comments instead) - anything without accepted → skip This removes the gate step that was re-fetching labels via gh issue view and all the step-level should_publish guards.