Distillation

Date: Sep 8, 2026

• 🔴 (10:27) User asserted: “Always allow workflow_dispatch for manual recovery.” ci-poller.yml gates check-ci with if: vars.CI_POLLER_HAS_PENDING == 'true' || github.event_name == 'workflow_dispatch'.
• 🔴 (10:27) User asserted: “Always run trusted code.” For workflow_dispatch, .github/workflows/ci-poller.yml checks out ${{ github.event.repository.default_branch }} rather than the dispatched ref, using actions/checkout@v6 with persist-credentials: false.
• 🔴 (10:27) User asserted: “Never move a release to ci-ready after it changes.” check-ci binds each poll cycle to the current accepted-label event via src/publish/current-accepted-event.js, captures accepted_actor and accepted_event_id, and repeatedly runs src/publish/validate-approval-attestation.js before CI checking, after CI passes, and immediately before applying ci-ready.
• 🔴 (10:27) User asserted that a renamed or re-approved issue “never reaches ci-ready.” The workflow removes ci-pending and accepted, then comments “Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.” whenever approval-event binding, approval-attestation validation, CI-ready attestation recording, CI-ready proof format, or CI-ready proof comment recording fails.
• 🟡 (10:27) User provided .github/workflows/ci-poller.yml (442 lines), named CI Status Poller; it runs on schedule cron: "*/5 * * * *" and workflow_dispatch with optional attempt input defaulting to "0".
• 🟡 (10:27) ci-poller.yml permissions are contents: read and issues: write; check-ci runs on ubuntu-latest in environment: production, uses concurrency group ci-status-poller, and sets cancel-in-progress: false.
• 🟡 (10:27) The poller checks only open issues carrying both ci-pending and accepted labels, with gh issue list --limit 200 --json number,title,labels,body; if none are found, it exits successfully.
• 🟡 (10:27) The workflow creates a label-change token using actions/create-github-app-token@v3, vars.SENTRY_INTERNAL_APP_ID, and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY; it creates a separate cross-repository release-bot token using vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry. GH_TOKEN is used for label changes so downstream publish.yml triggers; RELEASE_TOKEN is used for cross-repository check/status API calls because the internal app is not installed on some private repositories, including sentry-xbox, sentry-playstation, sentry-switch, and service-registry.
• 🟡 (10:27) The workflow defines gh_api_release() to invoke gh api under GH_TOKEN="$RELEASE_TOKEN", capture stdout, emit ::warning::gh api failed: ... on nonzero exit, and preserve the failure exit code.
• 🟡 (10:27) Repository and version are parsed from each issue title using parsePublishTitle imported from ./src/modules/details-from-context.js; the target repository becomes getsentry/ plus the parsed repo. Issues with unparseable repo/version are skipped.
• 🟡 (10:27) The poller extracts a 40-character SHA from an issue-body https://github.com/{owner}/{repo}/commit/{SHA}/checks/ link. It resolves the branch from repos/${repo}/commits/${issue_sha}/check-suites and branch HEAD from repos/${repo}/git/ref/heads/${branch} using release-bot access; API-resolution failures are nonfatal and fall back to issue_sha. If the branch head differs, it replaces the SHA in the issue body via gh issue edit.
• 🟡 (10:27) CI status is fetched from repos/${repo}/commits/${sha}/status; check runs are fetched paginated from repos/${repo}/commits/${sha}/check-runs via --paginate --jq '.check_runs[]'. If either API request fails, the issue is skipped rather than deriving state from partial data.
• 🟡 (10:27) CI readiness requires at least one check run or commit status; commit status must be success or have total_statuses == 0; pending_checks must be 0; and unsuccessful_checks must be 0. Completed check conclusions success, neutral, and skipped are treated as passing; other completed conclusions, including failure, cancelled, timed_out, action_required, stale, and startup_failure, are unsuccessful.
• 🟡 (10:27) Before applying ci-ready, the workflow runs src/publish/record-ci-ready-attestation.js with the expected accepted actor/event ID, requires output beginning ci_ready_attestation=, posts the resulting proof comment using GH_TOKEN="${{ github.token }}", then revalidates approval attestation once more. On success it swaps ci-pending for ci-ready and comments: CI checks passed for ${repo}@${version}. Publishing is starting now.
• 🟡 (10:27) If all check runs are completed and any are unsuccessful, the workflow swaps ci-pending to ci-failed, removes accepted, and comments with failed check names, SHA, a check-runs URL, and instructions to re-add accepted after fixing CI. If commit status is failure while all check runs pass, it performs the same label transition and comments with failed/error status contexts and target URLs where available.
• 🟡 (10:27) Cleanup runs with if: always(): Check for remaining pending issues counts open issues with both ci-pending and accepted using GH_TOKEN: ${{ github.token }}. A CI_POLLER_APP_CLIENT_ID/CI_POLLER_APP_PRIVATE_KEY GitHub App token is then used to set CI_POLLER_HAS_PENDING to "false" when count is 0, otherwise "true".
• 🟡 (10:27) The workflow self-dispatches ci-poller.yml when issues remain pending and the initial token/count steps succeeded, passing incremented attempt via gh workflow run ci-poller.yml -R "$GITHUB_REPOSITORY" -f attempt="${attempt}". It caps self-dispatch at 60 attempts (approximately 30 minutes), then relies on cron fallback; comments state cron */5 can drift to 30–40 minutes under load, whereas self-dispatch generally yields approximately 30–60 seconds between checks, and concurrency permits one running plus one queued run.