Distillation

Date: Sep 3, 2026

• 🔴 (16:08) User stated that the CI poller always adds ci-ready after checking CI; waiting-for-ci first removes an existing ci-ready label so that the poller’s fresh add emits a labeled event and reliably triggers publishing.
• 🟡 (16:08) .github/workflows/publish.yml has an issue-title concurrency group ${{ github.event.issue.title }} with cancel-in-progress: false, so duplicate issues for the same repo@version share a group.
• 🟡 (16:08) .github/workflows/publish.yml waiting-for-ci job runs on ubuntu-latest in production only when an open issue receives accepted and its title starts with publish: . It creates a GitHub App token via actions/create-github-app-token@v3, removes ci-failed and ci-ready, adds ci-pending using gh issue edit, comments either "Retrying — CI was previously failed. Checking CI status now." or "Approved. Checking CI status on the release branch. Publishing will start automatically when CI passes.", best-effort enables CI_POLLER_HAS_PENDING=true using a dedicated poller app token, and immediately dispatches ci-poller.yml with the internal app token.
• 🟡 (16:08) .github/workflows/publish.yml publish job runs only for an open issue’s ci-ready label event when the issue has accepted and ci-ready, and lacks ci-pending and ci-failed; it has timeout-minutes: 90. This prevents an accepted-event race with waiting-for-ci and prevents publishing without CI verification.
• 🟡 (16:08) The publish job checks out the workflow repository into .__publish__, uses actions/setup-node@v6 with Node 24 and Yarn cache keyed by .__publish__/yarn.lock, runs yarn install --cwd ".__publish__", parses inputs with node .__publish__/src/publish/inputs.js, and resolves the CI-approved release revision through node .__publish__/src/publish/resolve-release-revision.js using PUBLISH_ARGS and PUBLISH_ISSUE_BODY.
• 🟡 (16:08) The publish job checks out getsentry/${{ fromJSON(steps.inputs.outputs.result).repo }} into __repo__ at ${{ steps.release-revision.outputs.revision }}, with fetch-depth: 0 and a Release Bot GitHub App token scoped to owner getsentry.
• 🟡 (16:08) In publish.yml, Resolve publish location initializes workspace_names='[]', computes requires_workspace_discovery using needsWorkspaceDiscovery(input), and only runs getsentry/craft:latest workspace list when discovery is required and __repo__/.craft.yml exists. The Docker command mounts $GITHUB_WORKSPACE/__repo__ at /github/workspace/__repo__ and uses that path as its working directory; CRAFT_WORKSPACE_NAMES is passed to node .__publish__/src/publish/resolve-location.js.
• 🟡 (16:08) Set targets runs only when fromJSON(steps.inputs.outputs.result).targets is truthy. It builds payload as {"published": {<target>: true, ...}} via jq, uses resolved path and optional workspace, and writes Craft publish state outside the target checkout at $GITHUB_WORKSPACE/.craft-state/craft.
• 🟡 (16:08) The state-file safety logic canonicalizes container_cwd with realpath -m "/github/workspace/__repo__/$CRAFT_PUBLISH_PATH" and rejects any path other than /github/workspace/__repo__ or its descendants with ::error::Publish path must remain inside the target checkout. It derives a 12-character SHA-1 cwd_hash, sanitizes owner/repo/version to lowercase [a-z0-9._-], and prefixes workspace state files with URL-safe base64 workspace-${workspace_encoded}-; resulting filename is publish-state-${owner_sanitised}-${repo_sanitised}-${cwd_hash}-${workspace_prefix}${version_sanitised}.json.
• 🟡 (16:08) The Craft publish container executes cd __repo__/${{ fromJSON(steps.location.outputs.result).path }} then craft publish <version> --rev <CI-approved revision>. It pins XDG_STATE_HOME=/github/workspace/.craft-state, passes resolved workspace through CRAFT_WORKSPACE, keeps CRAFT_PUBLISH_STATE_GITHUB_REPO bound to the issue checkout identity getsentry/<repo> rather than any workspace release-repository override, and invokes node .__publish__/src/publish/update-issue.js on cancellation or failure to update completed targets and remove the relevant label.
• 🟡 (16:08) src/modules/__tests__/details-from-context.js verifies ordinary title parsing for publish: getsentry/sentry@21.3.1: result { dry_run: "", merge_target: "custom-branch", path: ".", repo: "sentry", targets: ["github", "npm[@sentry/node]", "docker[latest]"], version: "21.3.1" }; verifies versions may contain +, e.g. 4.2.6+sentry1; and verifies Merge target: (default) becomes merge_target: "".
• 🟡 (16:08) details-from-context.js tests legacy human-readable workspace title syntax publish: getsentry/toolkit [workspace: "cli/v2"] @1.2.3, expecting repo: "toolkit", version: "1.2.3", and workspace: "cli/v2"; it rejects the same workspace suffix paired with toolkit/packages/cli using "A publish workspace must use the repository root path.".
• 🟡 (16:08) Workspace-title tests verify JSON-escaped workspace strings parse correctly, including cli [preview] \"next\" to cli [preview] "next" and Unicode cli-日本語; a title with an unexpected space before a version (publish: getsentry/toolkit @1.2.3) is rejected as Invalid publish issue title, and invalid JSON escape cli\qnext is rejected as Invalid publish workspace JSON in title.
• 🟡 (16:08) The displayed unsafe-workspace test cases cover empty workspace "", newline escape cli\nnext, NUL \u0000, tab escape cli\tnext, bidirectional-format character cli\u202enext, line separator cli\u2028next, and begins coverage for paragraph-separator workspace input in the continuation beyond line 300.