[wrangler] Add --tag support to versions deploy#14211
Conversation
🦋 Changeset detectedLatest commit: edd87ae The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
I've completed a thorough review. The implementation is well-structured, consistent with the existing The edge cases I found — tag/version-id collision silently overwriting an explicit percentage, duplicate LGTM |
|
✅ All changesets look good |
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
@cloudflare/wrangler-bundler
commit: |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
Production deploys are commonly tagged with the commit SHA via
wrangler versions deploy --tag <sha>(or at upload time). When rolling back, developers think in commit SHAs, butwrangler versions deployonly accepts CF Version IDs — so a rollback requires first runningwrangler versions listto map a commit SHA to a Version ID.This adds a
--tagflag towrangler versions deployso you can deploy a version by its tag directly:The tag is resolved to a Version ID by matching the
workers/tagannotation against the worker's deployable versions. The<tag>@<percentage>shorthand mirrors the existing<version-id>@<percentage>notation, and multiple--tagvalues can be used to split traffic (and--tagcan be combined with explicit Version IDs).Behaviour notes:
wrangler versions list.The deployable-versions fetch populates the existing version cache, so the subsequent prompt/deploy flow reuses it without extra API round-trips.
--tagflag will follow before it ships.