Improve wrangler deploy flow to also check for potential (and likely unintentional) secrets overrides

[dario-piotrowicz]

Fixes https://jira.cfdata.org/browse/DEVX-2347

Before in case of names overlaps wrangler deploy would just proceed with the deployment and override your remote secrets, now instead it will do something like this:

---

• Tests
  • Tests included
  • Tests not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: self explanatory UX improvement
• Wrangler V3 Backport
  • Wrangler PR: V3 backport: Improve wrangler deploy flow to also check for potential (and likely unintentional) secrets overrides #11405
  • Not necessary because:

[changeset-bot]

🦋 Changeset detected

Latest commit: de03c97

The changes in this PR will be included in the next version bump.

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

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@11389

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@11389

miniflare

npm i https://pkg.pr.new/miniflare@11389

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@11389

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@11389

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@11389

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@11389

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@11389

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@11389

wrangler

npm i https://pkg.pr.new/wrangler@11389

commit: de03c97

[github-actions]

Failed to automatically backport this PR's changes to Wrangler v3. Please manually create a PR targeting the v3-maintenance branch with your changes. Thank you for helping us keep Wrangler v3 supported!

Depending on your changes, running git rebase --onto v3-maintenance main dario/DEVX-2347/wrangler-deploy-from-dash-secrets might be a good starting point.

Notes:

• your PR branch should be named v3-backport-11389
• add the skip-v3-pr label to the current PR to stop this workflow from failing

[ascorbic]

Does it actually delete it, or just override it?

[dario-piotrowicz]

Does it actually delete it, or just override it?

Technically always delete it and then add the new value in.

When the one in question is an env variable it does look like an override from the user perspective since secrets and variables are shown in the same plain in the dashboard. But when it is a binding, it does look like a delete since bindings are presented in their own dashboard page and the secret in the other page just disappears.

[penalosa]

This seems like it has potential to go stale as new binding types are added?

[dario-piotrowicz]

Yes, I had the same exact thought, but I couldn't think of a solution for this... do you have some ideas? 😓

[penalosa]

Can you include a type guard (assert never or something?) to make sure all bindings types are covered?

[dario-piotrowicz]

No, I don't think a never-assertion is possible here since we do handle all possible keys, if the key happens to be a binding then we return the corresponding array of names otherwise we return an empty array 😕

(it's not like we need to ensure that key is the key for a bindings, since any other key is also valid here)

[penalosa]

Gotcha... I don't want to overindex on this problem since it's probably fine

[dario-piotrowicz]

ok thanks 🙂 🙏

stale