ci: add temporary backport release workflow

[mattrothenberg]

Summary

Adds a temporary manual workflow for publishing a one-off @cloudflare/kumo backport release from a release/kumo-* branch.

This is needed to publish @cloudflare/kumo@2.3.1 from the @cloudflare/kumo@2.3.0 tag while main has already moved to 2.4.x.

The workflow requires explicit inputs:

• ref: backport release branch, guarded to release/kumo-*
• expected_version: expected package version after changeset version, used as a hard guard before publishing

Planned dispatch after merge:

• ref: release/kumo-2.3.1-react18-context
• expected_version: 2.3.1

After the backport release is published, this workflow should be removed.

Already prepared

The backport branch has been pushed: release/kumo-2.3.1-react18-context

It contains only:

• Combobox Context.Provider fix
• Autocomplete Context.Provider fix
• patch changeset for @cloudflare/kumo

Testing

Backport branch verification:

• pnpm --filter @cloudflare/kumo typecheck

• pnpm --filter @cloudflare/kumo test

• Reviews

• bonk has reviewed the change

• automated review not possible because: temporary release workflow for urgent backport, reviewed manually against existing release script behavior

• Tests

• Tests included/updated

• Automated tests not possible - manual testing has been completed as follows: backport branch typecheck and package tests passed

• Additional testing not necessary because: workflow wiring is isolated and guarded by explicit version/ref checks

[mattrothenberg]

/bonk can you check our thinking here? the goal is to be able to do an ad-hoc release of 2.3.1

[ask-bonk]

This is a solid temporary workflow. The guard rails (ref prefix check + hard version assertion) are exactly what you want for a one-off backport. Here is my review for PR #556:

---

🟡 Concern — latest dist-tag on npm

If @cloudflare/kumo@2.4.x has already been published to npm, running changeset publish here will overwrite the latest dist-tag with 2.3.1. Consumers running npm install @cloudflare/kumo would unexpectedly get the backport instead of 2.4.x.

Options:

1. Confirm that 2.4.x is not on npm yet — if true, no issue.
2. If 2.4.x is already published, you should publish this backport with a tag (e.g. backport or 2.3) and avoid mutating latest. You can do this by changing the publish step to:

   - name: Publish
     env:
       NPM_CONFIG_PROVENANCE: true
     run: pnpm run release -- --tag backport

   (Or add a root script like release:backport if you prefer.)

This is the only thing that feels like a real risk; everything else is optional cleanup.

---

🟢 Minor — redundant build step

You run pnpm --filter @cloudflare/kumo build explicitly, but pnpm run release resolves to pnpm build:all && changeset publish, which rebuilds kumo (and everything else). That makes the explicit build a no-op. Harmless, but if you want to save a minute or two you can drop step Build package and rely on release's build:all.

---

🟢 Workflow structure

• Permissions: id-token: write + contents: write is correct for provenance + git push.
• Git identity: github-actions[bot] is consistent with what changesets/action uses.
• Commit + push order: Committing the version bump before publish is correct; changeset publish will create the tag, then you push both commit and tags. 👍
• Concurrency group: Using backport-release-${{ inputs.expected_version }} prevents double-runs for the same version. Good.

---

Recommendations

Priority	Action
Blocking	Verify whether 2.4.x is on npm. If yes, add --tag to the publish step so you don't overwrite latest.
Optional	Remove the explicit Build package step to avoid a redundant build.

If the latest tag situation is intentionally safe, I'm happy to approve.

github run

[pkg-pr-new]

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

commit: 280d43d

[github-actions]

Docs Preview

View docs preview

Commit: d674741

[mattrothenberg]

/bonk re-review

[ask-bonk]

Re-review for PR #556

Good response to the previous review. The blocking concern has been addressed.

---

✅ Resolved — dist-tag guard

You switched from pnpm run release to pnpm exec changeset publish --tag backport. This correctly protects the latest dist-tag on npm. 👍

✅ Resolved — build step necessity

Since you now invoke changeset publish directly (rather than via the release script which bundles build:all), the explicit Build package step is no longer redundant — it's required. The workflow structure is coherent.

🟢 Minor observation — build scope

You build only @cloudflare/kumo (pnpm --filter @cloudflare/kumo build) rather than the full pnpm build:all. For this monorepo that should be fine because the other workspace packages (docs, figma, screenshot-worker) depend on kumo, not the reverse. On the controlled backport branch this is low risk.

🟢 No new blocking issues

• NPM_CONFIG_PROVENANCE: true is preserved. ✅
• Concurrency group still prevents double-runs. ✅
• Push-after-publish ordering is maintained. ✅

---

Verdict: This is safe to ship as a temporary workflow. The latest tag is protected and the backport will publish cleanly under the backport dist-tag.

github run