Dashboard › publish › Distillation
e8c19986-d53a-4dab-a9fd-ca7dfbf9aeea["lore_tm_v1_HsQpnZ4sn3Zr1jjndK3sa08EfAqkrEuJYvvjRQKPRz4"]
/home/byk/Code/getsentry/publish/.github/workflows/publish.yml defines the GitHub Actions workflow Publish, triggered by issues with types: [labeled]./home/byk/Code/getsentry/publish/.github/workflows/publish.yml uses concurrency group ${{ github.event.issue.title }} with cancel-in-progress: false, so duplicate issues for the same repo@version title share a concurrency group without cancelling an in-progress run.Publish workflow grants contents: read, issues: write, and packages: write.waiting-for-ci job runs on ubuntu-latest in the production environment only when the added label is accepted, the issue is open, and its title starts with publish: .waiting-for-ci flow is designed to add ci-pending, remove ci-failed when retrying, enable the poller via CI_POLLER_HAS_PENDING=true, comment on the issue, and trigger the poller immediately; publishing requires ci-ready to prevent publishing without CI verification during an auto-approve race.actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 with persist-credentials: false.Get auth token step uses actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1, vars.SENTRY_INTERNAL_APP_ID, and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY.Get release bot auth token step is continue-on-error: true and uses actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 with vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry; this token checks the actor’s current effective target-repository role without exposing RBAC data.Authorize approval step runs node src/publish/authorize-approval.js with APPROVAL_TOKEN, APPROVAL_ACTOR, APPROVAL_ISSUE_NUMBER, APPROVAL_ISSUE_REPOSITORY, and APPROVAL_ISSUE_TITLE; it is continue-on-error: true.steps.authorization.outputs.authorized == 'true', the workflow records an approval attestation by running gh issue comment with ${{ steps.authorization.outputs.approval_attestation }}.Validate approval attestation step runs node src/publish/validate-approval-attestation.js only after the attestation step succeeds, using APPROVAL_TOKEN: ${{ github.token }}, APPROVAL_ATTESTATION_AUTHOR: github-actions[bot], and the issue number, repository, and title; it is continue-on-error: true.Reject invalid approval step runs under always() if authorization failed, authorization did not return authorized == 'true', attestation failed, or approval validation failed; it removes the accepted label, comments Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue., and exits with status 1.Mark ci-pending step resets issue labels idempotently by removing ci-failed and ci-ready, then adding ci-pending; removing an existing ci-ready ensures a later fresh ci-ready labeled event can fire after a failed publish retry.Retrying — CI was previously failed. Checking CI status now. when the original issue labels contain ci-failed; otherwise it is Approved. Checking CI status on the release branch. Publishing will start automatically when CI passes.sentry-internal-app lacks actions_variables:write; the Get poller app token step is best-effort with continue-on-error: true and uses vars.CI_POLLER_APP_CLIENT_ID plus secrets.CI_POLLER_APP_PRIVATE_KEY.gh variable set CI_POLLER_HAS_PENDING -R "$GITHUB_REPOSITORY" -b "true" enables the cron poller.gh api --method POST "repos/$GITHUB_REPOSITORY/dispatches" -f event_type=ci-poller; the comment states GITHUB_TOKEN workflow-dispatch events are suppressed.publish job runs on ubuntu-latest in the production environment with display name Publish a new version.ci-ready after checking CI; waiting-for-ci first removes any existing ci-ready, ensuring a fresh labeled event on the happy path.publish job fires only for ci-ready label events, not accepted, to avoid racing with waiting-for-ci on the same event.