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

Aberta
  • Algo errado?
#2,431 5 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@andrewnester já está trabalhando nisso.

Desde 8/12/2025.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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

Linguagem predominante
Go
Estrelas
427
Forks
267
Merge médio
2d 1h
PRs com merge (30d)
233

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de databricks/cli

Todas as issues de databricks/cli

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.