Databricks Community

Charansai · ‎02-04-2026

Hi everyone,

I’m using Databricks Asset Bundles and running into an issue when deploying to my dev environment in development mode. Even though my bundle includes sync paths and notebook directories, the deployment only creates the .databricks/artifacts and .databricks/state folders — but none of my notebooks appear in the workspace.

Important context

I am performing the deployment directly from the Databricks Workspace Editor (the built‑in editor inside the Databricks UI), not from a local machine. I expected development mode to sync my src, resources, and tests folders into the workspace automatically, but that isn’t happening.

What I’m seeing

Running databricks bundle deploy -t dev from the Workspace Editor
Deployment completes with no errors
Only .databricks/artifacts and .databricks/state appear in the workspace
No notebooks or code folders are synced

My bundle.yml

yaml

variables:
  source_catalog:
    default: "cat_de_conformance"
  source_schema:
    default: "default"
  source_table:
    default: "employees"
  sink_catalog:
    default: "cat_dstd"
  sink_schema:
    default: "default"
  sink_table:
    default: "employees_department_stats"
  sink_dlt:
    default: "employees_department_stats_dlt"
  schedule_cron_expression:
    default: "23 30 15 * * ?"
  timezone_id:
    default: "America/New_York"
  pause_status:
    default: "UNPAUSED"
  test_job_parameter:
    default: "DEFAULT_DEV_JOB_PARAMETER"
  existing_cluster_id:
    default: ""

bundle:
  name: dbw-datalakehouse
  uuid: 87d5a23e-7bc7-e-e374b67d

artifacts:
  python_artifact:
    type: whl
    build: uv build --wheel

include:
  - resources/*.yml
  - resources/*/*.yml

sync:
  paths:
    - src
    - resources
    - tests

targets:
  dev:
    mode: development
    default: true
    workspace:
      host: https://adb-3960838.18.azuredatabricks.net
      root_path: /Workspace/Users/${workspace.current_user.userName}/Data_Lakehouse
    permissions:
      - service_principal_name: 1cb41354-64f9fa-48c6973a4a7d
        level: CAN_MANAGE
    run_as:
      service_principal_name: 1cb41354-6-99fa-48c6973a4a7d

  qa:
    mode: production
    default: true
    workspace:
      host: https://adb-2386398.18.azuredatabricks.net
      root_path: /Workspace/Shared/Data_Lakehouse
    permissions:
      - service_principal_name: 6ce6f4f2-9-9444-f1f63f88fb5b
        level: CAN_MANAGE
    run_as:
      service_principal_name: 6ce6f4f2--9444-f1f63f88fb5b

My questions

Does development mode skip notebook deployment when running from the Databricks Workspace Editor?
Should I be using bundle sync instead of bundle deploy for notebooks to appear?
Is my sync.paths configuration correct for syncing notebooks from src?
Are there limitations when deploying from the Workspace Editor vs. local CLI?
Is this expected behavior when using service principals in development mode?

Any insights or examples from others who have solved this would be greatly appreciated. Thanks in advance!

IM_01 · ‎02-04-2026

Hi @Charansai As you mentioned you are using databricks workspace so the files in the current folder will be used as source files because source linked deployment is enabled which means current working folder files are referenced as source code files without creating copies of files

saurabh18cs · ‎02-05-2026

Hi @Charansai can you try reversing this one :
FROM:

sync:
  paths:
    - src
    - resources
    - tests

TO: (for an example)

sync:

exclude:

- ./.azure-pipelines

- ./.azuredevops

- ./.databricks

- ./.vscode

- ./.venv

SteveOstrowski · 2 weeks ago

Hi @Charansai,

The behavior you are seeing is actually expected when deploying a bundle from the Databricks Workspace Editor. Here is why.

SOURCE-LINKED DEPLOYMENT

When you deploy a bundle from within the workspace (as opposed to using the Databricks CLI on a local machine), Databricks enables "source-linked deployment" by default. This means that deployed resources (jobs, pipelines, etc.) reference your source files directly in their current workspace location rather than copying them to a separate deployment path. As a result, the file synchronization step to the root_path is skipped entirely.

That is why you only see .databricks/artifacts and .databricks/state folders at your root_path, and your notebooks from src, resources, and tests do not appear there as copies. They do not need to, because the deployed jobs and pipelines point back to the original files in your workspace folder.

In short: your notebooks are not missing. They are being referenced in place, not duplicated.

HOW THIS DIFFERS FROM LOCAL CLI DEPLOYMENT

When you run "databricks bundle deploy" from a local machine using the Databricks CLI, the CLI uploads (syncs) your local files to the workspace root_path. The source_linked_deployment preset is ignored by the CLI, so you always get file copies in the target path.

From the workspace editor, source-linked deployment is the default, so file copies are not created.

VERIFYING YOUR DEPLOYMENT IS WORKING

To confirm everything is actually wired up correctly:

1. After deploying, check the Deployments panel in the workspace editor. Your deployed resources (jobs, pipelines) should appear under "Bundle resources."
2. Click on a deployed job and inspect its task configuration. The notebook_task path should point to your notebook in its original workspace location.
3. Try running the job. If it executes your notebook successfully, the deployment is working as intended.

IF YOU WANT TO DISABLE SOURCE-LINKED DEPLOYMENT

If you specifically need files to be copied to the deployment root_path (for example, to test exactly what a production deployment would look like), you can disable source-linked deployment by adding this to your dev target configuration:

presets:
source_linked_deployment: false

Your updated target would look like:

targets:
dev:
mode: development
default: true
presets:
source_linked_deployment: false
workspace:
host: https://adb-3960838.18.azuredatabricks.net
root_path: /Workspace/Users/${workspace.current_user.userName}/Data_Lakehouse

With this setting, deploying from the workspace editor will copy files to the root_path, similar to how the CLI behaves.

REGARDING YOUR SPECIFIC QUESTIONS

1. Does development mode skip notebook deployment when running from the Workspace Editor?
Not exactly. Development mode itself does not skip notebooks. It is the source-linked deployment preset (enabled by default in workspace deployments) that skips file copying, because files are referenced in place instead.

2. Should I be using bundle sync instead of bundle deploy?
No. "bundle deploy" is the correct command. "bundle sync" is a lower-level command for syncing files only without deploying resources. When deploying from the workspace editor, deploy handles everything.

3. Is my sync.paths configuration correct?
Your sync.paths configuration looks fine. However, when source-linked deployment is active, the sync.paths setting is effectively bypassed because files are not being copied.

4. Are there limitations when deploying from the Workspace Editor vs. local CLI?
The main difference is source-linked deployment being the default. Workspace deployments also cannot deploy to a different workspace (cross-workspace deployment requires the CLI). Otherwise, the resource deployment behavior is the same.

5. Is this expected behavior when using service principals in development mode?
The service principal configuration (run_as and permissions) does not affect file syncing behavior. The source-linked deployment behavior is the same regardless of run_as settings.

DOCUMENTATION REFERENCES

- Deploying bundles from workspace: https://docs.databricks.com/aws/en/dev-tools/bundles/workspace-deploy
- Authoring bundles in workspace: https://docs.databricks.com/aws/en/dev-tools/bundles/workspace-author
- Bundle deployment modes: https://docs.databricks.com/aws/en/dev-tools/bundles/deployment-modes

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.