Dashboard › publish › Distillation
6232ce34-6d1a-4de8-baa5-3108f4aa232d["lore_tm_v1_UzFRkDg2VSlHYAbXbpZkUQTRIX6M6svNxxAVa0z5Pao"]
/home/byk/Code/getsentry/publish/.github/workflows/ci-poller.yml defines CI Status Poller, triggered every 5 minutes by cron */5 * * * *, by repository_dispatch type ci-poller, and when workflow Run CI Status Poller completes.check-ci job runs on ubuntu-latest in the production environment with concurrency group ci-status-poller and cancel-in-progress: false; it runs when vars.CI_POLLER_HAS_PENDING == 'true', on any repository_dispatch, or after a successful workflow_run whose head_branch equals the repository default branch.^(0|[1-5][0-9])$, permitting exact integer strings 0 through 59; invalid values emit repository_dispatch attempt must be an integer from 0 through 59 and exit 1.actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 step explicitly checks out ${{ github.event.repository.default_branch }} with persist-credentials: false, rather than trusting an arbitrary dispatch ref.SENTRY_INTERNAL_APP_ID and protected SENTRY_INTERNAL_APP_PRIVATE_KEY for label changes that must trigger .github/workflows/publish.yml; it separately obtains a sentry-release-bot token using SENTRY_RELEASE_BOT_CLIENT_ID, protected SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry for cross-repository check-suite, status, and check-run API access, including private repositories where the internal app would return 404.gh_api_release() executes gh api in a subshell with GH_TOKEN="$RELEASE_TOKEN", captures stdout and stderr, returns the API exit code on failure, and emits ::warning::gh api failed: ...; this prevents the release-bot token override from leaking into label-changing calls.200 open issues carrying both ci-pending and accepted, requesting number,title,labels,body; it exits successfully when none exist and otherwise checks each issue.src/publish/current-accepted-event.js, preserving its .actor and .eventId, then runs src/publish/validate-approval-attestation.js with APPROVAL_ATTESTATION_AUTHOR="github-actions[bot]", EXPECTED_ACCEPTED_ACTOR, and EXPECTED_ACCEPTED_EVENT_ID.ci-pending and accepted, comments Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue., and skips that issue.parsePublishTitle() from ./src/modules/details-from-context.js, constructs repository getsentry/<repo>, and extracts .version; an unparseable repository/version emits a warning and leaves the issue pending.[0-9a-f]{40} between commit/ and /checks; if no SHA can be extracted, the issue is skipped.release/{version}, the poller queries repos/${repo}/commits/${issue_sha}/check-suites and uses .check_suites[0].head_branch; it then queries repos/${repo}/git/ref/heads/${branch} for .object.sha. Either lookup may fail non-fatally, falling back to the issue SHA.repos/${repo}/commits/${sha}/status and paginates all check runs from repos/${repo}/commits/${sha}/check-runs using --paginate --jq '.check_runs[]'; failure of either API call causes the issue to be skipped rather than deriving CI state from partial data.commit_status, total_statuses, total_checks, checks whose .status != "completed" as pending_checks, and completed checks as unsuccessful unless their conclusion is exactly success, neutral, or skipped; unsuccessful examples identified in comments are failure, cancelled, timed_out, action_required, stale, and startup_failure.success or total_statuses == 0, while pending_checks == 0 and unsuccessful_checks == 0.src/publish/record-ci-ready-attestation.js, posts that attestation using ${{ github.token }} so its author is github-actions[bot], and revalidates the approval once more immediately before changing labels.mktemp file supplied as GITHUB_OUTPUT; it must begin exactly ci_ready_attestation=. Missing/invalid output, failure to generate or post proof, or any approval change removes ci-pending and accepted, posts the standard invalid-approval retry comment, and prevents progression.ci-pending and addition of ci-ready, then comments CI checks passed for ${repo}@${version}. Publishing is starting now. Because only issues retaining both ci-pending and accepted are polled, adding ci-ready starts publishing.ci-pending and accepted, adds ci-failed, lists failed check names, links to https://github.com/${repo}/commit/${sha}/checks/, and instructs the author to re-add accepted after fixing CI.failure, the poller likewise swaps ci-pending for ci-failed and removes accepted; it lists status entries whose state is failure or error, including target_url links when present, and asks for accepted to be re-added after repair.if: always(): it checks whether at least one open issue still has both ci-pending and accepted, obtains a poller-app token using CI_POLLER_APP_CLIENT_ID and protected CI_POLLER_APP_PRIVATE_KEY, and synchronizes repository variable CI_POLLER_HAS_PENDING to exact string "true" or "false".*/5 cron may drift to 30–40 min; self-dispatch targets approximately 30–60s between checks via Actions startup latency, while the concurrency group limits accumulation to 1 running plus 1 queued execution.attempt=$((10#$ATTEMPT + 1)), stops when the incremented value is >= 60, and otherwise posts repository dispatch payload {"event_type":"ci-poller","client_payload":{"attempt":"<attempt>"}}. The 60-attempt chain is described as approximately 30 min, after which cron remains the fallback and a later accepted-label or workflow-dispatch relay can restart the chain.