Layering generally works the same for params and variables files. They use different folders. Example:
Params have a
.env extension, and vars have a
.rb extension. We’ll show a params example to cover the basics of layering.
config/blueprints/demo/params ├── base.env ├── dev.env └── prod.env
base.envis always evaluated.
prod.envis evaluated based on
In this case, you want to define your base params used for templates in the
base.env and overrides in
The basic example above shows layering with the top-level
config folder. You can also define layers within the blueprint.
You can have your layer files defined in the blueprint itself or at the project level. Example:
- Blueprint Layers: These layers ship with the blueprint. Think of them as defaults that ship with the blueprint itself. IE:
app/blueprints/demo/config. These layers are processed first and take lower precedence.
- Project Layers: These layers are your project-specific settings. IE:
config/blueprints/demo. These layers are processed later and take higher precedence. They override previous layer values.
It is recommended to define layers at the project-level,
config/blueprints. This allow blueprints to be even more reusable.
More step-by-step docs are provided in the next documentation pages and go into more details on layering.