config
Layered configuration lookup: environment, .env, bundle, and app.yaml.
Every package resolves settings the same way: take the caller’s value, else
an environment variable, else a default. Local development adds two fallback
locations: .env files, one App’s resources.apps.<app>.config.env in
databricks.yml, and literal env values in app.yaml / app.yml.
values is LAZY (an object.Sequence), so databricks bundle validate
is only spawned when the environment and .env both missed; app YAML is only
read after the bundle source also missed.
Inside a deployed Databricks App all three file sources are skipped by default
(isDatabricksAppEnv): the platform has already turned them into real
environment variables, there is no bundle to validate, and the databricks
CLI is not on the image. Boolean environment overrides can force either file
source on or off when a tool needs different behavior.
Only the single bundle app’s config.env and literal app YAML env[].value
entries are consulted. Root bundle variables are not: they are authoring
inputs for the bundle itself (interpolated into targets, resources, and paths),
so treating one as a process setting resolves names the deployed app never sees.
Node-only (child_process, fs, process).
Interfaces
Section titled “Interfaces”Type Aliases
Section titled “Type Aliases”Variables
Section titled “Variables”- appEnvEntrySchema
- appSchema
- bundleAppSchema
- bundleEnvEntrySchema
- bundleResourceSchema
- ENV_ONLY
- MAX_TCP_PORT
- valueSchema