Dashboard › craft › Distillation
2ed9bc5c-bc69-4e20-81a1-4e0fbf65f5c3["lore_tm_v1_7xgA0IeP3OJ4rBegV8qFrlxi7L87MoIiAQ2ZM3C6uqw"]
Date: Aug 25, 2026
docs/rfc.md frames whether release-repository owners may self-approve versus requiring a second approver as an unresolved design question; it also says GitHub manual-workflow URLs cannot prefill input values, so structured issues store release information, reduce friction, and create an audit paper trail.docs/key_rotation_vault_changes.md states employees should not publish through personal accounts or access global credentials; Craft release preparation no longer requires credentials, while publishing must run somewhere tokens cannot be accessed directly but approved engineers can click publish. Approval requirements vary by project: SDKs require a manager, while some codebases such as getsentry/sentry may use automatic publishing.docs/key_rotation_vault_changes.md proposes structured issues and issue-based workflow triggers so users with read access can create release issues, with repo-admin approval for releases; it also proposes automatically creating release-request issues when a release/* branch is pushed.README.md describes the release flow: developer triggers release workflow; SDK repository runs craft prepare; a publish issue is created in getsentry/publish; adding the accepted label triggers publishing; craft publish publishes to registries; the issue automatically closes on successful publishing. The README instructs users to add accepted, potentially requesting a team lead or manager because elevated permissions are required, then observe the issue for triggered-run information.README.md states publishing uses Craft and tokens from the Sentry Release Bot GitHub App. create-github-app-token generates short-lived action-run tokens using organization-level SENTRY_RELEASE_BOT_CLIENT_ID and SENTRY_RELEASE_BOT_PRIVATE_KEY; GITHUB_TOKEN cannot be used because GitHub prevents it from triggering further workflows.AGENTS.md identifies this as the Sentry Publish Repository: a GitHub Actions approval system for cross-project release publishing using Craft; it is a CommonJS JavaScript project on Node.js 24.0.0. It documents yarn test src/modules/__tests__/update-issue.js, targeted test syntax yarn test src/modules/__tests__/update-issue.js -t "specific test name", kebab-case files such as details-from-context.js and update-issue.js, and issue workflows triggered by labels/comments.src/modules/update-issue.js defines updateTargets({octokit, version, publishRepo, issue_number}), reads Craft state from ${process.env.GITHUB_WORKSPACE}/__repo__/.craft-publish-${version}.json, fetches the issue through octokit.rest.issues.get, transforms the issue body with transformIssueBody(craftState, issue.body), updates it through octokit.rest.issues.update, marks listed and unlisted targets from craftState.published as checked/unchecked, and removes a label via octokit.rest.issues.removeLabel.src/modules/process-end-state.js obtains issue_number from context.payload.issue, closes issues with octokit.rest.issues.update({ state: "closed" }), and posts comments with octokit.rest.issues.createComment.src/modules/details-from-context.js parses a publish issue’s title, dry-run label, merge target, and Targets section; it guards against absent context.payload.issue..github/workflows/publish.yml triggers on labeled issues and uses the issue title as its concurrency group so duplicate issues for the same repository/version share a group. Its publishing condition requires label accepted, an open issue, and title prefix publish: . On acceptance it resets CI labels by removing ci-failed and ci-ready and adding ci-pending; it comments based on whether ci-failed was present. The workflow uses an app token because GITHUB_TOKEN workflow_dispatch events are suppressed, and its CI gate fires only on ci-ready label events rather than accepted to avoid a race.