[Feature Request] Clean up local bundle cache (.databricks folder) when identity or root path is changed

Open
#2,431 5 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@andrewnester is already working on this.

Since Dec 8, 2025.

Assessment

This issue has not been assessed yet.

Description

DABs Enhancement No Autoclose
Describe the issue

I have inhertited a project were bundles are dynamically build in the same folder.

/
/use case a
/use case b
/databricks.yaml.template (includes workflows from a and b dynamically)

during CI/CD
/databicks.yaml (with use case a, job a) is build and deployed
.. later
/databicks.yaml (with use case b, with job b) is build and deployed

I have the feeling that this is too complex and can also be achieved in a static fashion.
I think this also explains why we only see bundle b deployed and not a.

But this non the less raises the question which attributes are used to make the identity of a bundle or more specifically its ressources.

What combination of attributes (source path, target path, bundle name, ...) is used to decide which resources are needed to be deleted, adjusted or created.
Can you please shed some light on it independent of my problem above?

Configuration

See above

Steps to reproduce the behavior
  1. A set of bundles (a, b, c) is dynamically created
  2. After deployment of bundle a, b, c only the workflow c exists, a and b are not there.
Expected Behavior

None so far, only a question. I also haven't found a quick answer in the documentation.

Actual Behavior

Only the last deployed bundle exists. A and b seem to get created and then deleted again - I believe since the mechanisms used identified all three bundles as beeing the same.

OS and CLI version

Databricks CLI v0.238.0

Is this a regression?

No

Debug Logs

could be provided upon request, but will have to be cleaned up

Dominant language
Go
Stars
427
Forks
267
Avg merge
2d 1h
Merged PRs (30d)
233

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/cli

All issues in databricks/cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.