ci: run backports through release workflow

[mattrothenberg]

Summary

Moves the manual backport release path into the existing Release workflow and removes the separate Backport Release workflow.

The first backport attempt reached npm publish but failed with an npm auth/trusted-publishing error. Publishing from the existing Release workflow should use the workflow already configured for npm trusted publishing.

The manual dispatch remains guarded by:

• backport_ref must match release/kumo-*
• expected_version must match the version produced by pnpm run version
• publish uses changeset publish --tag backport so npm latest remains on 2.4.x

Planned dispatch after merge:

• workflow: Release
• backport_ref: release/kumo-2.3.1-react18-context
• expected_version: 2.3.1

Notes

The previous Backport Release workflow failed before publishing. npm still has latest=2.4.0 and no @cloudflare/kumo@2.3.1.

Testing

• Inspected failed run logs: publish failed with npm E404 permission/trusted-publishing error

• Verified npm dist-tags: latest remains 2.4.0

• Verified @cloudflare/kumo@2.3.1 is not published

• Reviews

• bonk has reviewed the change

• automated review not possible because: temporary CI wiring for urgent trusted-publishing backport

• Tests

• Tests included/updated

• Automated tests not possible - manual testing has been completed as follows: inspected workflow and failed publish logs; guarded dispatch path only

• Additional testing not necessary because: no package source changes

[mattrothenberg]

/bonk review for correctness and security

[pkg-pr-new]

npm i https://pkg.pr.new/@cloudflare/kumo@557

commit: 42a44fd

[ask-bonk]

Correctness

• Moving the backport path into the existing Release workflow is the right fix for the npm trusted publishing failure. npm's trusted publishing configuration is tied to the workflow file path, so dispatches from .github/workflows/release.yml will use the already-configured trust relationship.
• The event filters (github.event_name == 'push' for release, workflow_dispatch for backport-release) correctly isolate the two jobs so a manual dispatch doesn't accidentally trigger both.
• The release/kumo-* prefix guard and the expected_version verification against packages/kumo/package.json are preserved, providing the same safety rails as the old standalone workflow.
• Publishing with --tag backport is correctly preserved; latest will remain unaffected.

Security

• The backport-release job uses minimal required permissions (id-token: write, contents: write) and omits pull-requests: write, which is good least-privilege hygiene.
• NPM_CONFIG_PROVENANCE: true is preserved for supply-chain provenance.

Minor notes (non-blocking)

• The shared concurrency: group: ${{ github.workflow }} now serializes regular releases and backports. In the old setup, backports used their own concurrency group (backport-release-${{ inputs.expected_version }}). This means a long-running backport could temporarily block a main release, and vice versa. Given the urgency and low frequency of backports, this is acceptable, but worth noting.
• git push origin HEAD:${{ inputs.backport_ref }} does not quote the input expansion. While the case prefix check mitigates obvious abuse, and triggering the workflow requires repo write access anyway, quoting the ref (git push origin "HEAD:${{ inputs.backport_ref }}") would be a small defensive improvement. Same for the echo in the verify step. This is pre-existing from the deleted workflow.

Overall, this looks correct and safe to merge for the stated backport fix.

[ask-bonk]

Review posted to PR #557 — approved with notes.

Summary of findings:

• Correctness: The change is the right fix. npm trusted publishing maps to the workflow file path, so moving the backport job into .github/workflows/release.yml should resolve the E404 auth failure. Event filters correctly isolate the two jobs (push vs. dispatch), and all existing guards (release/kumo-* prefix, expected_version check, --tag backport) are preserved.
• Security: Permissions are appropriately minimal for the backport job (id-token: write, contents: write, no pull-requests: write). Provenance remains enabled.

Minor, non-blocking notes flagged:

1. Concurrency: The two jobs now share one concurrency group (${{ github.workflow }}), so a backport and a main release will serialize. Previously, backports had their own group. This is acceptable for rare backports but worth being aware of.
2. Shell quoting: git push origin HEAD:${{ inputs.backport_ref }} should ideally quote the expansion (e.g., "HEAD:${{ inputs.backport_ref }}"). This is pre-existing from the deleted workflow and low-risk since write access is required to trigger it.

github run

[github-actions]

Docs Preview

View docs preview

Commit: c99c0f5