Distillation

Date: Sep 8, 2026

• 🔴 (02:52) User stated that ci-poller.yml must always allow workflow_dispatch for manual recovery.
• 🟡 (02:52) .github/workflows/ci-poller.yml is named CI Status Poller; triggers on cron */5 * * * * and workflow_dispatch with optional internal attempt input defaulting to "0". It has contents: read and issues: read permissions.
• 🟡 (02:52) .github/workflows/ci-poller.yml job check-ci runs on ubuntu-latest in production, only when vars.CI_POLLER_HAS_PENDING == 'true' || github.event_name == 'workflow_dispatch', and uses concurrency group ci-status-poller with cancel-in-progress: false.
• 🟡 (02:52) .github/workflows/ci-poller.yml obtains a sentry-internal-app token through actions/create-github-app-token@v3 using vars.SENTRY_INTERNAL_APP_ID and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY for publish-repository label changes that trigger downstream publish.yml.
• 🟡 (02:52) .github/workflows/ci-poller.yml separately obtains a release-bot token through actions/create-github-app-token@v3, using vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry, for cross-repository API access because the internal app may return 404 for private repositories including sentry-xbox, sentry-playstation, sentry-switch, and service-registry.
• 🟡 (02:52) .github/workflows/ci-poller.yml checks out the publish controller into .__publish__ with actions/checkout@v7, replacing the earlier audit finding of actions/checkout@v6 in this workflow.
• 🟡 (02:52) .github/workflows/ci-poller.yml lists up to 200 open issues carrying both ci-pending and accepted labels; it exits if none exist, deliberately avoiding polling abandoned unapproved releases.
• 🟡 (02:52) .github/workflows/ci-poller.yml defines gh_api_release(), which invokes gh api under GH_TOKEN="$RELEASE_TOKEN" in a subshell, captures stderr/stdout, emits ::warning::gh api failed: ... and exits nonzero on API errors including 404s, and otherwise prints API output.
• 🟡 (02:52) For each pending accepted issue, .github/workflows/ci-poller.yml writes the body to mktemp, calls node .__publish__/src/publish/resolve-ci-poller-input.js with PUBLISH_ISSUE_BODY_FILE and PUBLISH_TITLE, and skips malformed canonical publish inputs with warning "Could not parse canonical publish input for issue #<number>, skipping."
• 🟡 (02:52) .github/workflows/ci-poller.yml resolves the release branch from repos/${repo}/commits/${issue_sha}/check-suites using .check_suites[0].head_branch // empty; it then resolves branch HEAD from repos/${repo}/git/ref/heads/${branch} using .object.sha, falling back non-fatally to the issue SHA if either lookup fails.
• 🟡 (02:52) When a release branch HEAD differs from the canonical issue SHA, .github/workflows/ci-poller.yml updates only the issue body’s canonical View check-runs revision by rerunning src/publish/resolve-ci-poller-input.js with PUBLISH_REVISION="$sha" and edits the issue using gh issue edit --body-file.
• 🟡 (02:52) .github/workflows/ci-poller.yml fetches combined commit status from repos/${repo}/commits/${sha}/status and paginated check runs from repos/${repo}/commits/${sha}/check-runs; either API failure skips that issue rather than deriving CI state from partial data.
• 🟡 (02:52) .github/workflows/ci-poller.yml counts total_statuses, total_checks, incomplete check runs (.status != "completed"), and unsuccessful completed check runs whose conclusion is not success, neutral, or skipped; it leaves issues pending when both check/status counts are zero because CI may not yet have started.
• 🟡 (02:52) .github/workflows/ci-poller.yml marks CI ready only when commit status is success or there are zero commit statuses, all check runs are complete, and there are zero unsuccessful check runs. It removes ci-pending, adds ci-ready, and comments "CI checks passed for ${repo}@${version}. Publishing is starting now."
• 🟡 (02:52) .github/workflows/ci-poller.yml treats completed unsuccessful check runs as CI failure: removes ci-pending and accepted, adds ci-failed, comments failed check names plus https://github.com/${repo}/commit/${sha}/checks/, and instructs the author to re-add accepted after fixing CI.
• 🟡 (02:52) .github/workflows/ci-poller.yml separately treats commit_status == "failure" with no pending or unsuccessful check runs as a commit-status failure: removes ci-pending and accepted, adds ci-failed, and comments failed status contexts with target URLs when available plus the check-runs link.
• 🟡 (02:52) .github/workflows/ci-poller.yml has an always() cleanup step that checks whether any open issues retain both ci-pending and accepted; it uses a separate app token created from vars.CI_POLLER_APP_CLIENT_ID and secrets.CI_POLLER_APP_PRIVATE_KEY to set repository variable CI_POLLER_HAS_PENDING to "false" when none remain or "true" otherwise.
• 🟡 (02:52) .github/workflows/ci-poller.yml self-dispatches ci-poller.yml through gh workflow run ... -f attempt="${attempt}" whenever pending issues remain and the initial token/check succeeds; it increments ATTEMPT, caps self-dispatch at 60 attempts, expects roughly 30–60 seconds between runs from Actions startup latency, and falls back to cron after the cap because */5 cron may drift to 30–40 minutes under load.