mirror of https://github.com/databricks/cli.git
43 lines
2.2 KiB
Markdown
43 lines
2.2 KiB
Markdown
# Test path translation (with fallback to previous behavior)
|
|
|
|
As of v0.214.0, all paths in a resource definition were resolved relative to the path
|
|
where that resource was first defined. If those paths were specified in the same file,
|
|
or in a different file in the same directory, this would be intuitive.
|
|
|
|
If those paths were specified in a different file in a different directory, they would
|
|
still be resolved relative to the original file.
|
|
|
|
For example, a job defined in `./resources/my_job.yml` with an override
|
|
in `./override.yml` would have to use paths relative to `./resources`.
|
|
This is counter-intuitive and error-prone, and we changed this behavior
|
|
in https://github.com/databricks/cli/pull/1273.
|
|
|
|
## Appendix
|
|
|
|
Q: Why did this behavior apply as of v0.214.0?
|
|
|
|
A: With the introduction of dynamic configuration loading, we keep track
|
|
of the location (file, line, column) where a resource is defined.
|
|
This location information is used to perform path translation, but upon
|
|
introduction in v0.214.0, the code still used only a single path per resource.
|
|
Due to the semantics of merging two `dyn.Value` objects, the location
|
|
information of the first existing value is used for the merged value.
|
|
This meant that all paths for a resource were resolved relative to the
|
|
location where the resource was first defined.
|
|
|
|
Q: What was the behavior before v0.214.0?
|
|
|
|
A: Before we relied on dynamic configuration loading, all configuration was
|
|
maintained in a typed struct. The path for a resource was an unexported field on the
|
|
resource and was set right after loading the configuration file that contains it.
|
|
Target overrides contained the same path field, and applying a target override
|
|
would set the path for the resource to the path of the target override.
|
|
This meant that all paths for a resource were resolved relative to the
|
|
location where the resource was last defined.
|
|
|
|
Q: Why are we maintaining compatibility with the old behavior?
|
|
|
|
A: We want to avoid breaking existing configurations that depend on this behavior.
|
|
Use of the old behavior should trigger warnings with a call to action to update.
|
|
We can include a deprecation timeline to remove the old behavior in the future.
|