Add doc strings for common bundle resource fields#5664
Conversation
Integration test reportCommit: 6122f06
|
Document the common fields DABs injects across resources in the bundle JSON schema: permissions, lifecycle, and grants. These previously showed empty tooltips/docs on many resources. - permissions: fill the 8 SDK-typed variants' item subfields (level, user_name, service_principal_name, group_name) and add a field-level description, markdown_description, and example on all resources. - lifecycle: propagate the existing field-level description to the resources where it was still a placeholder. - grants: add a field-level description, markdown_description, and example on the UC resources (subfields come from the SDK). Regenerated bundle/schema/jsonschema.json.
The annotations.yml/jsonschema.json doc string additions for permissions, lifecycle, and grants were not propagated to the generated pydabs models, so validate-generated failed. Ran pydabs-codegen to sync them.
Align the permissions, grants, and permission-subfield doc strings with the Databricks docs (bundle permissions, Unity Catalog manage-privileges and permissions-concepts): - level: clarify the allowed levels depend on the resource type. - permissions: describe that each item grants one level to a single user/group/service principal and note the no-overlap rule with the top-level permissions mapping. - grants: match the resources reference wording and link to the Unity Catalog manage-privileges docs. - group/user/service_principal_name: use the docs' "granted" phrasing. Regenerated jsonschema.json and pydabs bindings.
fe1e312 to
37df68d
Compare
| "lifecycle": | ||
| "description": |- | ||
| PLACEHOLDER | ||
| Lifecycle is a struct that contains the lifecycle settings for a resource. It controls the behavior of the resource when it is deployed or destroyed. |
There was a problem hiding this comment.
cc @andrewnester @juliacrawf-db
Can omit "struct" (user's don't care). Also "the behavior of the resource" is vague and doesn't capture everything. This sentence should be refined.
There was a problem hiding this comment.
Changed to "Settings that control the deployment lifecycle of the resource, such as preventing it from being destroyed." here and in other cases. Please let me know if some other wording is better!
There was a problem hiding this comment.
Thank you! If there is additional copy editing needed it can be done in a follow up PR.
| "markdown_description": |- | ||
| A Sequence of permissions to apply to this resource, where each item grants a permission `level` to a single `user_name`, `group_name`, or `service_principal_name`. A principal cannot be set in both a resource's `permissions` and the top-level `permissions` mapping. | ||
|
|
||
| See [\_](/dev-tools/bundles/settings.md#permissions) and [\_](/dev-tools/bundles/permissions.md). |
There was a problem hiding this comment.
These links resolve on the docs site but not in JSON schema right?
Is there precedence for including such links?
There was a problem hiding this comment.
Right, this follows an existing pattern in annotations.yml, for example, line 310 in this file. I used the same convention here for consistency, but would be happy to remove them if it makes more sense!
There was a problem hiding this comment.
Got it, thanks for clarifying.
Drop the implementation-detail "struct" wording and the vague "controls the behavior" phrasing in favor of describing the actual behavior.
The previous commit refined the lifecycle field description in annotations.yml and jsonschema.json but did not regenerate the Python bindings, causing the validate-generated CI check to fail.
| "lifecycle": | ||
| "description": |- | ||
| PLACEHOLDER | ||
| Lifecycle is a struct that contains the lifecycle settings for a resource. It controls the behavior of the resource when it is deployed or destroyed. |
There was a problem hiding this comment.
Thank you! If there is additional copy editing needed it can be done in a follow up PR.
| "markdown_description": |- | ||
| A Sequence of permissions to apply to this resource, where each item grants a permission `level` to a single `user_name`, `group_name`, or `service_principal_name`. A principal cannot be set in both a resource's `permissions` and the top-level `permissions` mapping. | ||
|
|
||
| See [\_](/dev-tools/bundles/settings.md#permissions) and [\_](/dev-tools/bundles/permissions.md). |
There was a problem hiding this comment.
Got it, thanks for clarifying.
Changes
Document the common fields DABs injects across resources in the bundle JSON schema, which previously rendered empty tooltips/docs on many resources. The wording is aligned with the official Databricks docs (bundle permissions, Unity Catalog manage-privileges, and UC permissions concepts):
permissions— fill the 8 SDK-typed variants' item subfields (level,user_name,service_principal_name,group_name) and add a field-level description +markdown_description+ example on all resources. The description notes that each item grants onelevelto a single user/group/service principal, and that a principal cannot appear in both a resource'spermissionsand the top-levelpermissionsmapping.levelclarifies that the allowed values depend on the resource type.lifecycle— propagate the existing field-level description to the resources where it was still a placeholder.grants— add a field-level description +markdown_description+ example on the UC resources (subfields come from the SDK), matching the resources reference wording and linking to the UC manage-privileges docs.Regenerated
bundle/schema/jsonschema.jsonand the pydabs Python bindings (python/databricks/bundles/**) so the generated artifacts stay in sync.Why
These are the cross-cutting fields DABs owns on every resource, but their docs were only partially filled, so editor completions and the docs site showed blanks inconsistently. The remaining schema placeholders are resource-specific API fields whose descriptions belong upstream in the OpenAPI spec, not as CLI-only overrides, so they are intentionally left out.
Tests
Docs-only/schema change.
go test ./bundle/internal/schema/...passes, which verifies regeneration from the committed annotations is a no-op (no stale or missing placeholders).validate-generatedpasses now that the pydabs bindings are regenerated.