Distillation

["lore_tm_v1_MF7gyUvP3axj_XLxGHg-mxEmtbhy-2cQ8QxrCBcoBzM","lore_tm_v1_mw7oJBiRC_oMg5q9DqaAy3cd3vliw-meW6IzIiTDOpA","lore_tm_v1_OSFSuqVCt-rMVjLz7IZxpVRII_APBjg1e2kGagLnLTo","lore_tm_v1_CB5IyyQ1Al2E5PHwrVU0rzx47BUG8ZtfNwtiXAQv_IU","lore_tm_v1_kQYi4wiyaWZonl3P41OafOczgXIFGBMi5J4Cig1AfZE","lore_tm_v1_ssGwmAoQlzXwYlmDkGZugahMffAQMpWyxVs2viYid4E","lore_tm_v1_ReGEkOGVLRNOrrBtY6mdZLfVLgFNhcSKNPK9e4Ga_F4","lore_tm_v1__MGYo-18eVLc9BC3j2h0fy420KoiEFkXywm1ler7GZQ","lore_tm_v1_mbV3m8GoHWbyky0pbAd3pbe8wyavHSsf63h1Nseyc-U","lore_tm_v1_7wqv0wDdDgPXLh0r4oViAL-SEmJdLI8RJWjr473hkqU"]

🔴 (01:07) User-provided /home/byk/Code/getsentry/publish/src/publish/post-workflow-details.js is 8 lines; it imports postWorkflowDetails from ../modules/post-workflow-details.js, imports getGitHubToken from ../libs/github, creates context = github.context and octokit = github.getOctokit(getGitHubToken()), then invokes postWorkflowDetails({ context, octokit }) without awaiting or attaching an error handler.

🔴 (01:07) User-provided search found 53 issue-comment-related matches: module API calls in src/modules/process-end-state.js line 42 and src/modules/post-workflow-details.js line 12; associated mocks/assertions in src/modules/__tests__/process-end-state.js and src/modules/__tests__/post-workflow-details.js; gh issue comment calls in .github/workflows/publish.yml, .github/workflows/ci-poller.yml, and .github/workflows/auto-approve.yml.

🔴 (01:07) User-provided src/modules/__tests__/details-from-context.js verifies detailsFromContext(...) parses issue publish: getsentry/sentry@21.3.1 into { dry_run: "", merge_target: "custom-branch", path: ".", repo: "sentry", targets: ["github", "npm[@sentry/node]", "docker[latest]"], version: "21.3.1" }.

🔴 (01:07) User-provided src/modules/__tests__/details-from-context.js verifies version 4.2.6+sentry1 is preserved from title publish: getsentry/sentry-forked-django-stubs@4.2.6+sentry1.

🔴 (01:07) User-provided src/modules/__tests__/details-from-context.js verifies parsePublishTitle(...) supports qualified title publish: getsentry/sentry-javascript/packages/core@10.0.0, producing { path: "/packages/core", repo: "sentry-javascript", version: "10.0.0" }, and legacy title publish: sentry-javascript@10.0.0, producing { path: undefined, repo: "sentry-javascript", version: "10.0.0" }.

🔴 (01:07) User-provided src/modules/__tests__/details-from-context.js verifies Merge target: (default) becomes merge_target: "", with parsed result { dry_run: "", merge_target: "", path: ".", repo: "sentry", targets: ["github", "docker[latest]"], version: "21.3.1" }.

🔴 (01:07) User-provided src/modules/__tests__/details-from-context.js verifies missing issue context rejects with Issue context is not defined.

🔴 (01:07) User-provided src/modules/__tests__/update-issue.js sets process.env.GITHUB_WORKSPACE = ".", mocks state JSON as {"published":{"lol":true,"hey":false,"github":true}}, and tests both absent and present ./__repo__/.craft-publish-21.3.1.json states.

🔴 (01:07) User-provided src/modules/__tests__/update-issue.js verifies that when the Craft state file exists, issue 211 in getsentry/publish is fetched and updated so the body contains - [x] github, - [ ] pypi, - [x] lol, and - [ ] hey; when the state file is absent, the issue body is not updated.

🔴 (01:07) User-provided src/modules/__tests__/update-issue.js verifies updateIssue(...) removes label accepted from issue 211 in getsentry/publish whether or not parsed publish inputs exist; with inputs: undefined, it does not check the state file, fetch the issue, or update its body.

🔴 (01:07) User-provided transformIssueBody test verifies existing targets retain issue-body order while their checks are replaced from Craft state, and newly published target foo is appended: npm[@sentry/node] checked, aws-lambda checked, github unchecked, then foo checked.

🔴 (01:07) User-provided /home/byk/Code/getsentry/publish/src/libs/github.js defines getGitHubToken(): it returns process.env.GITHUB_TOKEN when present and otherwise throws 'No "GITHUB_TOKEN" environment variable found. Please ensure the workflow is configured correctly'; the function is exported via module.exports = { getGitHubToken }.

🔴 (01:07) User-provided src/libs/__tests__/github.js verifies getGitHubToken() throws when GITHUB_TOKEN is absent and returns exact value "Example Token" when defined.

🔴 (01:07) User stated releases must always require approval from a second person, analogous to code review.

🔴 (01:07) User-provided README.md defines the release flow in order: 1. developer triggers release workflow, 2. SDK repository runs craft prepare, 3. artifacts are built and a release branch created, 4. artifacts are uploaded to GitHub, 5. an issue is created in getsentry/publish, 6. a release manager reviews it, 7. adding the accepted label triggers publishing, 8. artifacts are downloaded from GitHub, 9. craft publish publishes to registries, 10. success closes the issue and failure updates it.

🔴 (01:07) User-provided README.md lists repository goals in exact order: 1. employees must not publish through personal accounts, 2. employees must not access global credentials, 3. employees must not build and publish releases from their machines, 4. releases require formal approval from a limited set of release managers, 5. these controls should not discourage any engineer from initiating a release.

🔴 (01:07) User-provided README.md documents CalVer configuration in .craft.yml: versioning.policy: calver, calver.format: "%y.%-m" (for example 24.12 for December 2024), and optional calver.offset: 14.

🔴 (01:07) User-provided README.md states releases merge to the repository’s default branch (master or main) unless the release workflow passes merge_target; Craft’s reusable workflow example uses getsentry/craft/.github/workflows/release.yml@v2 with version, merge_target, and secrets: inherit.

🔴 (01:07) User-provided approval policy distinguishes public customer-installed packages such as sentry-cli, SDKs, and distributed symbolicator utilities, which require explicit approval, from internal dependencies such as arroyo, which may receive automatic approval because dependency bumps require another approval in Sentry; automatic approvals are managed in .github/workflows/auto-approve.yml.

🔴 (01:07) User-provided README.md states secret-bearing jobs use the protected production environment, which permits only main deployments and disallows administrator bypass; SENTRY_INTERNAL_APP_PRIVATE_KEY and SENTRY_RELEASE_BOT_PRIVATE_KEY are organization-level secrets whose organization-wide access boundary must be managed separately by Security.

🔴 (01:07) User-provided docs/rfc.md identifies four central-publish requirements in order: 1. rapidly recycle NPM, PyPI, Cargo, Docker, and other publishing tokens without disrupting releases/developer flow, 2. restrict publishing tokens to authorized personnel and prevent leakage, 3. require manager or senior-engineer approval for SDK releases under SOC/ISO policy, 4. eliminate divergent per-project release/publish configurations.

🔴 (01:07) User-provided docs/rfc.md proposes: 1. a central release/publish repository containing workflows and tokens, 2. write/admin/triage access only for authorized personnel, 3. read access for other engineers, 4. structured release-request issues, 5. per-repository release actions that run craft prepare and open an issue containing repository name and release version, 6. an owner adds an accepted tag to trigger release, 7. successful release closes the issue, 8. OSS CalVer releases are automatically approved unless blocked.

🔴 (01:07) User-provided docs/key_rotation_vault_changes.md describes three existing secret vaults: SDKs/OSS available to a range of employees including departed employees, Shared available to all engineers including departed employees, and Ops available to operations with no departed employees retaining access.

🔴 (01:08) User-provided AGENTS.md identifies the project as the Sentry Publish Repository, a GitHub Actions-based approval system using Craft; it is pure JavaScript on Node.js 24.0.0 and uses CommonJS source modules.

🔴 (01:08) User requires Yarn 1.22.22 classic, managed through Volta, and explicitly prohibits npm.

🔴 (01:08) User-provided repository commands are: install with yarn install; all tests with yarn test; watch mode with yarn test:watch; one file with yarn test src/modules/__tests__/update-issue.js; name pattern with yarn test -t "pattern"; combined file and test name with yarn test src/modules/__tests__/update-issue.js -t "specific test name"; lint with yarn lint; format with yarn prettier.

🔴 (01:08) User-provided project structure assigns shared utilities to src/libs/, reusable core business logic to src/modules/, and GitHub Actions entry points to src/publish/; tests belong in __tests__/ subdirectories matching source filenames.

🔴 (01:08) User requires kebab-case filenames, camelCase variables/functions, UPPER_SNAKE_CASE constants and regexes, CommonJS (require/module.exports) for source files, and ES modules (import/export) for test files.

🔴 (01:08) User requires import ordering: 1. Node.js built-ins such as fs and path, 2. external packages such as @actions/github and @actions/core, 3. relative local modules.

🔴 (01:08) User requires Prettier default formatting, double-quoted strings, semicolons, and running yarn prettier before committing.

🔴 (01:08) User requires descriptive errors with remediation context, early input validation through guard clauses, file-existence checks before reads, and always throwing for unexpected values in switch statements; the prescribed default form is throw new Error(\Unknown status: '${status}'`)`.

🔴 (01:08) User-provided testing standard is Vitest v4.0.0 with globals enabled and mocks automatically cleared between tests; external dependencies should be mocked before requiring the module under test, and inline snapshots may be used for complex output.

🔴 (01:08) User-provided key dependencies are @actions/core for GitHub Actions inputs/outputs/logging, @actions/github for the Actions GitHub API client, and @sentry/node for Sentry error reporting.

🔴 (01:08) User-provided common implementation patterns include Promise.all([operation1(), operation2()]) for parallel async execution, destructuring, spread-based object merging, template literals, and regular expressions with named groups.

🔴 (01:08) User stated all repository code is owned by @getsentry/releng; long-term repository knowledge maintained by lore is stored in .lore.md.