When deploying versions for an
When deploying versions for an individual PR, is there a way to supply it's own env var for runtime. I am using GH Actions for deploy. Where BuildTime env Vars can be controlled but run time where I would like to specify for each version.
6 Replies
Do you mean a
var binding that could be provided in the Wrangler config file?
Are you saying that you have the value for one of these variables in the current process (env var) and want to ensure they are pushed to production?
Generally one would use wrangler secret put for this.Sorry, I mean exactly that. wrangler secret, say the DB url with auth, I have from neon for the branch. I would like to inject it to run time secret for that version only.
As, each of the PRs would have the DB branched of the staging version of the DB.
Can you create two Wrangler environments -
staging and production in your Wrangler config file. Then when you deploy your PR preview to staging it would use --env=staging and off main it would use --env=production.
Then you can upload the secret to the appropriate environment via wrangler secret put --env=staging (or the equivalent wrangler versions secret put command.@petebd Sorry for the ping, but I have a related issue. Wrangler enviroments won't work, and
wrangler secret put just caused a production outage for us. We do have 5 environments, and roughly 10 PRs. which we need dedicated preview enviroments for. That means for each of the 5 wrangler enviroments we need following deployments:
- production track
- PR1 deployment track
- PR2 deployment track
- ...
Currently we do this with wrangler versions upload, which adds new versions which we can preview under the preview url, however they are not separated. When we now want to add a secret to the production track with wrangler secret put KEY, it does take the latest version from the version list, and deploys it. That however could be a preview version. So a preview version just got propagated to production. To be able to do it correctly, we would have to create a new production version and then directly set the secret. In the Pages production & preview are separated, however it is still not enough. I would expect another level here. Wrangler enviroments which end up in dedicated instances with a suffix name-enviroment, deployment tracks inside each worker instance maybe based on --branch flag, which allow for all settings again. Also versions should be deletable, when the PR is closed. I hope my explanation make sense, and I could also show you the issue in a screen share if needed.Do you need to use
wrangler versions secrets putWould those secrets be available with the next
wrangler versions upload or wrangler deploy deployments?
Regardless of that, I find it not intuitive that all versions are a big list sorted by date, and not scoped to the branch they where deployed from.
I'm starting to think the better way would be to use --env branch-name for preview URLs, since everything else is super limited.. e.g. vars are not configurable, versions are not scoped per branch, no logs for preview versions, no option to remove versions, etc.
But then it's not trivial to configure this, since those "PR Branch" versions should not be configured in wrangler.jsonc because they are ephemeral and for our usecase (offering a whitelabel) we already use --env for the tenant, so we end up with TENANTS * PR COUNT where we will easily hit the 500 limit.
Who would be the best PM to address this with, so maybe we can improve the experience here?