Parameters and Environment Values

Skeleton Entities

Skeleton Entity templates (Witboost 2.3+) introduce a parameters.yaml file in the skeleton directory that serves two distinct purposes:

1. Derived parameters: computed values based on user inputs, available on the catalog-info.yaml as parameters.*
2. Derived values: static values or mapped values through the creation template fetch:template step and that remain constant over time, available on the catalog-info.yaml as values.*.
3. Environment-specific parameters: values that differ per deployment environment (development, QA, production), available in catalog-info.yaml as env.*

This guide explains 1 and 3 and shows real-world patterns; for more information on 2, refer to the legacy style examples.

The parameters.yaml file structure

parameters:
  # --- derived / computed fields ---
  derivedField: ${{ parameters.someInput | someFilter }}

# This example shows manually defined values, but these can also be retrieved from user input via a environmentParameters: true step
environmentParameters:
  development:
    envSpecificField: ${{ parameters.someInput }}_development
  qa:
    envSpecificField: ${{ parameters.someInput }}_qa
  production:
    envSpecificField: ${{ parameters.someInput }}_production

Derived parameters useful patterns

Chained derived fields

Derived fields in parameters block can reference other values in the same parameters block:

parameters:
  domainNameNormalized: ${{ parameters.domain | replace(r/domain:| |-/, "") }}
  databaseDevelopment: ${{ parameters.domainNameNormalized | upper }}_DEVELOPMENT
  databaseQa: ${{ parameters.domainNameNormalized | upper }}_QA
  databaseProduction: ${{ parameters.domainNameNormalized | upper }}_PRODUCTION
  schema: ${{ parameters.dataProductNameNormalized | upper }}_${{ parameters.dataProductMajorVersion }}

Here, databaseDevelopment is derived from domainNameNormalized, which is itself derived from parameters.domain. The result: if the user creates a component in the domain domain:default/finance, then databaseDevelopment evaluates to FINANCE_DEVELOPMENT.

Schema inheritance override

One useful pattern of using derived fields with calculated expression is data inheritance + user override, where at creation we inherit data from other entities and then allow the user to manually override it using the edit-template. An example of this is data contract schema inheritance: the schema chosen by the user at creation time is captured in a derived field and becomes the editable schema for the Editor Wizard:

parameters:
  editSchemaColumns: ${{ parameters.schemaDefinition.schemaColumns if parameters.inheritSchema else [] }}

For a full explanation of this pattern and why it solves the one-time inheritance limitation, see Inherited Schema Override via parameters.yaml.

Environment-specific parameters

On Skeleton Entities, we provide a way to setup different values for each parameter depending on the environment. These values can be manually defined on the skeleton/parameters.yaml file as shown below, or be the output of user-input values from a form step with environmentParameters: true.

Basic pattern

environmentParameters:
  development:
    database: ${{ parameters.databaseDevelopment }}
  qa:
    database: ${{ parameters.databaseQa }}
  production:
    database: ${{ parameters.databaseProduction }}

In catalog-info.yaml (%SKELETON), reference the active environment's value with ${{ env.database }}. Witboost automatically substitutes the value for the environment being deployed or displayed.

Computed file names per environment

Some workload templates compute the expected artifact file name per environment, for example, an Airflow DAG whose Python file is named differently in each environment:

environmentParameters:
  development:
    dagFileName: ${{ parameters.dagName }}_development.py
  qa:
    dagFileName: ${{ parameters.dagName }}_qa.py
  production:
    dagFileName: ${{ parameters.dagName }}_production.py

In catalog-info.yaml:

    specific:
      dagName: ${{ env.dagFileName }}

The full annotated example is in example_parameters.yaml.

Using env.* in catalog-info.yaml

Access the active environment's values directly:

%SKELETON
# ...
    specific:
      database: ${{ env.database | default("") | replace(r/ |-/, "") }}
      schema: ${{ parameters.schema | replace(r/ |-/, "") }}

Note the | default("") guard on env.database — useful when the field may not be set in all environments or when the environment is unknown (e.g., during catalog preview).

Legacy entities approach: configurations.yaml files

Before Skeleton Entities, the equivalent mechanism was to place per-environment files in skeleton/environments/<env>/configurations.yaml. These were ordinary YAML files written once at creation time and not re-evaluated.

skeleton/
  environments/
    dev/
      configurations.yaml
    prod/
      configurations.yaml

The configurations.yaml files could contain templated values (written by fetch:template using values.*), but they were static after creation — a new creation was required to change an environment-specific value.

Feature	Legacy configurations.yaml	Skeleton environmentParameters
Update without re-create	No	Yes (via Editor Wizard)
Derived from user inputs	Fixed at creation	Re-evaluated at edit time
Self-referential chaining	Not possible	Supported (parameters.*)
Access in catalog-info.yaml	values.* static file copy	parameters.*, values.*, and env.* dynamic per-environment

For new templates, prefer environmentParameters in parameters.yaml. Use configurations.yaml only when maintaining Legacy templates that do not support Skeleton Entities.