Distillation

Date: Sep 9, 2026

• 🔴 (23:48) User-provided src/publish/__tests__/workflow-action-pinning.js enumerates every .github/workflows/*.yml file and verifies all actions/* references are pinned to lowercase 40-character commit SHAs.
• 🔴 (23:48) src/publish/__tests__/workflow-action-pinning.js verifies workflow_dispatch: is absent from every workflow except .github/workflows/ci-poller-dispatch.yml; the relay must contain workflow_dispatch:, permissions: {}, and environment: production, and must not contain secrets..
• 🔴 (23:48) src/publish/__tests__/workflow-action-pinning.js defines secret-bearing jobs that 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.
• 🔴 (23:49) src/publish/authorize-approval.js:44 sends X-GitHub-Api-Version: "2026-03-10", matching src/publish/validate-approval-attestation.js:13.
• 🔴 (23:50) GitHub Actions are pinned as follows: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 in .github/workflows/auto-approve.yml; actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 in .github/workflows/publish.yml, .github/workflows/test.yml, and .github/workflows/ci-poller.yml; actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 in .github/workflows/auto-approve.yml, .github/workflows/publish.yml, and .github/workflows/ci-poller.yml; actions/setup-node@249970729cb0ef3589644e2896645e5dc5ba9c38 in .github/workflows/publish.yml and .github/workflows/test.yml; and actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 in .github/workflows/test.yml.
• 🔴 (23:50) .github/workflows/publish.yml uses Craft image docker://getsentry/craft@sha256:9a4a5d5efa44a00c2215078ead39800d4aaa5a97908b94f45a64d7d506d6e14b.
• 🔴 (23:50) User-provided .github/workflows/cocoapods-keepalive.yml runs CocoaPods Token Keep-Alive daily at midnight UTC via cron "0 0 * * *" because CocoaPods sessions currently expire after 3 days of inactivity; job keepalive runs on macos-15 under environment: production, uses COCOAPODS_TRUNK_TOKEN: ${{ secrets.COCOAPODS_TRUNK_TOKEN }}, installs CocoaPods with gem install cocoapods, prints pod --version, and refreshes the session using pod trunk me > /dev/null 2>&1.
• 🔴 (23:50) User requires publish failure/cancellation cleanup to remain runnable after every stage: src/publish/update-issue.js must parse PUBLISH_ARGS only when present, catch malformed JSON and skip target restoration, and always call updateIssue() so the accepted label is removed even when release-input parsing fails.
• 🔴 (23:50) User requires the CI poller to always add the ci-ready label after CI passes, even if that label is already present; an idempotence check must not skip relabeling because re-adding emits a fresh label event that resolves the waiting-for-ci race and starts publishing, whereas skipping it can strand accepted releases.
• 🔴 (23:50) User requires workflow_dispatch wherever operators need manual recovery. For privileged recovery, user prefers a no-secret relay protected by a main-only environment plus a successful default-branch workflow_run handoff over direct secret-bearing dispatch, because the dispatcher selects workflow YAML before jobs, guards, or checkout execute; workflows should be identified by checked-in filenames such as ci-poller.yml, not placeholders or numeric IDs.
• 🔴 (23:50) User requires release authorization and attestations to be bound to the exact live request, trusted actor, and current label-event provenance. Automated approval requires request-bound proof from github-actions[bot] before sentry-internal-app[bot] adds accepted; generic app identity is insufficient.
• 🔴 (23:50) User requires a changed request or replaced accepted event never to reach ci-ready; the captured event and request digest must be validated before CI, after CI, while recording CI-ready proof, immediately before adding ci-ready, and before Craft. User chose repeated live fencing over one initial validation because issue state can change during CI or setup.
• 🔴 (23:50) User requires trusted-code boundaries for privileged GitHub Actions: workflows using secrets, write permissions, approvals, or release state must execute only trusted default-branch code; third-party actions must be pinned to immutable commit SHAs; secret-bearing jobs must use the protected production environment; repository secrets must never be exposed to workflows dispatchable from arbitrary refs; manual dispatch must use an unprivileged relay followed by successful default-branch execution; approval state must be revalidated immediately before transitions such as ci-ready; regression tests, the full test suite, and lint checks must run after changes.
• 🔴 (23:50) User requires trusted, state-bound release workflow transitions: before applying accepted, moving an issue to ci-ready, or publishing, validate the live canonical issue, current label events, actor provenance, and matching attestations; reject renamed, closed, changed, re-approved, self-approved, or unverifiable requests. The CI poller is solely responsible for adding ci-ready. Recovery must retain workflow_dispatch without running arbitrary dispatched-ref code or exposing repository secrets; use trusted checkout refs, protected environments, least-privilege permissions, immutable action/image revisions, and final revalidation immediately before credential-bearing publication.
• 🔴 (23:50) User requires fail-closed, request-bound release authorization with strict separation between human and automated flows: human approvers need live target-repository role write, maintain, or admin and cannot self-approve; automated bot requests must not use collaborator permissions or trust the Internal App label actor alone, and instead require the exact parsed repository/release path in auto-approve-repos.txt plus a trusted attestation bound to the live request. Missing, malformed, stale, mismatched, or changed state must be unauthorized.
• 🔴 (23:50) User stated an established git workflow preference: create a branch, open a PR, and obtain review; this behavioral pattern has been observed across 3 sessions.
• 🔴 (23:50) User-provided package.json identifies private package publish version 0.0.1, repository git@github.com:getsentry/publish.git, Apache-2.0 license, Volta Node 24.0.0 and Yarn 1.22.22, and resolution undici: ^6.23.0. Scripts are test: vitest run, test:watch: vitest, lint: eslint src .github --ignore-pattern '!.github', and prettier: prettier --write src; dependencies include @actions/core ^2.0.0, @actions/github ^7.0.0, and @sentry/node ^10.0.0, with vitest ^4.1.0.
• 🔴 (23:50) User-provided src/modules/details-from-context.js parses publish titles with PUBLISH_TITLE_REGEX = /^publish: (?:getsentry\/)?(?<repo>[^/@]+)(?<path>\/[\w./-]+)?@(?<version>[\w.+-]+)$/; detailsFromContext() rejects missing issue context or invalid titles, emits dry_run: "1" only for a dry-run label, prefixes parsed paths with ., parses Merge target: ..., and extracts checked targets from the issue body.
• 🔴 (23:51) User-provided src/modules/update-issue.js has updateIssue() concurrently restore target state only when inputs?.version exists and remove label accepted unconditionally. updateTargets() reads ${process.env.GITHUB_WORKSPACE}/__repo__/.craft-publish-${version}.json only if it exists, transforms the live issue body from craftState.published, preserves declared target ordering/state, appends unlisted targets, and updates the issue body.
• 🔴 (23:51) User-provided src/publish/update-issue.js conditionally parses process.env.PUBLISH_ARGS; malformed JSON logs Could not parse publish inputs; skipping target update, after which main() still calls updateIssue({ context, octokit, inputs }). Direct-execution errors are logged and set process.exitCode = 1.
• 🔴 (23:51) User-provided src/modules/__tests__/update-issue.js verifies the Craft state path ./__repo__/.craft-publish-21.3.1.json, restoration of target states including - [x] github, - [ ] pypi, appended - [x] lol, and - [ ] hey, no issue-body update when the state file is absent, and unconditional removal of accepted from issue "211".
• 🔴 (23:51) src/modules/__tests__/update-issue.js specifically verifies that updateIssue() with inputs: undefined performs no state-file lookup, issue retrieval, or issue-body update, but still calls removeLabel({ owner: "getsentry", repo: "publish", issue_number: "211", name: "accepted" }).
• 🔴 (23:51) User-provided src/modules/process-end-state.js posts a workflow-result issue comment, closes the issue only on status === "success", and reports a Sentry session. Status mappings are: failure → message Release failed: ${repo}, severity error, session crashed; cancelled → Release cancelled: ${repo}, severity warn, session crashed; success → Release succeeded: ${repo}, severity info, session ok; unknown statuses throw Unknown status: '${status}'.