Distillation

Date: Sep 8, 2026

• 🟡 (02:13) .github/workflows/ci-poller.yml defines CI Status Poller, triggered by cron */5 * * * * and workflow_dispatch with optional attempt input defaulting to "0"; check-ci runs on ubuntu-latest in production only when vars.CI_POLLER_HAS_PENDING == 'true' || github.event_name == 'workflow_dispatch', with concurrency group ci-status-poller and cancel-in-progress: false.
• 🟡 (02:13) .github/workflows/ci-poller.yml obtains a label-change token via actions/create-github-app-token@v3 using SENTRY_INTERNAL_APP_ID/SENTRY_INTERNAL_APP_PRIVATE_KEY, and a cross-repository release-bot token via the same action using SENTRY_RELEASE_BOT_CLIENT_ID/SENTRY_RELEASE_BOT_PRIVATE_KEY with owner: getsentry; it checks out the publish controller with actions/checkout@v7 at .__publish__.
• 🟡 (02:13) CI poller lists up to 200 open issues carrying both ci-pending and accepted; for each, it invokes .__publish__/src/publish/resolve-ci-poller-input.js with PUBLISH_ISSUE_BODY and PUBLISH_TITLE, skips issues whose canonical publish input cannot be parsed, and derives repo, version, and authoritative issue_sha revision from the result.
• 🟡 (02:13) CI poller resolves a release branch from repos/${repo}/commits/${issue_sha}/check-suites and its current head from repos/${repo}/git/ref/heads/${branch} using gh_api_release; API failures are non-fatal and fall back to issue_sha. When branch head differs, it regenerates the issue body through resolve-ci-poller-input.js with PUBLISH_REVISION="$sha" and updates the issue body before checking CI.
• 🟡 (02:13) CI poller fetches combined commit status from repos/${repo}/commits/${sha}/status and all paginated check runs from repos/${repo}/commits/${sha}/check-runs; it skips polling if either API call fails or if both total_checks and total_statuses are 0. It treats check-run conclusions success, neutral, and skipped as passing; any other completed conclusion is unsuccessful.
• 🟡 (02:13) CI poller marks CI ready only when commit status is success or no commit statuses exist, no check runs are pending, and no check runs are unsuccessful; it then removes ci-pending, adds ci-ready, and comments CI checks passed for ${repo}@${version}. Publishing is starting now..
• 🟡 (02:13) CI poller treats completed unsuccessful check runs as CI failure: removes ci-pending and accepted, adds ci-failed, and comments failed check names plus [View check runs](https://github.com/${repo}/commit/${sha}/checks/); it separately handles a failing combined commit status when all check runs passed, listing failed/error status contexts and links where available.
• 🟡 (02:13) CI poller cleanup always checks whether any open issue has both ci-pending and accepted; using a separate CI_POLLER_APP_CLIENT_ID/CI_POLLER_APP_PRIVATE_KEY app token, it sets repository variable CI_POLLER_HAS_PENDING to "false" when none remain or "true" when issues remain.
• 🟡 (02:13) CI poller self-dispatches ci-poller.yml with incremented attempt when pending issues remain and its primary token and remaining-issues check succeeded; it caps self-dispatch at 60 attempts, then relies on cron fallback. Comments specify expected ~30–60-second self-dispatch intervals, unreliable cron drift to 30–40 minutes under load, and a concurrency limit of 1 running plus 1 queued workflow.