Distillation

Date: Sep 10, 2026

• 🔴 (16:11) User provided /home/byk/Code/getsentry/publish/src/publish/__tests__/publish-workflow.js; it requires node src/publish/request-digest-from-event.js and exactly 4 occurrences of EXPECTED_REQUEST_DIGEST: ${{ steps.request-digest.outputs.request_digest }} to bind approval/publication to the triggering issue snapshot.
• 🔴 (16:11) Publish workflow tests require Revalidate approval attestation after Set targets and immediately before Publish using Craft, with REQUIRE_CI_READY_ATTESTATION: "true".
• 🔴 (16:11) Publish workflow tests make Inform start informational rather than a publication gate: it precedes Get Release Bot auth token, and the intervening section contains continue-on-error: true.
• 🔴 (16:11) Publish workflow CI-poller activation order is Mark ci-pending → Trigger CI poller → Comment on issue → Enable cron poller → Revoke stranded approval; trigger, comment, and enable operations use continue-on-error: true. If both steps.trigger-poller.outcome != 'success' and steps.enable-poller.outcome != 'success', the stranded-approval guard removes both "ci-pending" and "accepted".
• 🔴 (16:11) Publish workflow reconciliation occurs after Publish using Craft and again after the single Report publish result step. Both reconciliation sections use if: always(), derive behavior from ${{ steps.publish.outcome }}, remove "accepted", "ci-pending", and "ci-ready", close the issue with --state closed, and contain no node invocation.
• 🔴 (16:11) Publish workflow tests require exactly 1 Report publish result step. It always runs, maps Craft outcomes through case "${{ steps.publish.outcome }}" in: success) status=success ;;, cancelled) status=cancelled ;;, and *) status=failure ;;, then invokes node .__publish__/src/publish/post-result.js "$status" without using cancelled().
• 🔴 (16:12) User provided /home/byk/Code/getsentry/publish/src/publish/__tests__/post-result.js; post-result.js main() must still call report with { inputs: {}, status: "failure" } when PUBLISH_ARGS is either absent or "not-json".
• 🔴 (16:12) User provided /home/byk/Code/getsentry/publish/src/publish/__tests__/discover-location.js; if the root configuration is absent, discoverLocation({ input: { path: "./packages/cli" }, repositoryDirectory: "__repo__", exists: () => false }) preserves checkout-path behavior and returns { path: "./packages/cli" }.
• 🔴 (16:12) discoverLocation() must preserve exact workspace casing: for input path "./packages/CLI" and Craft workspace output ["packages/CLI"], it returns { path: ".", workspace: "packages/CLI" }. Workspace discovery invokes docker with image getsentry/craft@sha256:9a4a5d5efa44a00c2215078ead39800d4aaa5a97908b94f45a64d7d506d6e14b and arguments containing workspace and list.
• 🔴 (16:12) getWorkspaceNames() fails closed with "Craft workspace discovery returned an invalid workspace list." when Craft outputs either "{}" or only "\n".
• 🔴 (16:12) User provided /home/byk/Code/getsentry/publish/src/publish/__tests__/resolve-release-revision.js; running resolve-release-revision.js with PUBLISH_ARGS: "" and PUBLISH_ISSUE_BODY: "" must exit nonzero with "Publish input must define a repository.", not "Unexpected end of JSON input".
• 🔴 (16:13) User provided /home/byk/Code/getsentry/publish/src/publish/__tests__/workflow-action-pinning.js; every actions/...@revision reference across .github/workflows/*.yml must use a lowercase 40-character hexadecimal SHA.
• 🔴 (16:13) Workflow-dispatch policy tests prohibit workflow_dispatch: in every workflow except .github/workflows/ci-poller-dispatch.yml. Secret-bearing jobs must use environment: production: .github/workflows/auto-approve.yml job auto-approve; .github/workflows/ci-poller.yml job check-ci; .github/workflows/cocoapods-keepalive.yml job keepalive; and .github/workflows/publish.yml jobs waiting-for-ci and publish.
• 🔴 (16:13) The sole protected dispatch relay, .github/workflows/ci-poller-dispatch.yml, must contain workflow_dispatch:, permissions: {}, and environment: production, and must not contain secrets..
• 🔴 (16:13) User provided /home/byk/Code/getsentry/publish/README.md; the documented release flow is: developer triggers release workflow → SDK repository runs craft prepare → builds artifacts and creates a release branch → uploads artifacts to GitHub → creates an issue in getsentry/publish → Release Manager Review → adding "accepted" triggers publish → artifacts are downloaded → craft publish publishes to registries → success closes the issue, while failure updates it.
• 🔴 (16:13) The repository’s documented goals are: 1. employees do not publish through personal accounts, 2. employees cannot access global credentials, 3. releases are not built or published from employee machines, 4. releases require formal approval from a limited set of release managers, and 5. these controls should not discourage any engineer from initiating a release.
• 🔴 (16:13) README approval policy distinguishes publicly installed packages such as sentry-cli, SDKs, and symbolicator utilities, which require explicit approval, from internal dependencies such as arroyo, which may receive automatic approval because the dependency bump is explicitly approved again in Sentry proper. Automatic approvals are managed in .github/workflows/auto-approve.yml.
• 🔴 (16:13) README security design states that the repository is read-only except for release managers; secret-bearing jobs use protected production, permitting only main deployments and disallowing administrator bypass. SENTRY_INTERNAL_APP_PRIVATE_KEY and SENTRY_RELEASE_BOT_PRIVATE_KEY are organization-level secrets whose cross-repository availability must be managed by Security.
• 🔴 (16:13) README CalVer example for .craft.yml uses versioning.policy: calver, calver.format: "%y.%-m" (for example, 24.12 for December 2024), and optional calver.offset: 14.
• 🔴 (16:13) README states releases default to the repository’s default branch, usually master or main; this can be overridden with the merge_target input in Craft’s reusable workflow or composite action.
• 🔴 (16:13) User stated releases should always require approval by a second person, like a code review.
• 🔴 (16:13) User provided /home/byk/Code/getsentry/publish/docs/rfc.md; the RFC’s proposed central-publish design is: 1. centralize release workflow and publishing tokens, 2. grant write/admin/triage only to authorized personnel, 3. give other engineers read access, 4. use a structured release-request issue, 5. run craft prepare in each source repository and open a release issue containing repository name and version, 6. have release-repository owners add "accepted" to trigger publication, 7. close the issue with a success message, and 8. automatically approve OSS CalVer releases unless blocked.
• 🟡 (16:13) The RFC records open design questions: 1. whether release-repository owners may directly run publication, 2. whether owners must still create an issue and obtain second-person approval, 3. how much friction the process creates, 4. whether approval authority should vary by release and how, and 5. whether exposing all tokens to all authorized personnel is acceptable.
• 🔴 (16:14) User provided /home/byk/Code/getsentry/publish/docs/key_rotation_vault_changes.md; it compares 2 credential-management approaches: 1. Dedicated Service—a configured machine holds all publishing credentials and publishes on authorized button press or automatically when permitted; 2. GitHub Actions in Separate Repo—centralize release actions in a restricted repository, minimize admins/write users, expose credentials only there, and use structured issues plus issue-triggered workflows so everyone else can retain read access.
• 🔴 (16:14) docs/key_rotation_vault_changes.md states SDKs must not be published without a manager, while some codebases, including sentry, may allow automatic publication.
• 🔴 (16:14) User provided /home/byk/Code/getsentry/publish/auto-approve-repos.txt, containing exactly 46 auto-approved release paths 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) User provided /home/byk/Code/getsentry/publish/src/modules/publish-issue-validation.js; isPublishRepository(name) permits only /^[A-Za-z0-9_.-]+$/ and rejects ".", "..", "__proto__", and names starting with "-". isReleaseVersion(version) validates three numeric version components plus optional prerelease and build metadata, case-insensitively.
• 🔴 (16:14) User provided generated parser /home/byk/Code/getsentry/publish/src/modules/publish-issue-title.js, generated by Peggy 5.1.0; its allowed start rules include PublishIssueTitle, ReleaseRevision, and CheckRunsLinkCount, and its title grammar begins with "publish: getsentry/", supports optional repository subpaths, then "@" and a release version.
• 🔴 (16:14) User provided /home/byk/Code/getsentry/publish/scripts/generate-publish-issue-title-parser.js; it reads src/modules/publish-issue-title.peggy, generates CommonJS parser source into src/modules/publish-issue-title.js with grammar source publish-issue-title.peggy, formats it using Prettier, and synchronizes the generated title-grammar block in docs/publish-issue-format.md.
• 🔴 (16:14) scripts/generate-publish-issue-title-parser.js --check fails with "The generated publish issue title parser is stale. Run \yarn generate`."if parser output differs, and"The generated publish issue title documentation is stale. Run `yarn generate`."if documentation differs. Without--check`, it writes both generated files.
• 🔴 (16:14) generateDocumentation() requires exactly 1 BEGIN GENERATED TITLE GRAMMAR marker and exactly 1 END GENERATED TITLE GRAMMAR marker; missing, duplicate, or malformed markers throw "Could not find the generated title grammar in the documentation.".