Skip to content

Route /Skills paths to the Files API in databricks fs - #6147

Merged
renaudhartert-db merged 1 commit into
mainfrom
skills-files-api-routing-copy
Aug 3, 2026
Merged

Route /Skills paths to the Files API in databricks fs#6147
renaudhartert-db merged 1 commit into
mainfrom
skills-files-api-routing-copy

Conversation

@renaudhartert-db

Copy link
Copy Markdown
Contributor

Changes

filerForPath now routes dbfs:/Skills/... to the Files API filer, alongside the existing /Volumes/ branch, instead of falling through to the legacy DBFS filer.

Why

UC Skills are Files-API-native: the server exposes skill bundle bytes at /api/2.0/fs/files/Skills/<catalog>/<schema>/<skill>/<file>, exactly like Volumes. This lets users manage a skill bundle with the standard databricks fs commands, e.g.:

databricks fs cp -r ./my-skill dbfs:/Skills/<catalog>/<schema>/my-skill/

fs cp -r walks the local tree and PUTs each file via the Files API (no atomic bundle endpoint — same as Volumes). The dbfs: scheme is legacy URI naming only; the request goes to the Files API.

Scope

One-line routing change. No new command, API method, or endpoint — reuses the existing public Files API, parallel to how /Volumes/ is handled. Shell completion already keys off the dbfs: scheme, so no completion change is needed.

Tests

Added new tests to cover Volumes and Skills.

This pull request and its description were written by Isaac.

filerForPath now routes dbfs:/Skills/... to the Files API filer, alongside the
existing /Volumes/ branch, instead of falling through to the legacy DBFS filer.
Co-authored-by: Isaac
@eng-dev-ecosystem-bot

Copy link
Copy Markdown
Collaborator

Integration test report

Commit: c99059d

Run: 30824183329

Env🔄​flaky💚​RECOVERED🙈​SKIP✅​pass🙈​skipTime
💚​aws linux4430610708:51
💚​aws windows4430810685:27
🔄​azure linux44430110709:09
💚​azure windows4430710686:25
💚​gcp linux1530610706:56
💚​gcp windows1530810684:53
12 interesting tests: 4 RECOVERED, 4 SKIP, 4 flaky
Test Nameaws linuxaws windowsazure linuxazure windowsgcp linuxgcp windows
💚​TestAccept💚​R💚​R💚​R💚​R💚​R💚​R
🙈​TestAccept/bundle/invariant/no_drift🙈​S🙈​S🙈​S🙈​S🙈​S🙈​S
🙈​TestAccept/bundle/resources/vector_search_endpoints/drift/recreated_same_name🙈​S🙈​S🙈​S🙈​S🙈​S🙈​S
🙈​TestAccept/bundle/resources/vector_search_indexes/recreate/embedding_dimension🙈​S🙈​S🙈​S🙈​S🙈​S🙈​S
🙈​TestAccept/ssh/connection🙈​S🙈​S🙈​S🙈​S🙈​S🙈​S
🔄​TestFsCpFileToDirFileNotOverwritten✅​p✅​p🔄​f✅​p✅​p✅​p
🔄​TestFsCpFileToDirFileNotOverwritten/uc-volumes_to_uc-volumes✅​p✅​p🔄​f✅​p✅​p✅​p
🔄​TestFsRmEmptyDir✅​p✅​p🔄​f✅​p✅​p✅​p
🔄​TestFsRmEmptyDir/uc-volumes✅​p✅​p🔄​f✅​p✅​p✅​p
💚​TestFetchRepositoryInfoAPI_FromRepo💚​R💚​R💚​R💚​R🙈​S🙈​S
💚​TestFetchRepositoryInfoAPI_FromRepo/root💚​R💚​R💚​R💚​R
💚​TestFetchRepositoryInfoAPI_FromRepo/subdir💚​R💚​R💚​R💚​R
Top 5 slowest tests (at least 2 minutes):
durationenvtestname
2:59aws windowsTestAccept
2:56azure windowsTestAccept
2:56gcp windowsTestAccept
2:47azure linuxTestFilerWorkspaceFilesExtensionsReadDir
2:14azure linuxTestFilerWorkspaceFilesExtensionsRead

@@ -0,0 +1,6 @@

>>> [CLI] fs cp local.txt dbfs:/Skills/main/default/fs-cp-test-[UNIQUE_NAME]/README.md

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we have any file that records the api logs? That will basically capture which API we are using.

@renaudhartert-db
renaudhartert-db added this pull request to the merge queueAug 3, 2026
Merged via the queue into main with commit 92ad56eAug 3, 2026
26 checks passed
@renaudhartert-db
renaudhartert-db deleted the skills-files-api-routing-copy branch August 3, 2026 15:45
deco-sdk-taggingBot added a commit that referenced this pull request Aug 6, 2026
## Release v1.11.0
### CLI
* Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders (currently in preview), which the workspace API reports as directories rather than repos ([#6181](#6181)).
* Support `dbfs:/Skills/...` paths in `databricks fs` commands, routed to the Files API. ([#6147](#6147))
### Bundles
* For jobs where `ai_runtime_task.code_source_path` is a relative path to a local directory, the directory is now packaged into a tarball (honoring `.gitignore` and `sync.include`/`sync.exclude`), uploaded during deployment, and `code_source_path` is rewritten to the uploaded workspace path. ([#6110](#6110))
* Added JSON output to `bundle init`. Running `databricks bundle init <template> -o json` now reports the files the template wrote, relative to the output directory. This lets callers that pass `--output-dir` learn where the template materialized instead of assuming the output is a single directory named after the project. The default text output is unchanged. ([#6161](#6161))
* The terraform deployment engine is deprecated and will stop working in a future version of the CLI. Setting `bundle.engine: terraform` now emits a deprecation warning. See https://docs.databricks.com/aws/en/dev-tools/bundles/direct for how to migrate to the direct deployment engine. ([#6099](#6099))
* Fixed the direct deployment engine planning a spurious `create` for an empty `grants: []` list. Terraform records no grants resource for such a list, so `bundle plan` after `bundle deployment migrate` no longer reports an action for it. Emptying a previously deployed list still revokes the grants, after which the node is dropped from the deployment state instead of being reported as unchanged forever. ([#6039](#6039))
* Fixed `bundle generate` downloading notebooks found inside a folder without their file extension. They are now exported like top-level notebooks, so a Python notebook lands as `notebook.py` instead of an extensionless file ([#6144](#6144)).
* direct: `webhook_notifications.on_*` destinations on jobs, tasks, and `for_each_task` are now compared as unordered sets. Previously the Jobs API returning these lists in a different order than submitted produced a phantom diff that `bundle plan` and `bundle deploy` could never converge past, reporting `1 to change` on every run ([#6060](#6060)).
* Fixed a pipeline with `allow_duplicate_names: true` never converging on the direct engine: the field is only accepted on create/update and is never returned by the pipelines GET API, so every subsequent `bundle plan` reported the pipeline as a perpetual update. ([#6076](#6076))
* direct: A local change to an input-only field (one the API accepts on write but never returns on read, e.g. pipelines' `run_as` or external locations' `skip_validation`) is no longer silently skipped when the new value coincidentally matches the field's fabricated remote value. Previously such a change could hit the `remote_already_set` shortcut and be dropped from the plan. ([#6112](#6112))
* Revert usage of RedactiveSenstiveFields (added in [#5896](#5896), released in 1.10.0) which lead to incorrect behaviour (permanent drift) for duration field in Postgres resources ([#6179](#6179)).
* Document postgres resource fields in the json schema ([#6164](#6164), [#6163](#6163)).
* direct: Recreating a `vector_search_indexes` resource no longer fails with "Index ... is currently pending deletion" when the backend has not yet released the index name. The create is now retried until the name becomes available. ([#6143](#6143))
### Dependency Updates
* Bump `github.com/databricks/databricks-sdk-go` from v0.165.0 to v0.166.0. ([#6175](#6175))
* Upgrade Terraform provider to 1.124.0. ([#6174](#6174))
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@renaudhartert-db@eng-dev-ecosystem-bot@parthban-db