Support for reusable configuration in render.yaml or a place to define variables
R
Rob Brackett
I am working on a
render.yaml
file with many similarly configured cron jobs, and it would be great to have a way to define variables or repeatable base configurations. Right now, I’m using YAML anchors in a kind of messy way, where the first cron job configuration also defines variables that get re-used in later configurations. That’s messy though, because later cron jobs need to override things from the first job that they might not otherwise set if they had a more clean “base” config.I’d love to have something like what is described in this community forum post: https://community.render.com/t/freeform-area-to-set-up-yaml-anchors/2619
# This might be a special field name that people can
# use, or maybe extra top-level fields prefixed with
# `_` or something could be specially allowed.
variables:
# This just sets up a re-usable dictionary,
# but doesn't configure an actual service.
# This way, each service can have a smaller
# definition.
base-cron-config: &base-cron-config
type: cron
env: node
plan: standard
autoDeploy: true
repo: https://github.com/my-org/my-repo.git
buildCommand: 'npm install'
envVars:
- fromGroup: env-var-group-name
services:
- <<: *base-cron-config
name: Job 1
schedule: '0 0/3 * * *'
startCommand: npm run some-script
- <<: *base-cron-config
name: Job 2
plan: starter plus # Different resource needs
schedule: '0/20 * * * *'
startCommand: 'npm run another-script'
Alternatively, a system like CircleCI uses, where they have special command and environment variables you can create (rather than just YAML anchors/references) would work great, too: https://circleci.com/docs/2.0/reusing-config/
Log In
J
Jesse Pinho
I would love this feature as well. I just spent some time refactoring my
render.yaml
to use shared variables at the top of the file. Then I pushed it up as a PR and Render didn't deploy a PR instance for it. Apparently Render doesn't support that part of YAML syntax? Please add support for YAML's merge syntax! (https://stackoverflow.com/a/9197237/974981)T
Trey Matteson
We have the exact same use case of wanting to share some boilerplate between bunch of worker services, which YAML has a ready solution, as shown in the code above. I wonder if another possible trick, which complies with the existing grammer, would be for a worker or service with a certain kind of name to be ignored (but still be a little source of shared config code). The reason to use a special name (admitedly a hack), is that field will certainly be overridden by all users of the common config block.
A
Adam Solove
Hi Rob! Great question.
I'm wondering if you have tried using Render's "Environment Groups" (https://render.com/docs/blueprint-spec#environment-groups) for this or whether you ran into challenges there.
From this example, I think you could define a single env group with the shared values, then apply that group to each service, and then override the variables on services where you want them to be different.
But let me know if that doesn't work out for you and something more is needed!
R
Rob Brackett
Adam Solove: Hi Adam, environment groups is completely unrelated to what I’m looking for here, and wouldn’t solve the problem (I do use them; they’re great). This is about having reusable parts of a Render service configuration (or really any part of the
render.yaml
file at all), like the plan
, repo
, buildCommand
, etc. fields. Environment groups are just for environment variables (stuff that gets applied at runtime), so they can’t really do anything like what I’m looking for here.Basically, my situation is that I have whole list of services that share a lot of common configuration (that’s not env vars, although they also share that), and I’d like to define the common bits somewhere and then extend them or use them kind of like a template for each service.
J
Jonathan Garbee
GIthub actions allows us to use variables with double braces in the config content. A similar setup would be super useful with render yaml as well. My use case is having Content Security Policy that can be extended. I'd like to have my base config served for the app as a whole, but for certain pages I need to add new rules. That way I can say allow form-action on my contact page but not allow it anywhere else.