Preview only environment group

Hello there,

We currently have a prod environment group which we use across all prod services/workers.

Is there a way to use e.g. a preview environment group for preview deployments only? Can’t quite figure out how to express this in the yaml file, if at all possible.

I know there’s a previewValue field for individual environment variable overrides, but ideally we’d like to have a separate environment variable group used for all preview deployments.

Cheers!

2 Likes

Also it seems like I can’t override a variable in my prod env group like follows:

    envVars:
      - key: MY_KEY
        previewValue: ***
      - fromGroup: prod # Attempting to override MY_KEY from here

Sync complains stating value doesn’t exist - doesn’t seem to be too easy to use the preview deployments when relying heavily upon environment groups.

Is there a way to use e.g. a preview environment group for preview deployments only?

You can define the env-based values in your YAML file like this, and then use fromGroup in your services:

envVarGroups:
- name: global-ev-group
  envVars: 
  - key: key-1
    value: prod-value
    previewValue: preview-value

The only issue here would be that the preview environments will each create a copy of the environment group, though env groups are free of charge and get deleted as soon as your PR is closed.

… it seems like I can’t override a variable in my prod env group

Since we are using the YAML format, you will need to remove the - from your fromGroup line.

Hi @mahsa - the problem is that the secret keys are sensitive so I don’t want to store them in the YAML file & commit them.

It’s almost like we need something like the following:

fromGroup: prod
previewFromGroup: staging
2 Likes

Hi @mtford,

What you’re saying definitely makes sense. Right now, there’s no way to have preview-specific configuration for environment variables that isn’t defined directly in the render.yaml. This is something I think would benefit a lot of users who are using preview environments, so I’ve created an internal issue to track this.

In the mean time, the only solutions I can think of are workarounds, like injecting two environment variable groups with different keys (like *_PROD and *_PREVIEW) and conditionally selecting between them in your run script. This obviously isn’t ideal since the production values would still be available in the preview environment services, so depending on your security requirements, this workaround might not be acceptable for you.

4 Likes

I second this request. I wouldn’t really have a need to dive into the render.yaml if there was simply a way to select a different environment for pull request previews.

Guessing this will be a pretty common use case amongst production applications. Currently we have our pull request builds point at a staging api instead of our production api. Trying to get our app deployment working in Preview and this was the first hiccup I ran into. Otherwise I’m really liking the platform!

FYI this was easily configured in Heroku using “Review app config vars”. Not to distract too much from this thread, but it’d also be nice to include a UI control for the render.yaml parameter previewsExpireAfterDays. Not sure if that shows up once I get things working, but was surprised that I didn’t see this in the settings page.

Thanks for your feedback @BradRyan! I’ve made note of it in the internal issue Dan mentioned.

1 Like

+1 to this feature!

Hey team, I also wanted to +1 this issue. I don’t want to commit secrets to github but that seems to be the only way to connect to a QA database. Without that there is limited utility in PR previews.

1 Like

Hey @kcc989, I didn’t test this, but I guess it could work.

If you have env vars DATABASE_URL_PROD and DATABASE_URL_QA set up in the render.com UI and linked to your service, then you can use the env var names as a value or previewValue in the render.yaml file. Something like this:

previewsEnabled: true

services:
  - name: api
    type: web
    env: elixir
    envVars:
      - key: DATABASE_URL_ENV_VAR_NAME
        value: DATABASE_URL_PROD
        previewValue: DATABASE_URL_QA
    buildCommand: .render.com/build.sh
    startCommand: .render.com/start.sh
    autoDeploy: true
    plan: starter
    numInstances: 1

And then reference the value of the particular env var itself like this (bash):

DATABASE_URL_PROD="your PROD DB credentials"
DATABASE_URL_QA="your QA DB credentials"
DATABASE_URL_ENV_VAR_NAME=DATABASE_URL_QA
echo ${!DATABASE_URL_ENV_VAR_NAME} # prints your QA DB credentials

Of course, preview only env groups would be very useful, but this little hack could hopefully solve your situation.

I stumbled upon this issue after opening a similar one of my own.

As I don’t see anything like this on the roadmap, I went ahead and created a feature request that I hope summarizes this thread. Feel free to upvote it if you want this feature :slight_smile:

2 Likes

I sort of expected this to work by having a previewValue on the fromGroup:

previewsEnabled: true
previewsExpireAfterDays: 1 #  automatically delete the environment after the specified number of days of inactivity
services:
  - type: web
    name: app
    env: node
    plan: free
    buildCommand: npm install &&
      npm run build
    startCommand: npm run start
    healthCheckPath: /api/trpc/healthz
    envVars:
      - key: NODE_ENV
        value: production

      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString

      - fromGroup: app-prod
        previewValue: app-preview

databases:
  - name: app-db
    plan: starter
    previewPlan: starter

Hey Alexander,
I can definitely see your way of thinking but it won’t work - we’re planning a lot of work around blueprints and thing is definitely an area we are hoping to improve,

Regards,

John B

1 Like