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

Ouverte
  • Quelque chose ne va pas ?
#7,301 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@andrewnester y travaille déjà.

Depuis le 3/11/2026.

  • #7326 par @andrewnester — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go
Domaine
cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Go
Étoiles
424
Forks
261
Merge moyen
1 j 16 h
PR mergées (30 j)
224

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de databricks/cli

Toutes les issues de databricks/cli

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.