Distillation

Date: Sep 5, 2026

• 🔴 (18:59) User stated the ci-poller must bind each polling cycle to the current accepted-label event before inspecting CI and must never move a release to ci-ready after that approval event changes.
• 🔴 (18:59) User stated that after the final CI check, approval must be revalidated so a renamed or re-approved issue never reaches ci-ready.
• 🔴 (18:59) User stated the ci-poller always adds ci-ready; publish.yml removes ci-ready first so that a fresh labeled event fires, making the publish-job gate safe.
• 🔴 (18:59) User stated workflow_dispatch must always be allowed for manual recovery.
• 🟡 (18:59) Current working tree in /home/byk/Code/getsentry/publish has modifications including .github/workflows/ci-poller.yml, .github/workflows/publish.yml, AGENTS.md, src/libs/__tests__/github.js, src/libs/github.js, src/modules/__tests__/update-issue.js, src/modules/details-from-context.js, src/modules/update-issue.js, src/publish/post-workflow-details.js, and src/publish/update-issue.js; .github/workflows/ci-poller.yml shows 140 changed lines.
• 🟡 (18:59) .github/workflows/ci-poller.yml changes workflow permissions from issues: read to issues: write, polls only issues carrying both ci-pending and accepted, obtains an accepted-label event ID and actor, and uses EXPECTED_ACCEPTED_EVENT_ID/EXPECTED_ACCEPTED_ACTOR during validation.
• 🟡 (18:59) The ci-poller parses the issue title, extracts a commit SHA from the issue-body “View check runs” link, resolves the release branch from the original commit’s check runs, queries repos/${repo}/commits/${sha}/check-runs with pagination, and distinguishes pending, unsuccessful, absent, successful, and failed CI states.
• 🟡 (18:59) On approval binding/validation or CI-ready-proof failure, ci-poller behavior shown removes accepted (and in some paths ci-pending), posts “Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.”, and logs warnings; on CI failure it swaps ci-pending to ci-failed and removes accepted.
• 🟡 (18:59) ci-poller invokes node src/publish/record-ci-ready-attestation.js to create CI-ready proof and uses APPROVAL_ATTESTATION_AUTHOR="github-actions[bot]" for approval-attestation validation.
• 🟡 (18:59) publish.yml contains an approval authorization/attestation flow: node src/publish/authorize-approval.js runs with continue-on-error: true; an approval-validation step runs node .__publish__/src/publish/validate-approval-attestation.js; invalid validation has an always() failure-handling path that comments on the issue.
• 🟡 (18:59) publish.yml has a publish-job gate requiring ci-ready and excluding ci-failed; it checks out the publish source into .__publish__ and uses node .__publish__/src/publish/inputs.js.
• 🟡 (18:59) publish.yml cleanup/result steps at lines 383–409 run node .__publish__/src/publish/update-issue.js on ${{ cancelled() || failure() }}, post-result.js cancelled on cancellation, post-result.js failure on failure, and post-result.js success on success; each passes PUBLISH_ARGS: ${{ steps.inputs.outputs.result }} and GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}.
• 🟡 (18:59) ci-poller.yml defines workflow_dispatch inputs, uses concurrency group ci-status-poller, obtains a release-bot token, and includes fallback handling for cases where the CI check step fails before CI_POLLER_HAS_PENDING is set.