-
Notifications
You must be signed in to change notification settings - Fork 337
RFC: introducing environments #220
Comments
Instead of |
This is a must! What about incorporating this in
workflow to use the config
I know this is more work, but this would prevent users from having to copy/paste their wrangler.toml everywhere and then getting account and zone tags becomes part of the once per user task versus a once per project |
re: @gabbifish 's comment, i think adding configuration for wasm modules would be a great add independent of this change; i prefer a world in which users don't think about bindings (an implementation detail of the workers config api), but about wasm modules and kv namespaces. re: @victoriabernard92 's comment, long cli commands are rather cumbersome, i for sure prefer adding lines to config files, even if it means copy-pasting, or the premise of #302 appeals to me (specify .toml) as an alternative, but only based on taste; i think both designs could be enhanced by the composition approach above, it just comes down to whether you prefer to have a single toml containing all of your configs, or a separate toml per "environment". re: kv_namespaces, do recall the updated design for how this should look in the toml ( #319 ). I can for sure see a world in which you have "staging" and "prod" kv namespaces that use the same binding but bind to different namespace ids based on env. |
I think #302 as an alternative to this would be a good start, but is less appealing to me as if you had a couple of different environments, you would end up cluttering your development directory (I can also see naming conventions for different One outstanding question I have for this RFC is how do we want to handle deploying to zoneless workers with this environment setup? I can imagine a world where people stage on re @victoriabernard92 I don't think we want to have a giant command like that for configuring your zones - I think it almost makes more sense to pull down the available zones for an account from the API or to have another type of configuration file that allows you to alias zone/account combos
^ This also has the same issue of - how do we do stuff w/zoneless |
@EverlastingBugstopper in the short term, i assume the same rules apply as for when you are publishing with wrangler today: if you pass the changing that convention may not be within the scope of this rfc? |
My suggestion had two parts I should've broken down:
I bring up 1. in this RFC because the global config toml's should be designed to mirror how the
Thus significantly reduces "noise"
Note |
So it looks like there are a couple of things going on with this RFC. At the most basic level there is a desire to deploy a single project to multiple zones (and maybe across separate accounts, though that is less of a priority). There seem to be a couple of approaches that we can take:
Personally I think that solution 1 is perfectly fine and while you will need to copy + paste your configurations for new projects, it's generally easier than solution 2. I find solution 2 to be cumbersome to implement and also would be hard for developers who are working on a shared account as they wouldn't be able to clone a repo with the account/zone ids filled in already in the |
Since they have to run wrangler config anyways, the account tag, zone tags and KV will all be populated in that global file. Committing the This isn't fully flushed out for how to touch workers.dev, kv,.. that the configured account doesn't own. I imagine modeling it after the endpoint |
@victoriabernard92 listing your kv namespaces is part of milestone 6 (KV commands) so you will no longer need to go to the ui, if that makes a difference. #342 |
I think maybe it makes sense to start with solution 1 and then maybe later we can move to solution 2 if it makes sense/we don't think the proposed solution is ergonomic enough? Open to discussing this more. |
let's start implementing solution 1! once we get that in place we can think about how we'd extend it. |
Closing in favor of #385 |
Problem
As described #199, we should have a way to configure Wrangler based on an environment name.
Proposal
New command line argument
I'm suggesting to add an
--env NAME
argument forwrangler publish
andwrangler build
. Additionally we could use an environment variable.The build commande is included because a custom webpack configuration could take advantage of it to provide a specific configuration. However, to be able to access it we need to inject an environment variable called
WRANGLER_ENV
.Segmented configuration
I think that the entire configuration needs to be segmented by env, like the following example:
Some people expressed concern about
kv-namespaces
being common to all environment, using that kind of configuration it can be different in each environment while maintaining the same JavaScript interface.Why arbitrary env?
I doubt we know everyone's workflow, we should let the user make Wrangler fit to their needs.
While we can't indentify which env is for prod (optimized) and dev (debug) I don't think it's an issue; Cloudflare's Worker is just a compilation target I think we should build for prod all the time. For debugging we could take advantage of source maps (or Wasm equivalent, if any).
The text was updated successfully, but these errors were encountered: