Skip to content

bundle: reject and hide deployment_id/version_id on jobs and pipelines#5441

Draft
shreyas-goenka wants to merge 1 commit into
mainfrom
dms-deployment-version-guard
Draft

bundle: reject and hide deployment_id/version_id on jobs and pipelines#5441
shreyas-goenka wants to merge 1 commit into
mainfrom
dms-deployment-version-guard

Conversation

@shreyas-goenka
Copy link
Copy Markdown
Contributor

@shreyas-goenka shreyas-goenka commented Jun 4, 2026

Why

deployment_id and version_id on a job/pipeline deployment block are set by the CLI to identify the bundle deployment and its version in the Deployment Metadata Service. They are not user-configurable: a hand-set value would be overwritten at deploy time, and version_id is set anew on every deploy. This PR makes that contract explicit.

What

  • Reject on input. New validate.ValidateDeploymentFields mutator errors if deployment_id or version_id is set on any job or pipeline, pointing at the offending location:

    Error: version_id must not be set in bundle configuration; it is managed by Databricks Asset Bundles
      at resources.jobs.my_job.deployment.version_id
      in databricks.yml:11:21
    
  • New hide_from_plan annotation (direct engine). Adds a lifecycle category that removes a field from the plan diff (display only — it does not by itself decide whether a change is applied). Applied to deployment.version_id for jobs and pipelines. version_id also gets ignore_local_changes + ignore_remote_changes, which are what actually keep its per-deploy churn from driving an update or showing as drift. deployment_id is intentionally left out of all three — it is stable, so it still shows in the plan and a change to it is applied normally.

  • Hide from JSON schema. removeDeploymentFields strips deployment_id/version_id from the generated JSON schema (jobs.JobDeployment / pipelines.PipelineDeployment). apps.AppDeployment.deployment_id is unaffected.

@eng-dev-ecosystem-bot
Copy link
Copy Markdown
Collaborator

eng-dev-ecosystem-bot commented Jun 4, 2026

Commit: 83b7584

Run: 27008464902

@shreyas-goenka shreyas-goenka force-pushed the dms-deployment-version-guard branch 2 times, most recently from 1675d50 to bb53a67 Compare June 4, 2026 14:14
@shreyas-goenka shreyas-goenka force-pushed the dms-deployment-version-guard branch from bb53a67 to b3361d1 Compare June 4, 2026 14:18
@shreyas-goenka shreyas-goenka force-pushed the dms-deployment-version-guard branch from b3361d1 to 5c00e17 Compare June 5, 2026 09:45
@shreyas-goenka shreyas-goenka force-pushed the dms-deployment-version-guard branch from 5c00e17 to d755193 Compare June 5, 2026 09:57
deployment_id and version_id on a job/pipeline deployment block are set by
the CLI to track the bundle deployment in the Deployment Metadata Service.
They are not user-configurable, so this change:

- Errors at validation time if either is set in bundle configuration
  (new validate.ValidateDeploymentFields mutator).
- Adds a hide_from_plan lifecycle annotation to the direct engine that
  removes a field from the plan diff (display only), and applies it to
  deployment.version_id for jobs and pipelines (version_id is set on every
  deploy, so showing it is pure noise). version_id also gets
  ignore_local_changes/ignore_remote_changes, which are what keep its churn
  from driving an update or showing as drift. deployment_id is intentionally
  left to show in the plan.
- Removes deployment_id/version_id from the generated JSON schema.

Co-authored-by: Isaac
@shreyas-goenka shreyas-goenka force-pushed the dms-deployment-version-guard branch from d755193 to 83b7584 Compare June 5, 2026 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants