Distillation

Date: Aug 27, 2026

• 🔴 (13:41) User stated that workflow_dispatch must always be allowed for manual recovery.
• 🟡 (13:41) .github/workflows/ci-status-poller.yml is scheduled with cron */5 * * * *, uses concurrency group ci-status-poller, and documents that workflow_dispatch remains enabled for manual recovery.
• 🟡 (13:41) The CI-status poller checks only issues carrying both ci-pending and accepted labels, queries up to 200 issues, and checks CI for ${repo}@${version} at a resolved commit SHA, logging the first 8 SHA characters and issue number.
• 🟡 (13:41) CI-status poller cross-repository GitHub API calls use a sentry-release-bot token; label changes on the current repository use a sentry-internal-app token. A gh_api_release helper handles release-bot API calls, and API failures are non-fatal where the workflow can fall back to the issue SHA.
• 🟡 (13:41) The CI-status poller parses publish issue titles to obtain repo, resolves a branch HEAD when possible because it may differ from issue_sha, and uses the issue SHA as fallback.
• 🟡 (13:41) The CI-status poller fetches commit status from repos/${repo}/commits/${sha}/status and paginates check-run retrieval to support repositories with more than 30 checks.
• 🟡 (13:41) CI-status poller treats a completed check run as unsuccessful when its conclusion is not success, neutral, or skipped; it logs that CI may not have started when neither check runs nor commit statuses exist.
• 🟡 (13:41) CI passes only when all check runs are completed and no failures are detected; repositories with no commit statuses are supported as check-run-only repositories. On success, the poller adds ci-ready and comments CI passed!.
• 🟡 (13:41) On CI failure, the poller removes acceptance so the author must fix CI and re-add accepted to retry; it builds failed-check names and failure-status output with links when target_url is present.
• 🟡 (13:41) The workflow has a remaining-pending fallback because a CI-check-step failure prevents CI_POLLER_HAS_PENDING from being set; token generation for a later step is deliberately placed after CI checking so token failure cannot block CI checking.
• 🟡 (13:41) The CI-status poller stops/requires manual intervention when retry attempt is at least 60; otherwise its fallback continues checking and restarts the chain on the next run.
• 🟡 (13:43) Search found 20 matches involving “branch” across workflows. .github/workflows/docs-preview.yml references fetching an existing gh-pages branch, adding .nojekyll to it, creating an orphan gh-pages branch when absent, and preview-branch: gh-pages.
• 🟡 (13:43) Search results show branch filters in .github/workflows/build.yml; .github/workflows/enforce-license-compliance.yml uses branches: [master] twice; .github/workflows/image.yml uses branches: [master, release/**, test-me-*]; and .github/workflows/lint.yml uses branches: [master].
• 🟡 (13:43) .github/workflows/release.yml contains a “Target branch to merge into” input description; “Use the craft config from the merge target branch”; a release-branch output branch from ${{ jobs.release.outputs.branch }}; a commit-SHA-on-release-branch description; branch output selection ${{ steps.craft-local.outputs.branch || steps.craft-action.outputs.branch }}; and workspace/path forwarding via ${{ github.event.inputs.workspace }}, ${{ inputs.path }}, and ${{ inputs.workspace }}.