`bundle plan` always plans an App update for `config.env` values, because the Apps API does not return them

Aberta
  • Algo errado?
#7,301 1 comentário 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@andrewnester já está trabalhando nisso.

Desde 3/11/2026.

  • #7326 de @andrewnester — aberto

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
cli

Direção de pesquisa

Reproduce with the small bundle in the issue: run databricks bundle deploy -t dev, then databricks bundle plan -t dev -o json, and compare changes for resources.apps.repro against remote_state.config.env. The payload does not name the Go source files involved, so locate the Apps diff logic from there. Done when a plan with unchanged config.env values (plain value and value_from) reports skip, and a real env change still plans an update.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Bug DABs
Describe the issue

For an App with config.env entries, databricks bundle plan plans an update of every config.env[N].value and config.env[N].value_from on every run, with identical old and new values, even immediately after a successful deploy with nothing changed. The live App returned by the Apps API lists each env entry with its name only, so the comparison against the remote state never matches.

Consequences:

  • A bundle containing such an App can never plan clean, so CI checks that gate on "no changes" (or drift detection) always flag it.
  • Every bundle deploy of the plan redeploys and restarts the App, even when nothing changed.
Configuration
bundle:
  name: env-diff-repro

targets:
  dev:
    mode: production
    default: true

resources:
  apps:
    repro:
      name: env-diff-repro
      source_code_path: ./app
      config:
        command: [python, app.py]
        env:
          - name: GREETING
            value: hello

app/app.py is any App that starts, for example a stdlib http.server listening on DATABRICKS_APP_PORT. The same happens with value_from bound to an App resource (we saw it with a postgres resource).

Steps to reproduce
  1. databricks bundle deploy -t dev
  2. databricks bundle plan -t dev -o json, with nothing changed.
Expected behavior

resources.apps.repro plans skip.

Actual behavior
"resources.apps.repro": {
  "action": "update",
  "changes": {
    "config.env[0].value": {"action": "update", "old": "hello", "new": "hello"}
  }
}

and remote_state.config.env is [{"name": "GREETING"}]. Removing env makes the plan clean (skip). Deploying the plan redeploys the App each time.

OS and CLI version
  • Databricks CLI v1.21.0 and v1.23.0 (both reproduce)
  • macOS (arm64); bundle plan -o json writes plan_version 2
Is this a regression?

Unknown.

Debug Logs

Can attach on request.

Linguagem predominante
Go
Estrelas
424
Forks
261
Merge médio
1d 16h
PRs com merge (30d)
224

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.