Distillation

Date: Sep 3, 2026

• 🔴 (16:51) User stated workflow dispatch must always be allowed for manual recovery.
• 🟡 (16:51) .github/workflows/ci-poller.yml defines workflow CI Status Poller, scheduled every 5 minutes via cron "*/5 * * * *", plus workflow_dispatch with optional internal attempt input defaulting to "0".
• 🟡 (16:51) CI Status Poller permissions are contents: read and issues: read; job check-ci runs on ubuntu-latest in environment production.
• 🟡 (16:51) check-ci runs only when vars.CI_POLLER_HAS_PENDING == 'true' || github.event_name == 'workflow_dispatch'; comments specify ci-pending.yml sets CI_POLLER_HAS_PENDING to "true" and this workflow resets it to "false" when done, while workflow_dispatch remains available for manual recovery.
• 🟡 (16:51) check-ci concurrency is group ci-status-poller with cancel-in-progress: false.
• 🟡 (16:51) ci-poller.yml creates a sentry-internal-app token in step Get auth token (id: token) using actions/create-github-app-token@v3, vars.SENTRY_INTERNAL_APP_ID, and secret SENTRY_INTERNAL_APP_PRIVATE_KEY; comments state this token performs label changes in the controller repo so events trigger downstream publish.yml, because GITHUB_TOKEN cannot.
• 🟡 (16:51) ci-poller.yml separately creates a sentry-release-bot cross-repository token in Get release bot auth token (id: release-token) via actions/create-github-app-token@v3, vars.SENTRY_RELEASE_BOT_CLIENT_ID, secret SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry; comments state the internal app is not installed on some private repositories including sentry-xbox, sentry-playstation, sentry-switch, and service-registry, where it would return 404.
• 🟡 (16:51) Workflow step Check out publish controller uses actions/checkout@v5 with path: .__publish__.
• 🟡 (16:51) Step Check CI status for ci-pending issues sets GH_TOKEN to ${{ steps.token.outputs.token }} for controller-repo label edits and RELEASE_TOKEN to ${{ steps.release-token.outputs.token }} for cross-repo API calls.
• 🟡 (16:51) The shell helper gh_api_release() invokes GH_TOKEN="$RELEASE_TOKEN" gh api "$@", captures stderr/stdout, emits ::warning::gh api failed: $output and returns nonzero on API failures including 404s, otherwise prints its output; it uses a subshell-scoped token override so GH_TOKEN does not leak to other calls.
• 🟡 (16:51) CI poller lists at most 200 open issues in $GITHUB_REPOSITORY carrying both ci-pending and accepted labels, retrieving number,title,labels,body; it exits successfully when the count is zero. Comments state requiring accepted avoids polling abandoned releases nobody approved.
• 🟡 (16:51) For each eligible issue, the workflow invokes node .__publish__/src/publish/resolve-ci-poller-input.js with PUBLISH_ISSUE_BODY="$body" and PUBLISH_TITLE="$title"; on parsing failure it warns Could not parse canonical publish input for issue #${number}, skipping. and continues. On success it extracts .repo, .version, and .revision as repo, version, and issue_sha.
• 🟡 (16:51) The poller derives the release branch from repos/${repo}/commits/${issue_sha}/check-suites using --jq '.check_suites[0].head_branch // empty', rather than hard-coding release/{version} because repositories may customize branch names in craft config; API failures are non-fatal and fall back to issue_sha.
• 🟡 (16:51) When a branch is found, the poller resolves its HEAD from repos/${repo}/git/ref/heads/${branch} with --jq '.object.sha'; if unavailable it logs Could not resolve HEAD of ${branch}, using issue SHA. and uses issue_sha. If no check suite branch is found it logs No check suites found for ${issue_sha:0:8}, using issue SHA. and uses issue_sha.
• 🟡 (16:51) If branch HEAD sha differs from issue_sha, the workflow logs the move and updates the issue body’s check-runs link by rerunning resolve-ci-poller-input.js with PUBLISH_ISSUE_BODY, PUBLISH_REVISION="$sha", and PUBLISH_TITLE, extracting .issueBody, then calling gh issue edit "$number" -R "$GITHUB_REPOSITORY" --body "$updated_body".
• 🟡 (16:51) The poller fetches combined commit status through repos/${repo}/commits/${sha}/status; failure logs Could not fetch commit status for ${repo}@${sha:0:8}, skipping. and does not derive state from partial data. It extracts .state as commit_status and .total_count as total_statuses.
• 🟡 (16:51) The poller fetches all check runs paginated through gh_api_release --paginate "repos/${repo}/commits/${sha}/check-runs" --jq '.check_runs[]'; failure logs Could not fetch check runs for ${repo}@${sha:0:8}, skipping. It computes total_checks, pending_checks where .status != "completed", and unsuccessful_checks where status is completed but conclusion is not success, neutral, or skipped.
• 🟡 (16:51) The workflow considers success, neutral, and skipped check-run conclusions passing; non-successful conclusions explicitly include failure, cancelled, timed_out, action_required, stale, and startup_failure.
• 🟡 (16:51) The poller requires at least one check run or one commit status before evaluating CI readiness; when both total_checks and total_statuses are "0", it logs that CI may not have started and continues.
• 🟡 (16:51) The displayed readiness logic marks commit status acceptable when commit_status == "success" or total_statuses == "0"; comments explain the latter permits repositories that use check runs only, while CI readiness also requires no pending check runs and no unsuccessful check runs.