Distillation

Date: Aug 27, 2026

• 🔴 (15:25) User stated that the CI poller always adds the ci-ready label after CI passes.
• 🟡 (15:25) .github/workflows/publish.yml approval job runs only for an accepted label event on an open issue whose title starts with publish: , and checks out code with actions/checkout@v6 and persist-credentials: false.
• 🟡 (15:25) .github/workflows/publish.yml creates the internal GitHub App token with actions/create-github-app-token@v3, vars.SENTRY_INTERNAL_APP_ID, and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY.
• 🟡 (15:25) .github/workflows/publish.yml best-effort creates a release-bot token using actions/create-github-app-token@v3, vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry; it runs node src/publish/authorize-approval.js with APPROVAL_TOKEN, APPROVAL_ACTOR, and APPROVAL_ISSUE_TITLE to verify the approving actor’s effective target-repository role without exposing RBAC data.
• 🟡 (15:25) .github/workflows/publish.yml rejects an approval when steps.authorization.outcome != 'success' or steps.authorization.outputs.authorized != 'true': it removes accepted, comments that @${{ github.actor }} cannot approve this release. Approvers must have write, maintain, or admin access to the target repository., then exits 1.
• 🟡 (15:25) .github/workflows/publish.yml resets accepted releases to clean CI-waiting state in the Mark ci-pending step: gh issue edit removes ci-failed and ci-ready and adds ci-pending. Label operations are idempotent. Removing ci-ready is necessary for retry after publish failure because leaving it would cause the poller’s later --add-label not to emit a label event, so publish.yml would not fire.
• 🟡 (15:25) .github/workflows/publish.yml comments Retrying — CI was previously failed. Checking CI status now. if the triggering issue labels included ci-failed; otherwise it comments Approved. Checking CI status on the release branch. Publishing will start automatically when CI passes.
• 🟡 (15:25) .github/workflows/publish.yml best-effort enables cron polling with a dedicated poller app token because sentry-internal-app lacks actions_variables:write; when token creation succeeds, it sets repository variable CI_POLLER_HAS_PENDING to "true" via gh variable set.
• 🟡 (15:25) .github/workflows/publish.yml immediately triggers ci-poller.yml via gh workflow run ci-poller.yml -R "$GITHUB_REPOSITORY" using the internal app token, because GITHUB_TOKEN-created workflow_dispatch events are suppressed.
• 🟡 (15:25) .github/workflows/publish.yml publish job runs on ubuntu-latest, uses environment: production, is named Publish a new version, and fires only on ci-ready label events—not accepted—to avoid racing with waiting-for-ci on the same event.