-
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
Use fs.FS
interface to read template
#1910
Conversation
This removes the need to pre-materialize built-in templates.
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Test Details: go/deco-tests/11901443007 |
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.
Thanks! It's great that we do not copy files for built-in templates anymore. This will really improve latency for DABs in the workspace.
@@ -109,6 +110,24 @@ func getUrlForNativeTemplate(name string) string { | |||
return "" | |||
} | |||
|
|||
func getFsForNativeTemplate(name string) (fs.FS, error) { |
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.
func getFsForNativeTemplate(name string) (fs.FS, error) { | |
func getFsForBuiltInTemplate(name string) (fs.FS, error) { |
This can be confusing because we also have the nativeTemplates
slice above, which are really first-party templates. To keep this explicit, we should rename nativeTemplates
-> firstPartyTemplates
as well (along with the associated methods).
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.
Good point. This will require a bit more work than just the rename, though, so I will address this in a follow-up PR.
## Changes When running the CLI on Databricks Runtime (DBR), use the extension-aware filer to write an instantiated template if the instance path is located in the workspace filesystem. Notebooks cannot be written through the workspace filesystem's FUSE mount. As a result, this is the only method for initializing templates that contain notebooks when running the CLI on DBR and writing to the workspace filesystem. Depends on #1910 and #1911. Supersedes #1744. ## Tests * Manually confirmed I can initialize a template with notebooks when running the CLI from the web terminal.
**Note:** the `bundle generate` command now uses the `.<resource-type>.yml` sub-extension for the configuration files it writes. Existing configuration files that do not use this sub-extension are renamed to include it. Bundles: * Make `TableName` field part of quality monitor schema ([#1903](#1903)). * Do not prepend paths starting with ~ or variable reference ([#1905](#1905)). * Fix workspace extensions filer accidentally reading notebooks ([#1891](#1891)). * Fix template initialization when running on Databricks ([#1912](#1912)). * Source-linked deployments for bundles in the workspace ([#1884](#1884)). * Added integration test to deploy bundle to /Shared root path ([#1914](#1914)). * Update filenames used by bundle generate to use `.<resource-type>.yml` ([#1901](#1901)). Internal: * Extract functionality to detect if the CLI is running on DBR ([#1889](#1889)). * Consolidate test helpers for `io/fs` ([#1906](#1906)). * Use `fs.FS` interface to read template ([#1910](#1910)). * Use `filer.Filer` to write template instantiation ([#1911](#1911)).
**Note:** the `bundle generate` command now uses the `.<resource-type>.yml` sub-extension for the configuration files it writes. Existing configuration files that do not use this sub-extension are renamed to include it. Bundles: * Make `TableName` field part of quality monitor schema ([#1903](#1903)). * Do not prepend paths starting with ~ or variable reference ([#1905](#1905)). * Fix workspace extensions filer accidentally reading notebooks ([#1891](#1891)). * Fix template initialization when running on Databricks ([#1912](#1912)). * Source-linked deployments for bundles in the workspace ([#1884](#1884)). * Added integration test to deploy bundle to /Shared root path ([#1914](#1914)). * Update filenames used by bundle generate to use `.<resource-type>.yml` ([#1901](#1901)). Internal: * Extract functionality to detect if the CLI is running on DBR ([#1889](#1889)). * Consolidate test helpers for `io/fs` ([#1906](#1906)). * Use `fs.FS` interface to read template ([#1910](#1910)). * Use `filer.Filer` to write template instantiation ([#1911](#1911)).
Changes
While working on the v2 of #1744, I found that:
filer.Filer
but is hardcoded to a local oneThis change updates the interface for reading templates to be
fs.FS
. This is compatible with theembed.FS
type for the built-in templates, so they no longer have to be copied to a temporary directory before being used.The alternative is to use a
filer.Filer
throughout, but this would have required even more plumbing, and we don't need to read templates, including notebooks, from the workspace filesystem (yet?).As part of making
template.Materialize
take anfs.FS
argument, the logic to match a given argument to a particular built-in template in theinit
command has moved to sit next to its implementation.Tests
Existing tests pass.