DashboardpublishDistillation

Distillation

ID: 0fb67a8c-8988-491f-9e88-d36cf96191aa
Session: 1V5okji1pQaM
Generation: 0
Tokens: 1757
R_compression: 14.969
C_norm: 0.000
Archived: No
Created: 2026-09-10 16:47:54
Source IDs:
["lore_tm_v1_0KgJu3S-vR3JHrKzTNRHK6hofSnrRF27z9V1SxbKgkc","lore_tm_v1_OUdVurQS0BiedqaRPESKQK9YQltnHqNIxiVVwU4AEw4","lore_tm_v1_2tZxQQiScSBly75dWBcbiNebtOEaJMVQNYQecsd5Mz8"]

Observations

πŸ”΄ (16:14) /home/byk/Code/getsentry/publish/auto-approve-repos.txt contains exactly 46 entries, in order: 1. getsentry/arroyo; 2. getsentry/auto-type-annotate; 3. getsentry/devenv; 4. getsentry/infra-event-notifier; 5. getsentry/jest-sentry-environment; 6. getsentry/json-schema-diff; 7. getsentry/js-source-scopes; 8. getsentry/objectstore/clients; 9. getsentry/ophio; 10. getsentry/pdb; 11. getsentry/pyo3-python-tracing-subscriber; 12. getsentry/pytest-sentry; 13. getsentry/relay/py; 14. getsentry/responses; 15. getsentry/rust-proguard; 16. getsentry/rust-sourcemap; 17. getsentry/rust-usage-accountant; 18. getsentry/script-runner; 19. getsentry/sentry-api-schema; 20. getsentry/sentry-forked-djangorestframework-stubs; 21. getsentry/sentry-forked-django-stubs; 22. getsentry/sentry-forked-jsonnet; 23. getsentry/sentry-infra-tools; 24. getsentry/sentry-kafka-management; 25. getsentry/sentry-kafka-schemas; 26. getsentry/sentry-protos; 27. getsentry/sentry-redis-tools; 28. getsentry/service-registry; 29. getsentry/skrooge; 30. getsentry/snuba-sdk; 31. getsentry/statsdproxy; 32. getsentry/status-page-list; 33. getsentry/streams/sentry_streams; 34. getsentry/symbolic; 35. getsentry/taskbroker/clients; 36. getsentry/usage-accountant; 37. getsentry/watto; 38. getsentry/sentry; 39. getsentry/snuba; 40. getsentry/vroom; 41. getsentry/relay; 42. getsentry/symbolicator; 43. getsentry/taskbroker; 44. getsentry/uptime-checker; 45. getsentry/launchpad; 46. getsentry/self-hosted. πŸ”΄ (16:14) .github/workflows/ci-poller.yml is being expanded from 324 to 509 lines and replaces its direct workflow_dispatch trigger plus internal attempt input with repository_dispatch type ci-poller and workflow_run completion events for workflow Run CI Status Poller; its existing "*/5 * * * *" schedule remains. πŸ”΄ (16:14) .github/workflows/ci-poller.yml changes top-level issue permission from issues: read to issues: write. πŸ”΄ (16:14) User directed that workflow_dispatch must always be allowed for manual recovery. πŸ”΄ (16:14) The CI poller’s trusted manual-recovery paths are repository_dispatch and a successful workflow_run of the protected workflow_dispatch relay from the repository default branch. πŸ”΄ (16:14) The check-ci job condition now runs when vars.CI_POLLER_HAS_PENDING == 'true', on repository_dispatch, or when github.event_name == 'workflow_run', github.event.workflow_run.conclusion == 'success', and github.event.workflow_run.head_branch == github.event.repository.default_branch. πŸ”΄ (16:14) User directed that workflow execution must always use trusted code, because workflow_dispatch can target any ref. πŸ”΄ (16:14) User directed that a release must never be moved to ci-ready after its approval request changes. πŸ”΄ (16:14) CI-poller processing now captures the current accepted-label event before inspecting CI, extracts accepted_event_id from .eventId, and binds later processing to that accepted event and the request digest. πŸ”΄ (16:14) User stated that a renamed or re-approved publish issue must never reach ci-ready. πŸ”΄ (16:14) CI-poller failure/recovery paths shown in the diff can edit issue labels, including removing "accepted", while successful progression removes "ci-pending" and adds "ci-ready". πŸ”΄ (16:14) After adding "ci-ready", the CI poller comments CI checks passed for ${repo}@${version}. Publishing is starting now.; it polls only issues carrying both ci-pending and accepted, so publishing begins when ci-ready is added. πŸ”΄ (16:14) CI-poller redispatch now supplies ATTEMPT from ${{ github.event_name == 'repository_dispatch' && steps.dispatch-attempt.outputs.value || '0' }}. πŸ”΄ (16:15) .github/workflows/publish.yml is being expanded from 318 to 528 lines to bind approval and CI-ready attestations into both the waiting-for-CI and publishing paths. πŸ”΄ (16:15) The waiting-for-ci job runs only when the event label is "accepted", the issue is open, and its title starts with "publish: "; it adds ci-pending, removes ci-failed when retrying, enables CI_POLLER_HAS_PENDING=true, comments on the issue, and triggers the poller immediately. πŸ”΄ (16:15) The waiting-for-ci job now checks out publish code with actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 and persist-credentials: false. πŸ”΄ (16:15) .github/workflows/publish.yml replaces unpinned actions/create-github-app-token@v3 with actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1. πŸ”΄ (16:15) The waiting-for-CI flow now binds a request snapshot, obtains a separate release-bot authentication token, records an approval attestation using APPROVAL_ACTOR: ${{ github.actor }}, and includes a continue-on-error: true attestation-related step. πŸ”΄ (16:15) When approval is invalid or cannot be verified, the workflow comments Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.. πŸ”΄ (16:15) The Enable cron poller step now has id: enable-poller, uses continue-on-error: true, runs under if: always() && steps.poller-token.outcome == 'success', and executes gh variable set CI_POLLER_HAS_PENDING -R "$GITHUB_REPOSITORY" -b "true". πŸ”΄ (16:15) User stated that the poller always adds ci-ready; the publish job fires only on ci-ready label events, not on accepted, to avoid racing with waiting-for-ci. πŸ”΄ (16:15) The publish job additionally requires the issue labels to contain "accepted", binds a fresh request snapshot, and sets REQUIRE_CI_READY_ATTESTATION: "true" before validating approval. πŸ”΄ (16:15) The publish flow runs node .__publish__/src/publish/validate-approval-attestation.js with APPROVAL_TOKEN: ${{ github.token }}; invalid validation exits with status 1 and has cleanup paths that remove labels including "accepted". πŸ”΄ (16:15) Target-repository checkout changes from actions/checkout@v7 to pinned actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1; it checks out getsentry/${{ fromJSON(steps.inputs.outputs.result).repo }} into __repo__ at ${{ steps.release-revision.outputs.revision }}, with fetch-depth: 0 and persist-credentials: false.