Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#7,032 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
go, yaml
Domaine
cli, tooling

Piste de recherche

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.

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

Description

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"
Langage dominant
Go
Étoiles
405
Forks
250
Merge moyen
1 j 11 h
PR mergées (30 j)
236

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.