-
Notifications
You must be signed in to change notification settings - Fork 393
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
[Feature] Add databricks_app
resource
#4099
base: main
Are you sure you want to change the base?
Conversation
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.
small changes in the doc required, otherwise code looks good
apps/resource_app.go
Outdated
return err | ||
} | ||
// now deploy the app, using the source code path | ||
createAppDeployment.AppName = app.Name |
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 think we discussed it offline and agreed that the deployment won't be part of TF configuration. Instead, if an users want to deploy, they use CLI to do that. Otherwise it's confusing because we do the deployments only when source_code_path changed but we need to do deployments when source code is changed.
@pietern wdyt?
apps/resource_app.go
Outdated
if err != nil { | ||
return err | ||
} | ||
if d.HasChanges("source_code_path", "mode") { |
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.
See my comment above, I think we should remove app deployment altogether for now
Just to clarify, I mean app resource needs to be added here so it can be part of the schema and be able to use it by DABs since we rely on generic |
@andrewnester makes sense - I've added |
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.
Behavior-wise, this seems OK to me. Can we use the plugin framework to implement this instead of the SDKv2? We're trying to move away from SDkv2 to plugin framework for all new resources.
apps/resource_app.go
Outdated
appNameValidationFunc := validation.StringMatch( | ||
regexp.MustCompile("^[a-z-]{2,30}$"), | ||
"name must contain only lowercase alphanumeric characters and hyphens, and be between 2 and 30 characters long") |
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.
Let's leave validation out and let server perform validation instead.
"update_time", "updater", "url"} { | ||
s.SchemaPath(p).SetComputed() | ||
} | ||
return s |
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.
Let's at least do the validation in the create/update. (Or at least test to verify what its behavior is.)
if err != nil { | ||
return err | ||
} | ||
_, err = w.Apps.Update(ctx, apps.UpdateAppRequest{ |
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.
Do we need to wait for state (like in create)?
apps/resource_app.go
Outdated
} | ||
return err | ||
} | ||
d.SetId(app.Name) |
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 we update this to get it back into a healthy state? if not this is fine. If so, let's set the ID before waiting for ready, then subsequent applies can call update.
) | ||
|
||
var appAliasMap = map[string]string{ | ||
"resources": "resource", |
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 ResourceApp() common.Resource { |
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.
BTW: Can we use the plugin framework for this new resource? Generally speaking, new resources should use the plugin framework, since it should be much more consistent for handling things like effective fields, dealing with lists, etc.
docs/resources/app.md
Outdated
|
||
-> This feature is in [Public Preview](https://docs.databricks.com/release-notes/release-types.html). | ||
|
||
Apps run directly on a customer’s Databricks instance, integrate with their data, use and extend Databricks services, and enable users to interact through single sign-on. |
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 we link to public docs about Apps?
docs/resources/app.md
Outdated
|
||
-> This feature is in [Public Preview](https://docs.databricks.com/release-notes/release-types.html). | ||
|
||
Apps run directly on a customer’s Databricks instance, integrate with their data, use and extend Databricks services, and enable users to interact through single sign-on. |
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 should probably mention that this only creates the application and doesn't do anything with the app deployment.
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/12044847955 |
Changes
databricks_app
resourceResolves #4084
Tests
make test
run locallydocs/
folderinternal/acceptance