Dashboard › publish › Distillation
7efa79a3-a508-43af-8f14-875ddb3d2fff["lore_tm_v1_DUhtuL3hrqGtck_8b4zsQihiIJHBq1DW1-YLETlu5UE","lore_tm_v1_4OHul7fL-eFZiDQLpdDZMkX6vMc7SOc2WcLuYVH_dTs","lore_tm_v1_UgXEKytd8F08ON8nl8kjT6AilO4wp1_QDa7dTJONknY","lore_tm_v1_ovmuANfggmhknmxJtZiJs3H5HNrd74R53MyleDTGVOY","lore_tm_v1_E2NYsa9OsIlplc99AEgJdv_tTHzf5WKgIhV5O4MwsSQ","lore_tm_v1_-gvHgmi06Kr4QTS7LHz5_4YPbOEqWx8MhvybVwVO6no"]
validateApprovalAttestation() in src/publish/validate-approval-attestation.js concurrently fetches the issue, all event pages, and all comment pages using Promise.all([getIssue(...), getAllPages(... resource: "events"), getAllPages(... resource: "comments")]), then derives currentAcceptedEvent(events) and currentCiReadyEvent(events).validateApprovalAttestation() requires all of: the issue is open; issue.title === issueTitle; requestDigest(issue) === expectedRequestDigest; an accepted label exists; the current accepted event is non-null; any supplied expectedAcceptedEvent matches both actor and eventId; and hasApprovalAttestation({ attestationAuthor, comments, event, issue }) succeeds.validateApprovalAttestation() returns the base approved result immediately when approval fails or requireCiReadyAttestation is false. When it is true and base approval succeeds, validation additionally requires a non-null current CI-ready event, a ci-ready label, and successful hasCiReadyAttestation({ acceptedEvent: event, attestationAuthor, comments, ciReadyEvent, issue }).main() in src/publish/validate-approval-attestation.js requires environment variables APPROVAL_TOKEN, APPROVAL_ISSUE_NUMBER, APPROVAL_ISSUE_REPOSITORY, APPROVAL_ISSUE_TITLE, APPROVAL_ATTESTATION_AUTHOR, and EXPECTED_REQUEST_DIGEST; a missing value throws No "${name}" environment variable found.main() supplies expectedAcceptedEvent only when both EXPECTED_ACCEPTED_ACTOR and EXPECTED_ACCEPTED_EVENT_ID exist, and enables requireCiReadyAttestation only when REQUIRE_CI_READY_ATTESTATION === "true".The current accepted label has no matching approval attestation; direct execution catches errors, logs with console.error(error), and sets process.exitCode = 1.src/publish/validate-approval-attestation.js exports getAllPages, getGitHubResponse, getIssue, main, and validateApprovalAttestation.src/modules/__tests__/update-issue.js lines 46 and 82, src/modules/__tests__/publish-workflow.js lines 132 and 150, and .github/workflows/publish.yml lines 327, 357, 415, and 422..craft-state/craft/publish-state-getsentry-sentry-c232c383e26f-21.3.1.json; another workflow test expects .craft-state/craft/publish-state-getsentry-toolkit-c232c383e26f-workspace-cGFja2FnZXMvY2xp-1.2.3.json..github/workflows/publish.yml constructs the state path as "$state_dir/publish-state-${owner_sanitised}-${repo_sanitised}-${cwd_hash}-${workspace_prefix}${version_component}.json", sets XDG_STATE_HOME: /github/workspace/.craft-state, and sets CRAFT_PUBLISH_STATE_GITHUB_REPO: getsentry/${{ fromJSON(steps.inputs.outputs.result).repo }}.docs/rfc.md defines the Central Publish Repository proposal: centralize workflows and publishing tokens in a restricted repository; grant authorized personnel write/admin/triage and other engineers read access; use structured release-request issues containing repository name and version; trigger publishing by adding the accepted tag; and close successful requests with a success message.README.md is ordered: 1. developer triggers release workflow; 2. SDK repository runs craft prepare; 3. build artifacts and create release branch; 4. upload artifacts to GitHub; 5. create issue in getsentry/publish; 6. release manager reviews and adds accepted; 7. publish workflow downloads artifacts; 8. craft publish sends them to registries; 9. success closes the issue, while failure updates it.sentry-cli, SDKs, and symbolicator utilities, which require explicit approval, from internal dependencies such as arroyo, which may use auto-approval because their later dependency bump in Sentry proper requires separate approval. Automatic approvals are managed in .github/workflows/auto-approve.yml.production environment permits only main deployments and disallows administrator bypass; secret-bearing jobs use this environment to prevent arbitrary workflow refs from accessing environment-scoped credentials.README.md states that Sentry Release Bot short-lived tokens are created with actions/create-github-app-token using organization-level SENTRY_RELEASE_BOT_CLIENT_ID and SENTRY_RELEASE_BOT_PRIVATE_KEY; GITHUB_TOKEN is unsuitable because GitHub prevents it from triggering additional workflows.SENTRY_INTERNAL_APP_PRIVATE_KEY and SENTRY_RELEASE_BOT_PRIVATE_KEY are organization-level secrets whose availability to other repositories must be managed separately by Security because this repository cannot narrow that organization-wide boundary..craft.yml uses versioning.policy: calver, calver.format: "%y.%-m" (example 24.12 for December 2024), and optional calver.offset: 14.master or main; this can be overridden using the merge_target workflow input in Craft’s reusable workflow or composite action.docs/key_rotation_vault_changes.md considered two release 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 a restricted repository, grant only bare-minimum admin/write access, and let others initiate approved releases through structured issues.AGENTS.md identifies the project as a pure JavaScript Sentry Publish Repository using Node.js 24.0.0, CommonJS source modules, and GitHub Actions-based approval workflows around Craft.1.22.22 classic via Volta and directs agents not to use npm.yarn install; yarn test; yarn test:watch; yarn test src/modules/__tests__/update-issue.js; yarn test -t "pattern"; yarn lint; and yarn prettier. A file and test-name filter can be combined as yarn test src/modules/__tests__/update-issue.js -t "specific test name".src/libs/ for shared utilities, src/modules/ for reusable core business logic, and src/publish/ for GitHub Actions entry points; tests belong in __tests__/ subdirectories.UPPER_SNAKE_CASE constants and regexes, CommonJS (require/module.exports) in source files, ES modules in test files, double-quoted strings, semicolons, and Prettier default formatting; yarn prettier must run before committing.fs and path; 2. external packages such as @actions/github and @actions/core; 3. local relative modules."failure", "cancelled", and "success" and defaults to throw new Error(\Unknown status: '${status}'`)`.v4.0.0 with globals enabled and mocks auto-cleared between tests; external dependencies should be mocked before importing the module under test, and inline snapshots may be used for complex output.@actions/core for GitHub Actions inputs, outputs, and logging; @actions/github for the GitHub API client; and @sentry/node for Sentry error reporting.@getsentry/releng; long-term agent knowledge is stored in project-root .lore.md and managed through lore at https://github.com/BYK/loreai.