Dashboard › publish › Distillation
95845c1f-c282-47ac-aaa5-41f7b13c71c2["lore_tm_v1_y16nFXal-vmvNP77ZQ3qc7JFBE9W58awtr6YjNqlkKY","lore_tm_v1_jQBQXUcvf4bfYPAqxYYBp1xKuGPhyaUrVmwMYvk9Dlc","lore_tm_v1_U3U7BLtnHTEr5zG4ZETsXf6AtvQGA32i_dXswYknFNo","lore_tm_v1_M7eTM4jXbOhZ6aQIRalMzP7ZJCmMrB3gZiTLrEMKapc","lore_tm_v1_Kk2bQSHyiaobiZXUuM7NWZJ5mQ10wCBmMO5t_J5o8q8","lore_tm_v1_DJczhrWyLnyS9dL1SjXXoYrCk2YPBXZ5X8yZrSGSlGA","lore_tm_v1_wsVo7w62QiHLI6odsUBVNVTAvhTag0-3Vaf2D8_CaV8","lore_tm_v1_Bq8m1e7SGKpWMTbavAwDEM-BQF55ldRI9Q9VwL59yRg","lore_tm_v1_7MvyW3sDkDOHcMimVUChk-dCQ9efJSHc2pyWkYJ9ioY","lore_tm_v1_OSdS9bwsNHPZp0Fex6kN0PByldjdlf4bgKFv2XOwSoA","lore_tm_v1_3aEvW3dvJA5U3ODYcpur2JOKrDr4qHaCyA5Cxck0i8Y","lore_tm_v1_0fTdIREE0L_4Kc8vyIyNCSC_jJ7H1G9ir4SnQxic4AQ","lore_tm_v1_zMRPj8RKoTGMXG1Zt41045luNYiYBRZNgdvOlE8_bNw","lore_tm_v1_UIUFqMyFlLhHT0D5gWLQlEMKzlVxxmx9-c0V7gbHzIA"]
Date: Sep 10, 2026
/home/byk/Code/getsentry/publish/src/publish/__tests__/ci-poller-workflow.js has 56 lines and 3 tests: (1) trusted default-branch code must be checked out in Get publish code before Get auth token; (2) manual recovery must use a protected .github/workflows/ci-poller-dispatch.yml relay while .github/workflows/ci-poller.yml uses repository_dispatch, types: [ci-poller], and successful default-branch workflow_run, with no workflow_dispatch; (3) repository dispatch attempts must be validated before app-token creation.src/publish/__tests__/ci-poller-workflow.js:40-55 requires regex [[ "$ATTEMPT" =~ ^(0|[1-5][0-9])$ ]], fallback ATTEMPT: ${{ github.event_name == 'repository_dispatch' && steps.dispatch-attempt.outputs.value || '0' }}, increment attempt=$((10#$ATTEMPT + 1)), and retry dispatch through gh api --method POST "repos/$GITHUB_REPOSITORY/dispatches" --input -./home/byk/Code/getsentry/publish/src/publish/__tests__/publish-workflow.js has 22 lines and 2 tests: Revalidate approval attestation must occur after Set targets and immediately before Publish using Craft, with REQUIRE_CI_READY_ATTESTATION: "true"; Craft must be pinned as docker://getsentry/craft@sha256: followed by exactly 64 lowercase hexadecimal characters./home/byk/Code/getsentry/publish/src/publish/__tests__/auto-approval-workflow.js has 27 lines and 2 tests: node src/publish/record-auto-approval-attestation.js must execute before --add-label accepted; the proof-posting interval must use GH_TOKEN: ${{ github.token }}, while the later internal-app labeling path uses GH_TOKEN: ${{ steps.token.outputs.token }}./home/byk/Code/getsentry/publish/src/publish/__tests__/record-auto-approval-attestation.js has 54 lines and 2 tests for recordAutoApprovalAttestation(). A live request publish: getsentry/sentry-javascript@10.0.0, issue "123", repository getsentry/publish, body Merge target: main, open state, no labels, and author/auto-approver getsantry[bot] must produce an attestation parsed as { autoApprover: "getsantry[bot]", requestDigest: expect.any(String), title }.recordAutoApprovalAttestation() must reject when the live issue author changed from automated approver getsantry[bot] to contractor, throwing exactly The automated approval request changed before approval./home/byk/Code/getsentry/publish/src/publish/__tests__/record-ci-ready-attestation.js has 93 lines and 3 tests for recordCiReadyAttestation(): a current accepted-label event ID "100" by contractor, accepted issue, and authenticated actor sentry-internal-app[bot] must create an attestation parsed as { acceptedActor: "contractor", acceptedEventId: "100", ciReadyActor: "sentry-internal-app[bot]", requestDigest: expect.any(String), title }.recordCiReadyAttestation() must throw The approval changed before CI could be marked ready if the live title changes from publish: getsentry/sentry-javascript@10.0.0 to publish: getsentry/sentry-python@10.0.0, or if expected accepted event { actor: "contractor", eventId: "100" } has been replaced by event ID "200"./home/byk/Code/getsentry/publish/src/publish/__tests__/current-accepted-event.js has 38 lines and 2 tests for getCurrentAcceptedEvent(): from accepted-label events "100" then "200" by contractor, it returns the latest { actor: "contractor", eventId: "200" }; an empty event list must throw The issue has no current accepted label event./home/byk/Code/getsentry/publish/src/publish/__tests__/workflow-action-pinning.js has 76 lines. It dynamically enumerates every .github/workflows/*.yml file and requires all actions/* references to use exactly 40 lowercase hexadecimal characters.src/publish/__tests__/workflow-action-pinning.js defines SECRET_BEARING_JOBS: .github/workflows/auto-approve.yml → auto-approve; .github/workflows/ci-poller.yml → check-ci; .github/workflows/cocoapods-keepalive.yml → keepalive; .github/workflows/publish.yml → waiting-for-ci, publish. Every listed job must contain environment: production..github/workflows/ci-poller-dispatch.yml to omit workflow_dispatch:. The relay alone must contain workflow_dispatch:, permissions: {}, and environment: production, and must not contain secrets../home/byk/Code/getsentry/publish/src/libs/__tests__/github.js has 19 lines and 2 tests for getGitHubToken(): absent GITHUB_TOKEN throws No "GITHUB_TOKEN" environment variable found.; GITHUB_TOKEN="Example Token" returns exactly "Example Token"./home/byk/Code/getsentry/publish/src/modules/__tests__/details-from-context.js has 127 lines and 4 tests covering detailsFromContext() and parsePublishTitle().detailsFromContext() parses issue publish: getsentry/sentry@21.3.1 with Merge target: custom-branch and checked targets github, npm[@sentry/node], and docker[latest] into { dry_run: "", merge_target: "custom-branch", path: ".", repo: "sentry", targets: ["github", "npm[@sentry/node]", "docker[latest]"], version: "21.3.1" }.detailsFromContext() preserves + in version 4.2.6+sentry1. parsePublishTitle("publish: getsentry/sentry-javascript/packages/core@10.0.0") returns { path: "/packages/core", repo: "sentry-javascript", version: "10.0.0" }, while legacy title publish: sentry-javascript@10.0.0 returns the same repo/version with path: undefined.Merge target: (default), detailsFromContext() emits merge_target: ""; the tested result uses repo sentry, path ., version 21.3.1, and targets ["github", "docker[latest]"]. Missing issue context must throw Issue context is not defined./home/byk/Code/getsentry/publish/src/modules/__tests__/update-issue.js has 208 lines and tests updateIssue() with Craft state path ./__repo__/.craft-publish-21.3.1.json, issue "211", repository getsentry/publish, and workflow run ID "1234".updateIssue() reads published state { lol: true, hey: false, github: true }, updates the issue body to include - [x] github, - [ ] pypi, - [x] lol, and - [ ] hey; when the state file does not exist, it does not modify the issue body.updateIssue() removes the accepted label exactly once whether or not the Craft state file exists. It also removes accepted without parsed publish inputs while avoiding state-file checks and issue get/update calls.transformIssueBody() preserves surrounding release-request text while converting published states to ordered target lines: - [x] npm[@sentry/node], - [x] aws-lambda, - [ ] github, and newly appended - [x] foo./home/byk/Code/getsentry/publish/README.md documents the release flow in order: 1. developer triggers release workflow, 2. SDK repo runs craft prepare, 3. builds artifacts and creates release branch, 4. uploads artifacts to GitHub, 5. creates issue in getsentry/publish, 6. release manager reviews, 7. adding accepted triggers publish, 8. artifacts are downloaded, 9. craft publish publishes to registries, 10. success closes the issue and failure updates it.sentry-cli, SDKs, and symbolicator utilities, which require explicit approval, from internal dependencies such as arroyo, which may receive auto-approval because their later integration into Sentry requires another explicit approval.production environment, which permits only main deployments and disallows administrator bypass, protecting environment-scoped credentials from arbitrary workflow refs. It identifies SENTRY_INTERNAL_APP_PRIVATE_KEY and SENTRY_RELEASE_BOT_PRIVATE_KEY as organization-level secrets whose cross-repository exposure must be managed separately by Security./home/byk/Code/getsentry/publish/docs/key_rotation_vault_changes.md identifies 3 secret vaults: 1. SDKs/OSS, accessible to a range of employees including some who departed; 2. Shared, accessible to all engineers including some who departed; 3. Ops, accessible to operations, none of whom departed.docs/key_rotation_vault_changes.md considers 2 credential-management approaches: (1) Dedicated Service—a configured machine holds all publishing credentials and publishes after an authorized button press or automatically where permitted; (2) GitHub Actions in Separate Repo—centralize release actions and tokens in one restricted repository, minimize admins/write users, let others request approved releases through structured issues, and optionally create release-request issues automatically on release/* pushes.getsentry-bot) — OSS, 5. NPM Bot — SDKs, 6. Cocoapods — SDKs, 7. Nexus — SDKs, 8. Packagist — SDKs, 9. RubyGems — SDKs + Ops, 10. Code Signing Certificate — SDKs, 11. Bintray — SDKs, 12. Bot Apple ITC — Shared, 13. clojars.org → SDKs. The SDK Low Security vault is for the SDK Team and remaining items in the SDKs vault./home/byk/Code/getsentry/publish/docs/rfc.md defines 4 problems: 1. rapidly recycle NPM, PyPI, Cargo, Docker, and other publishing tokens without release/developer disruption; 2. restrict tokens to authorized personnel without leakage, noting ordinary GitHub secrets can be exfiltrated by repository writers; 3. require SDK release approval by a manager or senior engineer for SOC/ISO compliance; 4. eliminate divergent repeated per-project release/publish configuration.docs/rfc.md proposes this ordered flow: 1. central release/publish repository stores workflow and tokens; 2. only authorized personnel receive write/admin/triage access; 3. other engineers receive read access; 4. structured issue template requests releases; 5. each repository’s release action runs craft prepare and opens an issue containing repository name and version; 6. release-repository owners add accepted; 7. successful release closes the issue; 8. OSS CalVer releases are auto-approved unless blocked.docs/rfc.md notes structured issues are used because GitHub manual-workflow URLs cannot prefill inputs; issues store release information, reduce friction, and provide an audit trail.