Uh oh!
There was an error while loading. Please reload this page.
Refactor bundle init - #2074
Conversation
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. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
pietern
left a comment
There was a problem hiding this comment.
Please TAL at the remaining open comments before merging.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
## Summary of changes This PR introduces three new abstractions: 1. `Resolver`: Resolves which reader and writer to use for a template. 2. `Writer`: Writes a template project to disk. Prompts the user if necessary. 3. `Reader`: Reads a template specification from disk, built into the CLI or from GitHub. Introducing these abstractions helps decouple reading a template from writing it. When I tried adding telemetry for the `bundle init` command, I noticed that the code in `cmd/init.go` was getting convoluted and hard to test. A future change could have accidentally logged PII when a user initialised a custom template. Hedging against that risk is important here because we use a generic untyped `map<string, string>` representation in the backend to log telemetry for the `databricks bundle init`. Otherwise, we risk accidentally breaking our compliance with our centralization requirements. ### Details After this PR there are two classes of templates that can be initialized: 1. A `databricks` template: This could be a builtin template or a template outside the CLI like mlops-stacks, which is still owned and managed by Databricks. These templates log their telemetry arguments and template name. 2. A `custom` template: These are templates created by and managed by the end user. In these templates we do not log the template name and args. Instead a generic placeholder string of "custom" is logged in our telemetry system. NOTE: The functionality of the `databricks bundle init` command remains the same after this PR. Only the internal abstractions used are changed. ## Tests New unit tests. Existing golden and unit tests. Also a fair bit of manual testing.
Summary of changes
This PR introduces three new abstractions:
Resolver: Resolves which reader and writer to use for a template.Writer: Writes a template project to disk. Prompts the user if necessary.Reader: Reads a template specification from disk, built into the CLI or from GitHub.Introducing these abstractions helps decouple reading a template from writing it. When I tried adding telemetry for the
bundle initcommand, I noticed that the code incmd/init.gowas getting convoluted and hard to test. A future change could have accidentally logged PII when a user initialised a custom template.Hedging against that risk is important here because we use a generic untyped
map<string, string>representation in the backend to log telemetry for thedatabricks bundle init. Otherwise, we risk accidentally breaking our compliance with our centralization requirements.Details
After this PR there are two classes of templates that can be initialized:
databrickstemplate: This could be a builtin template or a template outside the CLI like mlops-stacks, which is still owned and managed by Databricks. These templates log their telemetry arguments and template name.customtemplate: These are templates created by and managed by the end user. In these templates we do not log the template name and args. Instead a generic placeholder string of "custom" is logged in our telemetry system.NOTE: The functionality of the
databricks bundle initcommand remains the same after this PR. Only the internal abstractions used are changed.Tests
New unit tests. Existing golden and unit tests. Also a fair bit of manual testing.