Release databricks-sdk-java

.codegen/_last_sha

@@ -1 +1 @@
-38d17606a44b9fc2e02b73e9ebc9b916998ad105
+6d999596a730026ac6e5e8559b6fc62e35257710

.github/PULL_REQUEST_TEMPLATE.md

@@ -65,7 +65,7 @@
 
 <!--
   Describe any tests you have done, especially tests that are not part of
-  the unit tests (e.g. local tests, integration tests, manual verification).
+  the unit tests (e.g. local tests or manual verification).
 
   ALWAYS ANSWER THIS QUESTION: answer with "N/A" if tests are not applicable
   to your PR (e.g. if the PR only modifies comments). Do not be afraid of

CHANGELOG.md

@@ -1,5 +1,13 @@
 # Version changelog
 
+## Release v0.162.0 (2026-10-07)
+
+### Security Vulnerabilities
+* Bump Jackson (`jackson.version`) from 2.18.9 to 2.18.11 to address CVE-2026-68497, CVE-2026-89407, CVE-2026-89425, CVE-2026-91776 and CVE-2026-91777.
+
+### API Changes
+* Add `healthCheck` field for `com.databricks.sdk.service.apps.AppDeployment`.
+
 ## Release v0.161.0 (2026-10-04)
 
 ### API Changes

CONTRIBUTING.md

@@ -97,9 +97,9 @@ log4j.logger.com.databricks.sdk=DEBUG
 ## Testing
 
 - All changes to the SDK should be covered by unit tests.
-- When applicable, new features should be covered by integration tests. Integration tests are automatically run against Databricks workspaces and accounts in AWS, Azure and GCP.
-- Integration tests should clean up after themselves. If an integration test creates a resource like a file or cluster, it should delete that resource after the test is complete.
-- Integration tests should reuse compute resources where possible.
+- Tests must be hermetic and must not require a live Databricks workspace or account.
+- API behavior should be tested at the HTTP boundary with local fixtures when request routing, pagination, streaming, headers, or response decoding are relevant.
+- Unit-level mocks remain appropriate for isolated control-flow behavior.
 
 ## Code conventions