-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add validation for files with a .(resource-name).yml
extension
#1780
Conversation
29a4ef8
to
fa6b68c
Compare
.<resource-type>.yml
files.(resource-name).yml
extension is used
.(resource-name).yml
extension is used.(resource-name).yml
extensio
.(resource-name).yml
extensio.(resource-name).yml
extensios
.(resource-name).yml
extensios.(resource-name).yml
extension
.(resource-name).yml
extension.(resource-name).yml
extension
Triggered nightlies against this PR... |
Nightlies are green! |
|
||
func validateFileFormat(r *config.Root, filePath string) diag.Diagnostics { | ||
for _, typ := range resourceTypes { | ||
for _, ext := range []string{fmt.Sprintf(".%s.yml", typ), fmt.Sprintf(".%s.yaml", typ)} { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fjakobs Can you comment on why we should check both?
Useful context to include here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the plan is to have DABs in the workspace support both .yml
and .yaml
since asking users to change .yaml
-> .yml
is a bit arbitrary in a recommendation for DABs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree.
@fjakobs Can you provide a snippet we can include for future readers wrt the expected extensions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do recommend using yml
but it feels a bit arbitrary to actively prohibit this.
It's a SHOULD in https://docs.google.com/document/d/1M4UqmNdpDgKMfuBVSghm_UtaDdYp4r-1SA0SuWsgG_k/edit#heading=h.bs9f118p0tig and not a must.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you.
Please update the PR summary to match the final version.
@fjakobs Could you suggest 1) a comment to include on the multiple extensions we apply this recommendation to, 2) consider including some kind of doc of text we can link to explaining why we make this recommendation. As is, we recommend it but don't explain why (although it could make sense in isolation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about updating the templates? Is this going to happen in a follow up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't offer a full review right now but a few nits
Co-authored-by: Lennart Kats (databricks) <[email protected]>
Co-authored-by: Lennart Kats (databricks) <[email protected]>
Co-authored-by: Lennart Kats (databricks) <[email protected]>
Co-authored-by: Lennart Kats (databricks) <[email protected]>
Important changes: Workspace paths are automatically prefixed with `/Workspace`. In addition, all usage of path strings such as `/Workspace/${workspace.root_path}/...` in bundle configuration is automatically replaced with `${workspace.root_path}/...` and generates a warning as part of bundle validate. If you have specified a custom `workspace.root_path`, `workspace.artifact_path`, or `workspace.file_path`, Databricks Asset Bundles automatically prefixes it with `/Workspace`, but if you use any of these as variables (for example, `my_config_path: /Workspace/${workspace.file_path}/config`), you need to update those entries to remove the /Workspace prefix to avoid the warning. If you pass one of these as variables and prefix them in your code, you need to update your code to not do this. This change is required because originally when the workspace file system was rooted at `/` and home directories were under `/Users`, to access workspace paths through the Databricks REST API you would use these paths directly. To access workspace paths from your code, you could use the `/Workspace` file path and home directories were also available under `/Workspace/Users`. To avoid this duality of workspace paths, as well as the ambiguity between workspace paths and Unity Catalog `/Volumes` paths, all workspace paths are prefixed with `/Workspace`. Bundles: * Add an error if state files grow bigger than the export limit ([#1795](#1795)). * Always prepend bundle remote paths with /Workspace ([#1724](#1724)). * Add resource path field to bundle workspace configuration ([#1800](#1800)). * Add validation for files with a `.(resource-name).yml` extension ([#1780](#1780)). Internal: * Remove deprecated or readonly fields from the bundle schema ([#1809](#1809)). API Changes: * Changed `databricks git-credentials create` command . New request type is . * Changed `databricks git-credentials delete` command . New request type is . * Changed `databricks git-credentials delete` command to return . * Changed `databricks git-credentials get` command . New request type is . * Changed `databricks git-credentials get` command to return . * Changed `databricks git-credentials list` command to return . * Changed `databricks git-credentials update` command . New request type is . * Changed `databricks git-credentials update` command to return . * Changed `databricks repos create` command . New request type is . * Changed `databricks repos create` command to return . * Changed `databricks repos delete` command to return . * Changed `databricks repos get` command to return . * Changed `databricks repos update` command . New request type is . * Changed `databricks repos update` command to return . OpenAPI commit 0c86ea6dbd9a730c24ff0d4e509603e476955ac5 (2024-10-02) Dependency updates: * Upgrade TF provider to 1.53.0 ([#1815](#1815)). * Bump golang.org/x/term from 0.24.0 to 0.25.0 ([#1811](#1811)). * Bump golang.org/x/text from 0.18.0 to 0.19.0 ([#1812](#1812)). * Bump github.com/databricks/databricks-sdk-go from 0.47.0 to 0.48.0 ([#1810](#1810)).
Notable changes for Databricks Asset Bundles: Workspace paths are automatically prefixed with `/Workspace`. In addition, all usage of path strings such as `/Workspace/${workspace.root_path}/...` in bundle configuration is automatically replaced with `${workspace.root_path}/...` and generates a warning as part of bundle validate. More details can be find here: https://docs.databricks.com/en/release-notes/dev-tools/bundles.html#workspace-paths-will-be-automatically-prefixed Bundles: * Add an error if state files grow bigger than the export limit ([#1795](#1795)). * Always prepend bundle remote paths with /Workspace ([#1724](#1724)). * Add resource path field to bundle workspace configuration ([#1800](#1800)). * Add validation for files with a `.(resource-name).yml` extension ([#1780](#1780)). Internal: * Remove deprecated or readonly fields from the bundle schema ([#1809](#1809)). API Changes: * Changed `databricks git-credentials create`, `databricks git-credentials delete`, `databricks git-credentials get`, `databricks git-credentials list`, `databricks git-credentials update` commands . * Changed `databricks repos create`, `databricks repos delete`, `databricks repos get`, `databricks repos update` command . OpenAPI commit 0c86ea6dbd9a730c24ff0d4e509603e476955ac5 (2024-10-02) Dependency updates: * Upgrade TF provider to 1.53.0 ([#1815](#1815)). * Bump golang.org/x/term from 0.24.0 to 0.25.0 ([#1811](#1811)). * Bump golang.org/x/text from 0.18.0 to 0.19.0 ([#1812](#1812)). * Bump github.com/databricks/databricks-sdk-go from 0.47.0 to 0.48.0 ([#1810](#1810)). --------- Co-authored-by: Pieter Noordhuis <[email protected]>
Changes
We want to encourage a pattern of specifying only a single resource in a YAML file when the
.(resource-type).yml
extension is used (for example,.job.yml
). This convention could allow us to bijectively map a resource YAML file to its corresponding resource in the Databricks workspace.This PR:
bundle validate
command.NOTE: While this PR also shows the recommendation for
.yaml
files, we do not encourage users to use this extension. We only support it here since it's part of the YAML standard and some existing users might already be using.yaml
.Tests
Unit tests and manually. Here's what an example output looks like: