Update SDK to d1470710f514d8f73570685ee567472fe0cd3807

.claude/commands/write-pr-description.md

@@ -0,0 +1,77 @@
+---
+description: >
+  Write or improve a GitHub pull request description. Use when the user asks
+  to "write a PR description", "improve the PR description", "update the PR
+  body", or provides a PR URL and asks for a better description.
+  Keywords: PR description, pull request summary, PR body, PR writeup.
+allowed-tools: [Read, Glob, Grep, Bash, ToolSearch]
+---
+
+# Write PR Description
+
+Generate a structured PR description that explains **why** the change exists,
+not just what files were touched.
+
+## When to use
+
+- The user provides a PR URL and asks to write or improve its description.
+- The user asks to draft a PR description for the current branch.
+- An agent needs to open a PR and wants a high-quality description.
+
+## Workflow
+
+### Phase 1: Gather context
+
+Collect all the information needed to understand the change:
+
+1. **Read the PR metadata** — title, current description, author, branch name.
+2. **Read the full diff** — understand every file changed, every function added
+   or removed, every signature change. Do not skip files.
+3. **Read surrounding code when needed** — if the diff modifies an interface or
+   a struct, read the full file to understand how the change fits into the
+   existing architecture.
+4. **Check for linked issues or docs** — the PR or commit messages may
+   reference issues, design docs, or RFCs that explain motivation.
+
+### Phase 2: Analyze the change
+
+Before writing, answer these questions internally:
+
+- **What was the status quo before this PR?** What limitation, bug, or missing
+  capability existed?
+- **Why is this change needed now?** What concrete problem does it solve? Who
+  benefits?
+- **What are the key design decisions?** Why was this approach chosen over
+  alternatives?
+- **What is the new API surface?** Any new public types, functions, or
+  configuration options?
+- **What are the architectural changes?** How does the internal structure
+  change? What moves where? What gets refactored?
+- **Are there behavioral changes?** If not, say so explicitly — this reassures
+  reviewers.
+
+### Phase 3: Write the description
+
+Use the structure defined in `.github/PULL_REQUEST_TEMPLATE.md` as the
+template. The tone should be direct and technical. Write for a reviewer who is
+familiar with the codebase but has not seen this change before.
+
+**Key principles:**
+
+- **Lead with why, not what.** The diff already shows the what. The description
+  should explain the reasoning that is not visible in the code.
+- **Be specific.** Instead of "improves extensibility", say "allows internal
+  tools to compose their own auth chain from individual credential strategies".
+- **Name things.** Reference actual types, functions, files, and config fields.
+  Use backticks for code references.
+- **State non-changes explicitly.** If the PR is a refactor with no behavioral
+  change, say "No behavioral changes. Existing users are unaffected." This is
+  valuable information for reviewers.
+- **Keep the summary to one or two sentences.** It should be scannable.
+- **Use the motivation section to tell a story.** What was the problem? Why
+  couldn't it be solved before? What does this PR unlock?
+
+### Phase 4: Update the PR
+
+Use the GitHub MCP tools or `gh` CLI to update the PR body with the new
+description. Confirm with the user before pushing if unsure.

CHANGELOG.md

@@ -1,5 +1,18 @@
 # Version changelog
 
+## Release v0.118.0 (2026-06-18)
+
+### API Changes
+* Add `create_data_api()`, `delete_data_api()`, `get_data_api()` and `update_data_api()` methods for [w.postgres](https://databricks-sdk-py.readthedocs.io/en/latest/workspace/postgres/postgres.html) workspace-level service.
+* Add `capacity_reservation_group` field for `databricks.sdk.service.compute.AzureAttributes`.
+* Add `serverless_compute_id` field for `databricks.sdk.service.pipelines.ClonePipelineRequest`.
+* Add `serverless_compute_id` field for `databricks.sdk.service.pipelines.CreatePipeline`.
+* Add `serverless_compute_id` field for `databricks.sdk.service.pipelines.EditPipeline`.
+* Add `serverless_compute_id` field for `databricks.sdk.service.pipelines.PipelineSpec`.
+* Add `endpoint_id` field for `databricks.sdk.service.vectorsearch.MiniVectorIndex`.
+* Add `endpoint_id` field for `databricks.sdk.service.vectorsearch.VectorIndex`.
+* Add `dynamics365` enum value for `databricks.sdk.service.catalog.ConnectionType`.
+
 ## Release v0.117.0 (2026-06-11)
 
 ### API Changes

CONTRIBUTING.md

@@ -1,8 +1,25 @@
-We happily welcome contributions to the Databricks SDK for Python. We use [GitHub Issues](github.com/databricks/databricks-sdk-py/issues) to track community reported issues and [GitHub Pull Requests](https://github.com/databricks/databricks-sdk-py/pulls) for accepting changes.
+We happily welcome contributions to the Databricks SDK for Python. We use [GitHub Issues](https://github.com/databricks/databricks-sdk-py/issues) to track community reported issues and [GitHub Pull Requests](https://github.com/databricks/databricks-sdk-py/pulls) to collect proposed changes.
 Contributions are licensed on a license-in/license-out basis.
 
 # Contributing Guide
 
+## This repository is a mirror
+
+This repository is a read-only mirror: the source of truth for the SDK
+lives in Databricks' internal repository, and the contents here are
+published from it as part of each release. What this means for you:
+
+- **Issues** are tracked publicly
+  [here](https://github.com/databricks/databricks-sdk-py/issues).
+- **External contributors:** pull requests with potential improvements
+  should be made against this repository. These pull requests will be
+  reviewed here, but will not be merged directly once approved.
+  Rather, a maintainer will re-apply the changes in the Databricks
+  internal repository and publish them as part of the next release.
+- **Databricks employees:** do not open pull requests against this
+  repository. Make your change in the internal repository following the
+  internal SDK contribution procedure.
+
 ## Communication
 Before starting work on a major feature, please open a GitHub issue. We will make sure no one else is already working on it and that it is aligned with the goals of the project.
 A "major feature" is defined as any change that is > 100 LOC altered (not including tests), or changes any user-facing behavior.

README.md

@@ -7,6 +7,10 @@
 [![codecov](https://codecov.io/gh/databricks/databricks-sdk-py/branch/main/graph/badge.svg?token=GU63K7WDBE)](https://codecov.io/gh/databricks/databricks-sdk-py)
 [![lines of code](https://tokei.rs/b1/github/databricks/databricks-sdk-py)]([https://codecov.io/github/databricks/databricks-sdk-py](https://github.com/databricks/databricks-sdk-py))
 
+> This repository is a read-only mirror, published from Databricks'
+> internal repository with each release. Pull requests are reviewed
+> here but merged internally (see [CONTRIBUTING.md](CONTRIBUTING.md)).
+
 [Beta](https://docs.databricks.com/release-notes/release-types.html): This SDK is supported for production use cases, 
 but we do expect future releases to have some interface changes; see [Interface stability](#interface-stability). 
 We are keen to hear feedback from you on these SDKs. Please [file issues](https://github.com/databricks/databricks-sdk-py/issues), and we will address them.