Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

databricks/cli issue: strict-mode warning when a group is set at target level and on a job

Aperta
  • Qualcosa non va?
#7,032 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, yaml
Ambito
cli, tooling

Direzione di ricerca

The debug log places the warning after the ApplyBundlePermissions mutator and before FixPermissions; start by reading those entry points and the permission validation described in the issue. Reproduce with the supplied configuration using databricks bundle validate -t dev-ci --strict. Done means maintainers clarify whether permissions can be layered and either stop warning for entries in different layers or make validation and documentation agree.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

DABs

Describe the issue

Declaring the same group in a target's permissions and again in a job's permissions inside that target produces a validation warning. In strict mode that warning is a hard error. The permissions docs describe this layered pattern as supported, with a defined order of precedence, and recommend defining permissions at the top level.

The docs also say a principal cannot appear in both the top-level permissions mapping and within resources. The two statements conflict, and the CLI behavior matches the second one.

Documentation conflict

The Set permissions for resources page (last updated Sep 11, 2026) makes statements that cannot all hold at once.

Section What the page says
Note near the top Permissions cannot overlap: a user, group, or service principal cannot be defined in both the top-level permissions mapping and within resources.
All resources Databricks recommends the top-level permissions mapping for managing bundle resource permissions.
Combined permissions Permissions declared for a resource at the top level are combined with those declared for the same resource in a target.
Order of precedence Lists four levels, from resource-in-target down to top-level. Its example sets test-group at the top level, on a job, and on that job in a target.

The CLI schema doc strings in PR 5664 repeat the no-overlap rule: a principal cannot be set in both a resource's permissions and the top-level permissions mapping.

Workarounds and request

Current workarounds, each with a cost:

  • Declare each principal in one place only. Either drop the group from the target-level permissions, or drop it from the job and accept one level for the whole target. Dropping it from the target level only works if the group has no access to the deployment folder. Otherwise strict mode raises a second warning: "workspace folder has permissions not configured in bundle".
  • If the target-level levels suffice, use one of CAN_VIEW, CAN_MANAGE, or CAN_RUN there and remove the job-level entry.
  • Run validation without strict mode, which loses the gate for every other warning.

Request to maintainers:

  1. Confirm whether the same principal at target level and resource level is supported.
  2. If it is, stop emitting this warning for entries in a different layer.
  3. If it is not, correct the documentation: the recommended-approach text and the order-of-precedence example.

Configuration

The config below is sanitized from the real bundle. The same group is set to CAN_VIEW for the whole target and to CAN_MANAGE_RUN on one job in that target.

bundle:
  name: my-bundle

variables:
  developer_group:
    default: my-developer-group

resources:
  jobs:
    my_job:
      name: my_job
      # tasks omitted

targets:
  dev-ci:
    mode: production
    workspace:
      host: https://<workspace>.cloud.databricks.com
      root_path: /Workspace/<path>/.bundle/my-bundle/dev-ci
    permissions:
      - service_principal_name: <deployment-sp>
        level: CAN_MANAGE
      - group_name: ${var.developer_group}
        level: CAN_VIEW
    resources:
      jobs:
        my_job:
          permissions:
            - user_name: <user>@example.com
              level: CAN_MANAGE
            - group_name: ${var.developer_group}
              level: CAN_MANAGE_RUN

Steps to reproduce the behavior

  1. Save the configuration above as databricks.yml and fill in the placeholders.
  2. Run databricks bundle validate -t dev-ci --strict.
  3. See the warning and the strict-mode error.

Expected Behavior

The permissions docs list an order of precedence for permissions defined in several places, from the resource in the target down to the bundle's top-level permissions. Under that order, a job-level entry in a target should override the target-level entry for the same group without a warning. The docs' own example combines a group at the top level, on a job, and on the same job in a target.

If layering the same principal is not supported, validation should say so clearly, and the docs should stop presenting it as the recommended path.

Actual Behavior

Validation reports one warning naming the group, then fails because strict mode forbids warnings. Output is sanitized except for the message wording and is from v1.20.0; v1.10.0 printed the last line as "Warnings are not allowed in strict mode". In the debug log the warning is printed right after the ApplyBundlePermissions mutator, before FixPermissions.

Warning: 'jobs' already has permissions set for '<developer-group>' group

Name: <bundle-name>
Target: dev-ci
Workspace:
  Host: https://<workspace>.cloud.databricks.com
  User: <service-principal-id>
  Path: /Workspace/<path>/.bundle/<bundle-name>/dev-ci

Found 1 warning
Error: 1 warning was found. Warnings are treated as errors in strict mode

OS and CLI version

  • Databricks CLI version: Databricks CLI v1.20.0 (manually upgraded); also reproduced on v1.10.0 (Docker image)
  • Workspace: AWS
  • Target mode: production
  • Validation run in strict mode, which turns warnings into errors
  • Run in the ghcr.io/databricks/cli:latest Docker image on a self-hosted runner
  • OS: Linux

Is this a regression?

Not known. The warning reproduces on v1.20.0 (installed manually) and on v1.10.0 (the current Docker image).

Debug Logs

Output of databricks bundle validate -t dev-ci --strict --log-level=debug, run on v1.20.0, with sensitive values redacted and unrelated lines omitted (full redacted log can be attached):

[... earlier lines omitted ...]
16:24:08 Debug: Apply pid=58 mutator=ProcessStaticResources mutator=DashboardFixups
16:24:08 Debug: Apply pid=58 mutator=ProcessStaticResources mutator=GenieSpaceFixups
16:24:08 Debug: Apply pid=58 mutator=ProcessStaticResources mutator=ApplyBundlePermissions
Warning: 'jobs' already has permissions set for '<developer-group>' group
16:24:08 Debug: Apply pid=58 mutator=ProcessStaticResources mutator=FixPermissions
16:24:08 Debug: Apply pid=58 mutator=PythonMutator(load_resources)
16:24:08 Debug: Apply pid=58 mutator=PythonMutator(apply_mutators)
[... lines omitted ...]
16:24:08 Debug: Apply pid=58 mutator=CheckPermissions
[... lines omitted ...]
16:24:08 Debug: Apply pid=58 mutator=ValidateSharedRootPermissions
[... lines omitted ...]
16:24:08 Debug: ApplyParallel pid=58 mutator=validate:folder_permissions
[... lines omitted ...]
16:24:08 Debug: Apply pid=58 mutator=ResolveJobRunFileTriggers
Name: <bundle-name>
Target: dev-ci
Workspace:
  Host: https://<workspace>.cloud.databricks.com
  User: <service-principal-id>
  Path: /Workspace/<path>/.bundle/<bundle-name>/dev-ci
Found 1 warning
Error: 1 warning was found. Warnings are treated as errors in strict mode
16:24:08 Info: failed execution pid=58 exit_code=1 error="1 warning was found. Warnings are treated as errors in strict mode"
Lingua principale
Go
Stelle
405
Fork
250
Merge medio
1g 11h
PR unite (30g)
236

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di databricks/cli

Tutte le issue di databricks/cli

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.