Distillation

Date: Aug 27, 2026

• 🟡 (16:03) Proposed Publish change b658ffa renames workflow display name in .github/workflows/cocoapods-keepalive.yml:1 from "CocoaPods Token Keep-Alive" to CocoaPods Token Keep-Alive.
• 🟡 (16:03) Proposed Publish change b658ffa adds id: craft-state to the Set targets bash step in .github/workflows/publish.yml, enabling later workflow steps to consume its state-file output.
• 🟡 (16:03) Proposed Publish change b658ffa passes CRAFT_WORKSPACE: ${{ fromJSON(steps.inputs.outputs.result).workspace || '' }} to the Craft Docker publish step in .github/workflows/publish.yml.
• 🟡 (16:03) Proposed Publish change b658ffa passes CRAFT_PUBLISH_STATE_GITHUB_REPO: getsentry/${{ fromJSON(steps.inputs.outputs.result).repo }} to the Craft Docker publish step; comment specifies state must follow the issue checkout identity rather than an optional workspace GitHub release-repository override.
• 🟡 (16:03) Proposed Publish change b658ffa passes CRAFT_STATE_FILE_PATH: ${{ steps.craft-state.outputs.state_file }} to the failure/cancellation node .__publish__/src/publish/update-issue.js step.
• 🟡 (16:03) Proposed Publish tests add title parsing coverage for escaped workspace characters; malformed workspace JSON must throw Invalid publish workspace JSON in title.
• 🟡 (16:03) Proposed Publish tests cover empty workspace title JSON (publish: getsentry/toolkit [workspace: ""] @1.2.3), NUL ("\\u0000"), Unicode bidi format control ("cli\\u202enext"), and paragraph separator ("cli\\u2029next").
• 🟡 (16:03) Proposed Publish workspace validation error text is Workspace names must be nonempty and cannot contain Unicode control, format, or separator characters; tests additionally cover tab and paragraph-separator workspace values.
• 🟡 (16:03) Proposed Publish tests set CRAFT_STATE_FILE_PATH to .craft-state/craft/publish-state-getsentry-sentry-c232c383e26f-21.3.1.json; updateIssue() reads this workflow-provided secure state-file path rather than deriving ./__repo__/.craft-publish-21.3.1.json.
• 🟡 (16:03) In proposed .github/workflows/publish.yml, the state-file step constructs publish state outside the checked-out repository via XDG_STATE_HOME; comments distinguish container CWDs /github/workspace/__repo__ and /github/workspace, hash container_cwd with sha1sum | cut -c1-12, and base64url-encode nonempty CRAFT_PUBLISH_WORKSPACE using base64 -w 0 | tr '+/' '-_' | tr -d '='.
• 🟡 (16:03) Proposed .github/workflows/publish.yml comments state the state location is outside __repo__/ so repository contents cannot pre-populate it.
• 🟡 (16:03) craft-workspace-action-propagation/.github/workflows/release.yml:4-18 retains workflow_dispatch and defines optional version (default 'auto'), optional force, and optional workspace inputs; workspace is described as Named Craft release workspace to prepare and publish.
• 🟡 (16:03) craft-workspace-action-propagation/.github/workflows/release.yml:20-65 defines workflow_call inputs including optional string workspace, version, force (default 'false'), merge_target, blocker_label (default 'release-blocker'), publish_repo, git_user_name, git_user_email, path (default '.'), and craft_config_from_merge_target (default 'false').
• 🟡 (16:03) craft-workspace-action-propagation/.github/workflows/release.yml:83-105 runs build only when github.repository == 'getsentry/craft'; release needs build and runs when it succeeded or was skipped, exposing version, branch, sha, previous_tag, and changelog from craft-local or craft-action.
• 🟡 (16:03) craft-workspace-action-propagation/.github/workflows/release.yml:107-132 creates a release-bot app token only for Craft’s own workflow_dispatch, checks out with that token or github.token, and dogfoods the local ./ action with workspace: ${{ github.event.inputs.workspace }}.
• 🟡 (16:03) craft-workspace-action-propagation/.github/workflows/release.yml:134-151 invokes getsentry/craft@v2 for external repositories and forwards workspace: ${{ inputs.workspace }} alongside version, force, merge target, blocker label, publish repo, Git identity, path, and merge-target-config options.
• 🔴 (16:03) User stated the CI poller always adds ci-ready.
• 🟡 (16:03) .github/workflows/ci-poller.yml comments describe adding ci-pending and removing ci-failed on retry; its waiting-for-ci job is gated on an open issue title starting with publish: , obtains GitHub App tokens, comments Approved. Checking CI status on the release branch. Publishing will start automatically when CI passes., and sets repository variable CI_POLLER_HAS_PENDING to "true" using gh variable set CI_POLLER_HAS_PENDING -R "$GITHUB_REPOSITORY" -b "true".
• 🟡 (16:03) .github/workflows/ci-poller.yml comments identify an event-ordering concern with waiting-for-ci; the poller adding ci-ready is intended to ensure the publish workflow fires.