Référence de configuration

Cette page fournit des références pour les clés prises en charge par la configuration (YAML) des Declarative Automation Bundles (anciennement connus sous le nom de Databricks Asset Bundles). Consultez Que sont les Declarative Automation Bundles ?

Pour des exemples complets de bundles, consultez les exemples de configurations de bundles et le repository GitHub d'exemples de bundles.

Artefacts

Type: Map

Spécifie les artefacts à créer automatiquement lors des déploiements de bundles, qui peuvent être utilisés ultérieurement lors des exécutions de bundles. Chaque clé est le nom de l'artefact, et la valeur est une carte qui définit les paramètres de création de l'artefact.

astuce

Vous pouvez définir, combiner et remplacer les paramètres des artefacts dans les bundles, comme décrit dans Remplacer par les paramètres cibles.

YAML

artifacts:
  <artifact-name>:
    <artifact-field-name>: <artifact-field-value>

Clé	Type	Description
build	Chaîne	Un ensemble facultatif de commandes de build à exécuter localement avant le déploiement. Pour les builds Python wheel, le Databricks CLI suppose qu'il peut trouver une installation locale du package Python wheel pour exécuter les builds, et il exécute la commande python setup.py bdist_wheel par default lors de chaque déploiement de bundle. Spécifiez plusieurs commandes de build sur des lignes distinctes.
dynamic_version	Booléen	Indique s'il convient de patcher la version de la wheel de manière dynamique en fonction du Timestamp du fichier .whl. Si cette option est définie sur true, un nouveau code peut être déployé sans avoir à mettre à jour la version dans setup.py ou pyproject.toml. Ce paramètre n'est valide que lorsque type est défini sur whl. Ajouté dans la version 0.245.0 de Databricks CLI.
executable	Chaîne	Le type exécutable. Les valeurs possibles sont bash, sh et cmd.
files	Séquence	Le chemin relatif ou absolu vers les fichiers d’artefacts créés. Voir artifacts. name .files.
path	Chaîne	Le chemin local du répertoire pour l'artefact. Les chemins sont relatifs à l'emplacement du fichier de configuration du bundle. Pour les builds Python wheel, il s'agit du chemin d'accès au fichier setup.py du fichier Python wheel. Si path n'est pas inclus, le CLI Databricks tente de trouver le fichier setup.py du fichier Python wheel à la racine du bundle.
type	Chaîne	Requis si l'artefact est un Python wheel. Le type de l'artefact. Les valeurs valides sont whl et jar. Ce paramètre n'a pas besoin d'être spécifié pour créer d'autres artefacts.

Clé	Type	Description
build	Chaîne	Un ensemble facultatif de commandes de build à exécuter localement avant le déploiement. Pour les builds Python wheel, le Databricks CLI suppose qu'il peut trouver une installation locale du package Python wheel pour exécuter les builds, et il exécute la commande python setup.py bdist_wheel par default lors de chaque déploiement de bundle. Spécifiez plusieurs commandes de build sur des lignes distinctes.
dynamic_version	Booléen	Indique s'il convient de patcher la version de la wheel de manière dynamique en fonction du Timestamp du fichier .whl. Si cette option est définie sur true, un nouveau code peut être déployé sans avoir à mettre à jour la version dans setup.py ou pyproject.toml. Ce paramètre n'est valide que lorsque type est défini sur whl. Ajouté dans la version 0.245.0 de Databricks CLI.
executable	Chaîne	Le type exécutable. Les valeurs possibles sont bash, sh et cmd.
files	Séquence	Le chemin relatif ou absolu vers les fichiers d’artefacts créés. Voir artifacts. name .files.
path	Chaîne	Le chemin local du répertoire pour l'artefact. Les chemins sont relatifs à l'emplacement du fichier de configuration du bundle. Pour les builds Python wheel, il s'agit du chemin d'accès au fichier setup.py du fichier Python wheel. Si path n'est pas inclus, le CLI Databricks tente de trouver le fichier setup.py du fichier Python wheel à la racine du bundle.
type	Chaîne	Requis si l'artefact est un Python wheel. Le type de l'artefact. Les valeurs valides sont whl et jar. Ce paramètre n'a pas besoin d'être spécifié pour créer d'autres artefacts.

Exemples

La configuration suivante crée un Python wheel en utilisant Poetry :

YAML

artifacts:
  default:
    type: whl
    build: poetry build
    path: .

La configuration suivante exécute des tests et construit un wheel. Pour un tutoriel complet sur les bundles qui utilise artifacts pour construire un Python wheel, consultez Créer un fichier Python wheel à l'aide de Declarative Automation Bundles.

YAML

artifacts:
  default:
    type: whl
    build: |-
      # run tests
      python -m pytest tests/ -v

      # build the actual artifact
      python setup.py bdist_wheel

    path: .

Pour une configuration exemple qui construit un JAR et l'importe dans Unity Catalog, consultez Bundle qui upload un fichier JAR dans Unity Catalog.

artifacts. name .fichiers

Type: Sequence

Le chemin relatif ou absolu vers les fichiers d’artefacts créés. Utilisez source pour spécifier les artefacts créés. Les chemins sont relatifs à l'emplacement du fichier de configuration du bundle.

Clé	Type	Description
source	Chaîne	Obligatoire. Le fichier source de l'artefact.

Clé	Type	Description
source	Chaîne	Obligatoire. Le fichier source de l'artefact.

bundle

Type: Map

Les attributs du bundle lors du déploiement vers cette cible.

Un fichier de configuration de bundle doit contenir un seul mappage bundle de niveau supérieur.

Ce mappage bundle doit contenir un mappage name qui spécifie un nom programmatique (ou logique) pour l'ensemble. L'exemple suivant déclare un bundle avec le nom programmatique (ou logique) hello-bundle.

YAML

bundle:
  name: hello-bundle

Un mappage bundle peut également être un enfant d'une ou plusieurs des cibles dans le mappage cibles de niveau supérieur. Chacun de ces mappages enfants bundle spécifie tout remplacement non-default au niveau de la cible.

Clé	Type	Description
cluster_id	Chaîne	L'ID d'un cluster à utiliser pour exécuter le bundle. Cette clé vous permet de spécifier l'ID d'un cluster à utiliser comme remplacement pour les clusters définis ailleurs dans le fichier de configuration du bundle. Pour des informations sur la manière de récupérer l'ID d'un cluster, consultez URL et ID de ressource de compute. Le remplacement cluster_id est destiné aux scénarios de développement uniquement et n'est pris en charge que pour la cible dont le mappage mode est défini sur development. Pour plus d'informations sur le mappage target, consultez les cibles.
compute_id	Chaîne	Obsolète. L'ID du compute à utiliser pour exécuter le bundle.
databricks_cli_version	Chaîne	La version de l'interface de ligne de commande Databricks à utiliser pour le bundle. Voir bundle.databricks_cli_version.
deployment	Carte	La définition du déploiement du bundle. Pour les attributs pris en charge, consultez Modes de déploiement des Declarative Automation Bundles. Consultez bundle.deployment.
engine	Chaîne	Le moteur de déploiement à utiliser. Les valeurs valides sont terraform et direct. La valeur par default est terraform. Cette configuration a priorité sur la variable d'environnement DATABRICKS_BUNDLE_ENGINE. Pour plus d'informations sur le moteur de déploiement direct, consultez Migrer vers le moteur de déploiement direct. Ajouté dans la version 0.295.0 de Databricks CLI.
git	Carte	Les détails du contrôle de version Git qui sont associés à votre offre groupée. Pour les attributs pris en charge, consultez Git.
name	Chaîne	Le nom du bundle.
uuid	Chaîne	Réservé. Un identifiant unique universel (UUID) pour le bundle qui identifie de manière unique le bundle dans les systèmes internes de Databricks. Ceci est généré lorsqu'un projet de bundle est initialisé à l'aide d'un Template Databricks (en utilisant la commande databricks bundle init). Ajouté dans la version 0.236.0 de la CLI Databricks

Clé	Type	Description
cluster_id	Chaîne	L'ID d'un cluster à utiliser pour exécuter le bundle. Cette clé vous permet de spécifier l'ID d'un cluster à utiliser comme remplacement pour les clusters définis ailleurs dans le fichier de configuration du bundle. Pour des informations sur la manière de récupérer l'ID d'un cluster, consultez URL et ID de ressource de compute. Le remplacement cluster_id est destiné aux scénarios de développement uniquement et n'est pris en charge que pour la cible dont le mappage mode est défini sur development. Pour plus d'informations sur le mappage target, consultez les cibles.
compute_id	Chaîne	Obsolète. L'ID du compute à utiliser pour exécuter le bundle.
databricks_cli_version	Chaîne	La version de l'interface de ligne de commande Databricks à utiliser pour le bundle. Voir bundle.databricks_cli_version.
deployment	Carte	La définition du déploiement du bundle. Pour les attributs pris en charge, consultez Modes de déploiement des Declarative Automation Bundles. Consultez bundle.deployment.
engine	Chaîne	Le moteur de déploiement à utiliser. Les valeurs valides sont terraform et direct. La valeur par default est terraform. Cette configuration a priorité sur la variable d'environnement DATABRICKS_BUNDLE_ENGINE. Pour plus d'informations sur le moteur de déploiement direct, consultez Migrer vers le moteur de déploiement direct. Ajouté dans la version 0.295.0 de Databricks CLI.
git	Carte	Les détails du contrôle de version Git qui sont associés à votre offre groupée. Pour les attributs pris en charge, consultez Git.
name	Chaîne	Le nom du bundle.
uuid	Chaîne	Réservé. Un identifiant unique universel (UUID) pour le bundle qui identifie de manière unique le bundle dans les systèmes internes de Databricks. Ceci est généré lorsqu'un projet de bundle est initialisé à l'aide d'un Template Databricks (en utilisant la commande databricks bundle init). Ajouté dans la version 0.236.0 de la CLI Databricks

bundle.databricks_cli_version

Le mappage bundle peut contenir un mappage databricks_cli_version qui contraint la version de Databricks CLI requise par le bundle. Cela peut éviter les problèmes causés par l'utilisation de mappages non pris en charge dans une certaine version de Databricks CLI.

La version de Databricks CLI est conforme à la gestion sémantique des versions et le mappage databricks_cli_version prend en charge la spécification de contraintes de version. Si la valeur actuelle de databricks --version ne se trouve pas dans les limites spécifiées dans le mappage databricks_cli_version du bundle, une erreur se produit lorsque databricks bundle validate est exécuté sur le bundle. Les exemples suivants présentent quelques syntaxes courantes de contraintes de version :

YAML

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.0' # require Databricks CLI 0.218.0

YAML

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.*' # allow all patch versions of Databricks CLI 0.218

YAML

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0' # allow any version of Databricks CLI 0.218.0 or higher

YAML

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0, <= 1.0.0' # allow any Databricks CLI version between 0.218.0 and 1.0.0, inclusive

bundle.deployment

Type: Map

La définition du déploiement du bundle

Clé	Type	Description
fail_on_active_runs	Booléen	Échec des exécutions actives. Si cette option est définie sur vrai, un déploiement en cours d'exécution peut être interrompu.
lock	Carte	Les attributs de verrouillage de déploiement. Consultez bundle.deployment.lock.

Clé	Type	Description
fail_on_active_runs	Booléen	Échec des exécutions actives. Si cette option est définie sur vrai, un déploiement en cours d'exécution peut être interrompu.
lock	Carte	Les attributs de verrouillage de déploiement. Consultez bundle.deployment.lock.

bundle.deployment.lock

Type: Map

Les attributs du verrou de déploiement.

Clé	Type	Description
enabled	Booléen	Si ce verrou est activé.
force	Booléen	Faut-il forcer ce verrou s'il est activé ?

Clé	Type	Description
enabled	Booléen	Si ce verrou est activé.
force	Booléen	Faut-il forcer ce verrou s'il est activé ?

Expérimental

Type: Map

Définit les attributs pour les fonctionnalités expérimentales.

Clé	Type	Description
python	Carte	Obsolète. Utilisez la correspondance python de niveau supérieur à la place. Ajouté dans la version 0.238.0 de Databricks CLI.
python_wheel_wrapper	Booléen	Faut-il utiliser un encapsuleur Python wheel.
record_deployment_history	Booléen	Enregistrer l'historique de déploiement du bundle.
scripts	Carte	Les commandes à exécuter.
skip_artifact_cleanup	Booléen	Détermine s'il faut ignorer la suppression du dossier .internal dans workspace.artifact_path. Par default, ce dossier est supprimé avant l'upload de nouveaux artefacts de build (tels que les wheels Python) pendant le déploiement. Définir sur true pour conserver les artefacts existants entre les déploiements. Ajouté dans la version 0.254.0 de Databricks CLI
skip_name_prefix_for_schema	Booléen	Ignorer l'ajout du préfixe (défini dans presets.name_prefix ou calculé lorsque mode: development) aux noms des schémas Unity Catalog définis dans le bundle. Ajouté dans la version 0.255.0 de Databricks CLI.
use_legacy_run_as	Booléen	S’il faut utiliser l’ancien comportement d’exécution.

Clé	Type	Description
python	Carte	Obsolète. Utilisez la correspondance python de niveau supérieur à la place. Ajouté dans la version 0.238.0 de Databricks CLI.
python_wheel_wrapper	Booléen	Faut-il utiliser un encapsuleur Python wheel.
record_deployment_history	Booléen	Enregistrer l'historique de déploiement du bundle.
scripts	Carte	Les commandes à exécuter.
skip_artifact_cleanup	Booléen	Détermine s'il faut ignorer la suppression du dossier .internal dans workspace.artifact_path. Par default, ce dossier est supprimé avant l'upload de nouveaux artefacts de build (tels que les wheels Python) pendant le déploiement. Définir sur true pour conserver les artefacts existants entre les déploiements. Ajouté dans la version 0.254.0 de Databricks CLI
skip_name_prefix_for_schema	Booléen	Ignorer l'ajout du préfixe (défini dans presets.name_prefix ou calculé lorsque mode: development) aux noms des schémas Unity Catalog définis dans le bundle. Ajouté dans la version 0.255.0 de Databricks CLI.
use_legacy_run_as	Booléen	S’il faut utiliser l’ancien comportement d’exécution.

inclure

Type: Sequence

Spécifie une liste de globs de chemins qui contiennent les fichiers de configuration à inclure dans le bundle. Ces globs de chemins sont relatifs à l’emplacement du fichier de configuration de bundle dans lequel les globs de chemins sont spécifiés. Hormis databricks.yml, vous devez utiliser le tableau include pour spécifier tous les fichiers de configuration à inclure dans le bundle.

astuce

Pour inclure ou exclure d'autres fichiers dans le paquet, utilisez les options inclure et exclure.

Ce tableau include ne peut apparaître que comme un mappage de niveau supérieur.

L'exemple de configuration suivant inclut trois fichiers de configuration. Ces fichiers se trouvent dans le même dossier que le fichier de configuration du bundle :

YAML

include:
  - 'bundle.artifacts.yml'
  - 'bundle.resources.yml'
  - 'bundle.targets.yml'

La configuration d'exemple suivante inclut tous les fichiers dont les noms de fichier commencent par bundle et se terminent par .yml. Ces fichiers se trouvent dans le même dossier que le fichier de configuration du bundle :

YAML

include:
  - 'bundle*.yml'

autorisations

Type: Sequence

Définit les autorisations à appliquer aux ressources définies dans le bundle, où chaque élément de la séquence est une autorisation pour une entité spécifique. Consultez Définir les autorisations pour les ressources dans les Declarative Automation Bundles.

Les niveaux d'autorisation de haut niveau autorisés sont CAN_VIEW, CAN_MANAGE et CAN_RUN.

Si vous souhaitez appliquer des autorisations à une ressource spécifique, consultez Définir des autorisations pour une ressource spécifique.

Clé	Type	Description
group_name	Chaîne	Le nom du groupe qui dispose de l'ensemble d'autorisations défini à ce niveau.
level	Chaîne	L'autorisation accordée pour l'utilisateur, le groupe, le Service Principal définie pour cette autorisation. Les valeurs valides pour cette clé sont différentes selon que les autorisations sont définies au niveau supérieur du bundle ou pour une ressource spécifique. Consultez Définir les autorisations pour les ressources dans Declarative Automation Bundles.
service_principal_name	Chaîne	Le nom du Service Principal qui a l'autorisation définie dans le niveau.
user_name	Chaîne	Le nom de l'utilisateur qui a l'ensemble d'autorisations défini au niveau.

Clé	Type	Description
group_name	Chaîne	Le nom du groupe qui dispose de l'ensemble d'autorisations défini à ce niveau.
level	Chaîne	L'autorisation accordée pour l'utilisateur, le groupe, le Service Principal définie pour cette autorisation. Les valeurs valides pour cette clé sont différentes selon que les autorisations sont définies au niveau supérieur du bundle ou pour une ressource spécifique. Consultez Définir les autorisations pour les ressources dans Declarative Automation Bundles.
service_principal_name	Chaîne	Le nom du Service Principal qui a l'autorisation définie dans le niveau.
user_name	Chaîne	Le nom de l'utilisateur qui a l'ensemble d'autorisations défini au niveau.

Exemple

La configuration d'exemple suivante définit les niveaux d'autorisation pour un utilisateur, un groupe et un Service Principal, qui sont appliqués à toutes les Ressources définies dans resources dans le bundle :

YAML

permissions:
  - level: CAN_VIEW
    group_name: test-group
  - level: CAN_MANAGE
    user_name: someone@example.com
  - level: CAN_RUN
    service_principal_name: 123456-abcdef

Préréglages

Type: Map

Définit les préréglages de déploiement de bundle. Pour plus d'information, consultez Préréglages personnalisés.

À moins qu'une exception ne soit spécifiée pour un préréglage, si mode et presets sont définis, les préréglages remplacent le comportement du mode par default, et les paramètres des ressources individuelles remplacent les préréglages.

Préréglage	Description
artifacts_dynamic_version	Indique s'il faut mettre à jour dynamiquement la version des artefacts whl pendant le déploiement. Les valeurs valides sont true ou false. Si le paramètre de configuration artifacts.dynamic_version de niveau supérieur est spécifié, il remplace ce préréglage. Ajouté dans la version 0.256.0 de Databricks CLI
jobs_max_concurrent_runs	Le nombre maximal d'exécutions simultanées autorisées pour les Jobs.
name_prefix	La chaîne de préfixe à ajouter en préfixe aux noms de ressources.
pipelines_development	Si les déploiements de pipeline doivent être verrouillés en mode développement. Les valeurs valides sont true ou false.
source_linked_deployment	Si les ressources créées lors du déploiement pointent vers des fichiers source dans le workspace au lieu de leurs copies de workspace. Ajouté dans la version 0.236.0 de la CLI Databricks
tags	Un ensemble de clés tags qui s'appliquent à toutes les ressources qui prennent en charge les tags, ce qui inclut les jobs et les expérimentations. Les Declarative Automation Bundles ne prennent pas en charge les tags pour la ressource schema.
trigger_pause_status	Un statut de pause à appliquer à tous les Trigger et plannings. Les valeurs valides sont PAUSED ou UNPAUSED. Si mode est défini sur development, trigger_pause_status est toujours PAUSED.

Préréglage	Description
artifacts_dynamic_version	Indique s'il faut mettre à jour dynamiquement la version des artefacts whl pendant le déploiement. Les valeurs valides sont true ou false. Si le paramètre de configuration artifacts.dynamic_version de niveau supérieur est spécifié, il remplace ce préréglage. Ajouté dans la version 0.256.0 de Databricks CLI
jobs_max_concurrent_runs	Le nombre maximal d'exécutions simultanées autorisées pour les Jobs.
name_prefix	La chaîne de préfixe à ajouter en préfixe aux noms de ressources.
pipelines_development	Si les déploiements de pipeline doivent être verrouillés en mode développement. Les valeurs valides sont true ou false.
source_linked_deployment	Si les ressources créées lors du déploiement pointent vers des fichiers source dans le workspace au lieu de leurs copies de workspace. Ajouté dans la version 0.236.0 de la CLI Databricks
tags	Un ensemble de clés tags qui s'appliquent à toutes les ressources qui prennent en charge les tags, ce qui inclut les jobs et les expérimentations. Les Declarative Automation Bundles ne prennent pas en charge les tags pour la ressource schema.
trigger_pause_status	Un statut de pause à appliquer à tous les Trigger et plannings. Les valeurs valides sont PAUSED ou UNPAUSED. Si mode est défini sur development, trigger_pause_status est toujours PAUSED.

Python

Type: Map

Configure le chargement du code Python défini avec le package databricks-bundles. Pour plus d'informations, consultez Configuration de bundle en Python.

Déplacé de experimental dans la version 0.275.0 de la CLI Databricks

Clé	Type	Description
mutators	Séquence	Les mutateurs contiennent une liste de chemins de fonctions entièrement qualifiés vers les fonctions mutateur, tels que [my_project.mutators:add_default_cluster]. Ajouté dans la version 0.238.0 de Databricks CLI.
resources	Séquence	Ressources contient une liste de chemins de fonctions entièrement qualifiés pour charger les ressources définies dans le code Python, tels que ["my_project.resources:load_resources"] Ajouté dans la version 0.238.0 de Databricks CLI.
venv_path	Chaîne	Le chemin vers l'environnement virtuel. Si activé, le code Python s'exécute dans cet environnement. Si désactivé, il utilise par default l'interpréteur Python disponible dans le Shell actuel. Ajouté dans la version 0.238.0 de Databricks CLI.

Clé	Type	Description
mutators	Séquence	Les mutateurs contiennent une liste de chemins de fonctions entièrement qualifiés vers les fonctions mutateur, tels que [my_project.mutators:add_default_cluster]. Ajouté dans la version 0.238.0 de Databricks CLI.
resources	Séquence	Ressources contient une liste de chemins de fonctions entièrement qualifiés pour charger les ressources définies dans le code Python, tels que ["my_project.resources:load_resources"] Ajouté dans la version 0.238.0 de Databricks CLI.
venv_path	Chaîne	Le chemin vers l'environnement virtuel. Si activé, le code Python s'exécute dans cet environnement. Si désactivé, il utilise par default l'interpréteur Python disponible dans le Shell actuel. Ajouté dans la version 0.238.0 de Databricks CLI.

Ressources

Type: Map

Définit les ressources du bundle, où chaque clé est le nom de la ressource, et la valeur est une carte qui définit la ressource. Pour plus d'informations sur les ressources prises en charge par les Declarative Automation Bundles et la référence de définition des ressources, consultez Ressources des Declarative Automation Bundles.

Le mappage resources peut apparaître comme un mappage de niveau supérieur, ou il peut être un enfant d'une ou plusieurs des cibles dans le mappage cibles de niveau supérieur, et inclut zéro ou un des types de ressources pris en charge. Chaque mappage de type de ressource comprend une ou plusieurs déclarations de ressources individuelles, chacune devant avoir un nom unique. Ces déclarations de Ressources individuelles utilisent la charge utile de requête de l'Opération de création de l'objet correspondant, exprimée en YAML, pour définir la Ressource. Les propriétés prises en charge pour une Ressource sont les champs pris en charge de l'objet correspondant.

Les charges utiles des requêtes d’opération de création sont documentées dans la Référence de l'API REST Databricks, et la commande databricks bundle schema affiche tous les schémas d'objets pris en charge. De plus, la commande databricks bundle validate renvoie des avertissements si des propriétés de ressource inconnues sont trouvées dans les fichiers de configuration du bundle.

Pour plus d'informations sur les ressources prises en charge dans les bundles, ainsi que sur la configuration courante et des exemples, consultez les Ressources sur les bundles d'automatisation déclarative et les Exemples de configuration de bundles.

YAML

resources:
  <resource-type>:
    <resource-name>:
      <resource-field-name>: <resource-field-value>

Clé	Type	Description
alerts	Carte	Les définitions d'alerte (v2) pour le lot, où chaque clé est le nom de l'alerte. Voir alerte. Ajouté dans la version 0,279.0 de Databricks CLI
apps	Carte	Les définitions d'applications Databricks pour le bundle, où chaque clé est le nom de l'application. Consultez l'application. Ajouté dans la version 0.239.0 de Databricks CLI
catalogs	Carte	Les définitions de catalogue (Unity Catalog) pour le bundle, où chaque clé est le nom d'un catalogue. Voir les catalogues. Ajouté dans la version 0.287.0 de la CLI Databricks
clusters	Carte	Les définitions de cluster pour le bundle, où chaque clé est le nom d'un cluster. See clusters.
dashboards	Carte	Les définitions de tableau de bord pour le bundle, où chaque clé est le nom du tableau de bord. Voir le tableau de bord. Ajouté dans la version 0.232.0 de la CLI Databricks
database_catalogs	Carte	Les définitions du catalogue de bases de données pour le bundle, où chaque clé est le nom du catalogue de bases de données. Voir database_catalog. Ajouté dans la version 0.265.0 de Databricks CLI
database_instances	Carte	Les définitions d'instances de base de données pour le bundle, où chaque clé est le nom de l'instance de base de données. Voir l'instance de base de données. Ajouté dans la version 0.265.0 de Databricks CLI
experiments	Carte	Les définitions d'expérience pour le bundle, où chaque clé est le nom de l'expérience. See Experimentation.
external_locations	Carte	Les définitions d'emplacement externe pour le bundle, où chaque clé est le nom de l'emplacement. Voir external_location (Unity Catalog). Ajouté dans la CLI Databricks version 0.289.0
genie_spaces	Carte	Les définitions d'agent Genie pour le bundle, où chaque clé est le nom de l'agent Genie. Voir espace_genie. Ajouté à la version 1,3,0 de Databricks CLI
jobs	Carte	Les définitions du job pour le bundle, où chaque clé est le nom du job. See Job.
model_serving_endpoints	Carte	Les définitions d'Endpoint de service de modèle pour le bundle, où chaque clé est le nom de l'Endpoint de service de modèle. Voir endpoint de service de modèle.
models	Carte	Les définitions de modèle pour le bundle, où chaque clé est le nom du modèle. Consultez modèle (hérité).
pipelines	Carte	Les définitions de pipeline pour le bundle, où chaque clé est le nom du pipeline. See pipeline.
postgres_branches	Carte	Les définitions de Branch Postgres pour le bundle, où chaque clé est le nom de la Branch Lakebase. Voir branche Postgres. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_catalogs	Carte	Les définitions de catalogue Postgres pour le bundle, où chaque clé est le nom du catalogue. Voir postgres_catalog. Ajouté dans la version 1.0.0 de Databricks CLI
postgres_databases	Carte	Les définitions de base de données Postgres pour le bundle, où chaque clé est le nom de la base de données. Voir postgres_database. Ajouté dans la version 1.4.0 de Databricks CLI
postgres_endpoints	Carte	Les définitions d'Endpoint Postgres pour le bundle, où chaque clé est le nom de l'Endpoint compute Lakebase. Voir postgres_endpoint. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_projects	Carte	Les définitions de projet Postgres pour le bundle, où chaque clé est le nom du projet Lakebase. Voir postgres_project. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_roles	Carte	Les définitions de rôle Postgres pour le bundle, où chaque clé est le nom du rôle. Consultez postgres_role. Ajouté dans la version 1.4.0 de Databricks CLI
postgres_synced_tables	Carte	Les définitions de table synchronisée Postgres pour le bundle, où chaque clé est le nom de la table synchronisée. Voir postgres_synced_table. Ajouté dans la version 1.0.0 de Databricks CLI
quality_monitors	Carte	Les définitions des moniteurs de qualité pour le bundle, où chaque clé est le nom du moniteur de qualité. Consultez quality_monitor (Unity Catalog).
registered_models	Carte	Les définitions de modèle enregistré pour le bundle, où chaque clé est le nom du modèle enregistré dans Unity Catalog. Consultez registered_model (Unity Catalog).
schemas	Carte	Les définitions de schéma pour le package, où chaque clé est le nom du schéma. Consultez le schéma (Unity Catalog).
secret_scopes	Carte	Les définitions de Secret Scope pour le bundle, où chaque clé est le nom du Secret Scope. Voir secret_scope. Ajouté dans la version 0.252.0 de la CLI Databricks
sql_warehouses	Carte	Les définitions de SQL Warehouse pour le bundle, où chaque clé est le nom du SQL Warehouse. Voir sql_warehouse. Ajouté dans la CLI Databricks version 0.260.0
synced_database_tables	Carte	Les définitions des tables de base de données synchronisées pour le bundle, où chaque clé est le nom de la table de base de données. Voir synced_database_table. Ajouté dans Databricks CLI version 0,266.0
vector_search_endpoints	Carte	Les définitions d'endpoint de recherche IA pour le bundle, où chaque clé est le nom de l'endpoint de recherche IA. Voir vector_search_endpoint. Ajouté dans Databricks CLI version 0.298.0
vector_search_indexes	Carte	Les définitions d’index de recherche vectorielle du bundle, où chaque clé est le nom de l’index de recherche vectorielle. Voir vector_search_index. Ajouté dans la version 1.1.0 de la CLI Databricks.
volumes	Carte	Les définitions de volume pour le bundle, où chaque clé est le nom du volume. Consulter le volume (Unity Catalog). Ajouté dans la version 0.236.0 de la CLI Databricks

Clé	Type	Description
alerts	Carte	Les définitions d'alerte (v2) pour le lot, où chaque clé est le nom de l'alerte. Voir alerte. Ajouté dans la version 0,279.0 de Databricks CLI
apps	Carte	Les définitions d'applications Databricks pour le bundle, où chaque clé est le nom de l'application. Consultez l'application. Ajouté dans la version 0.239.0 de Databricks CLI
catalogs	Carte	Les définitions de catalogue (Unity Catalog) pour le bundle, où chaque clé est le nom d'un catalogue. Voir les catalogues. Ajouté dans la version 0.287.0 de la CLI Databricks
clusters	Carte	Les définitions de cluster pour le bundle, où chaque clé est le nom d'un cluster. See clusters.
dashboards	Carte	Les définitions de tableau de bord pour le bundle, où chaque clé est le nom du tableau de bord. Voir le tableau de bord. Ajouté dans la version 0.232.0 de la CLI Databricks
database_catalogs	Carte	Les définitions du catalogue de bases de données pour le bundle, où chaque clé est le nom du catalogue de bases de données. Voir database_catalog. Ajouté dans la version 0.265.0 de Databricks CLI
database_instances	Carte	Les définitions d'instances de base de données pour le bundle, où chaque clé est le nom de l'instance de base de données. Voir l'instance de base de données. Ajouté dans la version 0.265.0 de Databricks CLI
experiments	Carte	Les définitions d'expérience pour le bundle, où chaque clé est le nom de l'expérience. See Experimentation.
external_locations	Carte	Les définitions d'emplacement externe pour le bundle, où chaque clé est le nom de l'emplacement. Voir external_location (Unity Catalog). Ajouté dans la CLI Databricks version 0.289.0
genie_spaces	Carte	Les définitions d'agent Genie pour le bundle, où chaque clé est le nom de l'agent Genie. Voir espace_genie. Ajouté à la version 1,3,0 de Databricks CLI
jobs	Carte	Les définitions du job pour le bundle, où chaque clé est le nom du job. See Job.
model_serving_endpoints	Carte	Les définitions d'Endpoint de service de modèle pour le bundle, où chaque clé est le nom de l'Endpoint de service de modèle. Voir endpoint de service de modèle.
models	Carte	Les définitions de modèle pour le bundle, où chaque clé est le nom du modèle. Consultez modèle (hérité).
pipelines	Carte	Les définitions de pipeline pour le bundle, où chaque clé est le nom du pipeline. See pipeline.
postgres_branches	Carte	Les définitions de Branch Postgres pour le bundle, où chaque clé est le nom de la Branch Lakebase. Voir branche Postgres. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_catalogs	Carte	Les définitions de catalogue Postgres pour le bundle, où chaque clé est le nom du catalogue. Voir postgres_catalog. Ajouté dans la version 1.0.0 de Databricks CLI
postgres_databases	Carte	Les définitions de base de données Postgres pour le bundle, où chaque clé est le nom de la base de données. Voir postgres_database. Ajouté dans la version 1.4.0 de Databricks CLI
postgres_endpoints	Carte	Les définitions d'Endpoint Postgres pour le bundle, où chaque clé est le nom de l'Endpoint compute Lakebase. Voir postgres_endpoint. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_projects	Carte	Les définitions de projet Postgres pour le bundle, où chaque clé est le nom du projet Lakebase. Voir postgres_project. Ajouté dans la version 0.287.0 de la CLI Databricks
postgres_roles	Carte	Les définitions de rôle Postgres pour le bundle, où chaque clé est le nom du rôle. Consultez postgres_role. Ajouté dans la version 1.4.0 de Databricks CLI
postgres_synced_tables	Carte	Les définitions de table synchronisée Postgres pour le bundle, où chaque clé est le nom de la table synchronisée. Voir postgres_synced_table. Ajouté dans la version 1.0.0 de Databricks CLI
quality_monitors	Carte	Les définitions des moniteurs de qualité pour le bundle, où chaque clé est le nom du moniteur de qualité. Consultez quality_monitor (Unity Catalog).
registered_models	Carte	Les définitions de modèle enregistré pour le bundle, où chaque clé est le nom du modèle enregistré dans Unity Catalog. Consultez registered_model (Unity Catalog).
schemas	Carte	Les définitions de schéma pour le package, où chaque clé est le nom du schéma. Consultez le schéma (Unity Catalog).
secret_scopes	Carte	Les définitions de Secret Scope pour le bundle, où chaque clé est le nom du Secret Scope. Voir secret_scope. Ajouté dans la version 0.252.0 de la CLI Databricks
sql_warehouses	Carte	Les définitions de SQL Warehouse pour le bundle, où chaque clé est le nom du SQL Warehouse. Voir sql_warehouse. Ajouté dans la CLI Databricks version 0.260.0
synced_database_tables	Carte	Les définitions des tables de base de données synchronisées pour le bundle, où chaque clé est le nom de la table de base de données. Voir synced_database_table. Ajouté dans Databricks CLI version 0,266.0
vector_search_endpoints	Carte	Les définitions d'endpoint de recherche IA pour le bundle, où chaque clé est le nom de l'endpoint de recherche IA. Voir vector_search_endpoint. Ajouté dans Databricks CLI version 0.298.0
vector_search_indexes	Carte	Les définitions d’index de recherche vectorielle du bundle, où chaque clé est le nom de l’index de recherche vectorielle. Voir vector_search_index. Ajouté dans la version 1.1.0 de la CLI Databricks.
volumes	Carte	Les définitions de volume pour le bundle, où chaque clé est le nom du volume. Consulter le volume (Unity Catalog). Ajouté dans la version 0.236.0 de la CLI Databricks

Exemple

La configuration d'exemple suivante définit une ressource de Job :

YAML

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

run_as

Type: Map

L'identité (user_name ou service_principal_name) à utiliser pour exécuter les ressources Declarative Automation Bundles. Il offre la possibilité de séparer l'identité utilisée pour déployer un bundle job ou un pipeline de celle utilisée pour exécuter le job ou le pipeline. Consultez Spécifier une identité d'exécution pour un flux de travail Declarative Automation Bundles.

Clé	Type	Description
service_principal_name	Chaîne	L'ID d'application d'un Service Principal actif. La configuration de ce champ nécessite le rôle servicePrincipal/user.
user_name	Chaîne	L'e-mail d'un utilisateur de Workspace actif. Les utilisateurs non-administrateurs peuvent uniquement définir ce champ sur leur propre e-mail.

Clé	Type	Description
service_principal_name	Chaîne	L'ID d'application d'un Service Principal actif. La configuration de ce champ nécessite le rôle servicePrincipal/user.
user_name	Chaîne	L'e-mail d'un utilisateur de Workspace actif. Les utilisateurs non-administrateurs peuvent uniquement définir ce champ sur leur propre e-mail.

scripts

Type: Map

Les scripts qui peuvent être exécutés à l'aide de bundle run. Chaque script nommé dans le mappage scripts contient du contenu avec des commandes. Voir Exécuter les scripts.

Ajouté dans la version 0.259.0 de la CLI Databricks

YAML

scripts:
  <script-name>:
    <script-field-name>: <script-field-value>

Clé	Type	Description
content	Chaîne	Les commandes à exécuter Ajouté dans la version 0.259.0 de la CLI Databricks

Clé	Type	Description
content	Chaîne	Les commandes à exécuter Ajouté dans la version 0.259.0 de la CLI Databricks

Exemples

YAML

scripts:
  my_script:
    content: uv run pytest -m dev

synchroniser

Type: Map

Les fichiers et chemins d'accès aux fichiers à inclure ou à exclure dans le bundle.

Clé	Type	Description
exclude	Séquence	Une liste de fichiers ou de dossiers à exclure du bundle. Voir inclure et exclure.
include	Séquence	Une liste de fichiers ou de dossiers à inclure dans le bundle. Voir inclure et exclure.
paths	Séquence	Les chemins des dossiers locaux, qui peuvent se trouver en dehors de la racine du bundle, à synchroniser avec le workspace lorsque le bundle est déployé. Voir sync.paths.

Clé	Type	Description
exclude	Séquence	Une liste de fichiers ou de dossiers à exclure du bundle. Voir inclure et exclure.
include	Séquence	Une liste de fichiers ou de dossiers à inclure dans le bundle. Voir inclure et exclure.
paths	Séquence	Les chemins des dossiers locaux, qui peuvent se trouver en dehors de la racine du bundle, à synchroniser avec le workspace lorsque le bundle est déployé. Voir sync.paths.

inclure et exclure

Les mappages include et exclude dans le mappage sync spécifient une liste de fichiers ou de dossiers à inclure ou à exclure des déploiements de bundles, en fonction des règles suivantes :

• Selon toute liste de fichiers et de chemins de type glob dans un fichier .gitignore à la racine du bundle, le mappage include peut contenir une liste de fichiers de type glob, de chemins de type glob ou les deux, par rapport à la racine du bundle, à inclure explicitement.
• En fonction de toute liste de fichiers et de chemins d'accès globaux dans un fichier .gitignore à la racine du bundle, plus la liste de fichiers et de chemins d'accès globaux dans le mappage include, le mappage exclude peut contenir une liste de fichiers globaux, de chemins d'accès globaux, ou les deux, par rapport à la racine du bundle, à exclure explicitement.

Tous les chemins vers les fichiers et dossiers spécifiés sont relatifs à l'emplacement du fichier de configuration du bundle dans lequel ils sont spécifiés.

La syntaxe des modèles de fichiers et de chemins include et exclude suit la syntaxe de modèle standard .gitignore. Voir format de modèle gitignore.

Par exemple, si le fichier .gitignore suivant contient les entrées suivantes :

.databricks
my_package/dist

Et le fichier de configuration du bundle contient le mappage include suivant :

YAML

sync:
  include:
    - my_package/dist/*.whl

Ensuite, tous les fichiers du dossier my_package/dist avec une extension de fichier *.whl sont inclus. Tous les autres fichiers du dossier my_package/dist ne sont pas inclus.

Toutefois, si le fichier de configuration du bundle contient également le mappage exclude suivant :

YAML

sync:
  include:
    - my_package/dist/*.whl
  exclude:
    - my_package/dist/delete-me.whl

Ensuite, tous les fichiers du dossier my_package/dist avec une extension de fichier *.whl, à l'exception du fichier nommé delete-me.whl, sont inclus. Tout autre fichier dans le dossier my_package/dist n'est pas non plus inclus.

Le mappage sync peut également être déclaré dans le mappage targets pour une cible spécifique. Tout mappage sync déclaré dans une cible est fusionné avec toutes les déclarations de mappage sync de niveau supérieur. Par exemple, en continuant avec l'exemple précédent, le mappage include au niveau targets fusionne avec le mappage include dans le mappage sync de niveau supérieur :

YAML

targets:
  dev:
    sync:
      include:
        - my_package/dist/delete-me.whl

remarque

Les modèles include et exclude filtrent uniquement les fichiers trouvés dans les dossiers listés dans sync.paths. Il n'est pas possible d'ajouter des fichiers à partir d'un dossier qu'aucun chemin de synchronisation ne couvre. Parce que paths est par default la racine du bundle (.), include et exclude s'appliquent à l'ensemble de la racine du bundle à moins que vous ne restreigniez paths.

sync.paths

Le mappage sync peut contenir un mappage paths qui spécifie les chemins locaux à synchroniser avec le workspace. Le mappage paths vous permet de partager des fichiers courants entre les bundles et peut être utilisé pour synchroniser des fichiers situés en dehors de la racine du bundle. (La racine du bundle est l'emplacement du fichier databricks.yml.) Ceci est particulièrement utile lorsque vous avez un seul repository qui héberge plusieurs bundles et que vous souhaitez partager des bibliothèques, des fichiers de code ou la configuration.

Les chemins spécifiés doivent être relatifs aux fichiers et aux répertoires ancrés dans le dossier où le mappage paths est défini. Si une ou plusieurs valeurs de chemin remontent dans l'arborescence jusqu'à un ancêtre de la racine du bundle, le chemin racine est déterminé dynamiquement pour garantir que la structure du dossier reste intacte. Par exemple, si le dossier racine du bundle est nommé my_bundle, alors cette configuration dans databricks.yml synchronise le dossier common situé un niveau au-dessus de la racine du bundle et la racine du bundle elle-même :

YAML

sync:
  paths:
    - ../common
    - .

Un déploiement de ce bundle entraîne la structure de dossiers suivante dans le Workspace :

common/
  common_file.txt
my_bundle/
  databricks.yml
  src/
    ...

Combinaison de chemins avec inclusion et exclusion

Les mappages paths, include et exclude sont appliqués dans l'ordre : paths sélectionne les dossiers à synchroniser, puis include et exclude filtrent les fichiers trouvés dans ces dossiers. Écrivez les globs include et exclude par rapport à la racine du bundle (l'emplacement du fichier databricks.yml), de la même manière que lorsque paths n'est pas défini. Lorsqu'une valeur paths traverse la racine du bundle et que la racine de synchronisation s'étend à un ancêtre commun, la CLI Databricks ré-ancre automatiquement vos globs include et exclude à la nouvelle racine de synchronisation, de sorte que vous n'avez pas besoin de les ajuster.

L'exemple suivant synchronise à la fois le dossier ../common et la racine du bundle, inclut tous les fichiers .whl que .gitignore exclurait autrement, et exclut un seul fichier :

YAML

sync:
  paths:
    - ../common
    - .
  include:
    - my_package/dist/*.whl
  exclude:
    - my_package/dist/delete-me.whl

cibles

Type: Map

Définit les contextes de cible de déploiement pour le bundle. Chaque target est une collection unique d'artefacts, de paramètres du Workspace Databricks et parfois de détails de ressources spécifiques à la cible.

Le mappage targets se compose d'un ou de plusieurs mappages cibles, chacun devant avoir un nom programmatique (ou logique) unique. Ce mappage est facultatif mais fortement recommandé.

Les paramètres de la correspondance targets prévalent sur les paramètres spécifiés dans les correspondances Workspace, artefacts et Ressources de niveau supérieur.

Une cible peut également remplacer les valeurs de toutes les variables de niveau supérieur.

YAML

targets:
  <target-name>:
    <target-field-name>: <target-field-value>

Clé	Type	Description
artifacts	Carte	Les artefacts à inclure dans le déploiement cible. Voir les artefacts.
bundle	Carte	Les attributs du bundle lors du déploiement vers cette cible. Voir bundle.
cluster_id	Chaîne	L'identifiant du cluster à utiliser pour cette cible.
compute_id	Chaîne	Obsolète. L'ID du compute à utiliser pour cette cible.
default	Booléen	Que cette cible soit la cible default. Voir targets. name .default.
git	Carte	Les paramètres de contrôle de version Git pour la cible. Voir Git.
mode	Chaîne	Le mode de déploiement pour la cible. Les valeurs valides sont development ou production. Voir targets. name .mode et modes de déploiement des Declarative Automation Bundles.
permissions	Séquence	Les autorisations pour le déploiement et l'exécution du bundle dans la cible. Afficher les autorisations.
presets	Carte	Les préréglages de déploiement pour la cible. Voir targets. name .presets.
resources	Carte	Les définitions de ressources pour la cible. See Ressources.
run_as	Carte	L'identité à utiliser pour exécuter le bundle. Voir run_as et Spécifier une identité d'exécution pour un workflow Declarative Automation Bundles.
sync	Carte	Les chemins locaux à synchroniser avec le Workspace cible lorsqu'un bundle est exécuté ou déployé. Voir synchronisation.
variables	Carte	Les définitions des variables personnalisées pour la cible. Consultez les variables.
workspace	Carte	Le Databricks Workspace pour la cible. See Workspace.

Clé	Type	Description
artifacts	Carte	Les artefacts à inclure dans le déploiement cible. Voir les artefacts.
bundle	Carte	Les attributs du bundle lors du déploiement vers cette cible. Voir bundle.
cluster_id	Chaîne	L'identifiant du cluster à utiliser pour cette cible.
compute_id	Chaîne	Obsolète. L'ID du compute à utiliser pour cette cible.
default	Booléen	Que cette cible soit la cible default. Voir targets. name .default.
git	Carte	Les paramètres de contrôle de version Git pour la cible. Voir Git.
mode	Chaîne	Le mode de déploiement pour la cible. Les valeurs valides sont development ou production. Voir targets. name .mode et modes de déploiement des Declarative Automation Bundles.
permissions	Séquence	Les autorisations pour le déploiement et l'exécution du bundle dans la cible. Afficher les autorisations.
presets	Carte	Les préréglages de déploiement pour la cible. Voir targets. name .presets.
resources	Carte	Les définitions de ressources pour la cible. See Ressources.
run_as	Carte	L'identité à utiliser pour exécuter le bundle. Voir run_as et Spécifier une identité d'exécution pour un workflow Declarative Automation Bundles.
sync	Carte	Les chemins locaux à synchroniser avec le Workspace cible lorsqu'un bundle est exécuté ou déployé. Voir synchronisation.
variables	Carte	Les définitions des variables personnalisées pour la cible. Consultez les variables.
workspace	Carte	Le Databricks Workspace pour la cible. See Workspace.

targets. name .« default »

Pour spécifier une default cible pour les commandes de bundle, définissez le mappage default sur true. Par exemple, cette cible nommée dev est la default :

YAML

targets:
  dev:
    default: true

Si un target default n'est pas configuré, ou si vous souhaitez valider, déployer et exécuter des Job ou des pipeline au sein d'un target spécifique, utilisez l'option -t des commandes de bundle.

Les commandes suivantes valident, déploient et exécutent my_job dans les cibles dev et prod :

Bash

databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev my_job

Bash

databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod my_job

L'exemple suivant déclare deux cibles. La première cible porte le nom dev et est la cible default utilisée lorsqu'aucune cible n'est spécifiée pour les commandes de bundle. La deuxième cible porte le nom prod et n'est utilisée que lorsque cette cible est spécifiée pour les commandes de bundle.

YAML

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>

targets. name .mode

Pour faciliter le développement et les meilleures pratiques CI/CD, Declarative Automation Bundles propose des modes de déploiement pour les cibles qui définissent des comportements par default pour les flux de travail de pré-production et de production. Certains comportements sont également configurables à l'aide de targets. name .presets.

Pour plus de détails, consultez les modes de déploiement des Declarative Automation Bundles.

astuce

Pour définir des identités d’exécution pour les bundles, vous pouvez spécifier run_as pour chaque cible, comme décrit dans Spécifier une identité d’exécution pour un workflow de bundles d’automatisation déclarative.

Pour spécifier qu'une cible est traitée comme une cible de développement, ajoutez l'ensemble de mappage mode à development. Pour spécifier qu'une cible est traitée comme une cible de production, ajoutez l'ensemble de mappage mode à production. Par exemple, cette cible nommée prod est traitée comme une cible de production :

YAML

targets:
  prod:
    mode: production

targets. name .presets

Vous pouvez personnaliser certains des comportements de déploiement cible mode à l'aide du mappage presets.

Pour une liste des préréglages disponibles, consultez Préréglages personnalisés.

L'exemple suivant montre une cible de production personnalisée qui préfixe et taggue toutes les ressources de production :

YAML

targets:
  prod:
    mode: production
    presets:
      name_prefix: 'production_' # prefix all resource names with production_
      tags:
        prod: true

variables

Type: Map

Définit une variable personnalisée pour le bundle. Pour chaque variable, définissez une description facultative, une valeur default, si la variable personnalisée est un type complexe ou une recherche pour récupérer une valeur d'ID, en utilisant le format suivant :

YAML

variables:
  <variable-name>:
    description: <variable-description>
    default: <optional-default-value>
    type: <optional-type-value> # "complex" is the only valid value
    lookup:
      <optional-object-type>: <optional-object-name>

remarque

Les variables sont supposées être de type string, sauf si type est défini sur complex. Consultez Définir une variable complexe.

Pour référencer une variable personnalisée dans la configuration du bundle, utilisez la substitution ${var.<variable_name>}.

Pour plus d'informations sur les variables personnalisées et les substitutions, consultez Substitutions et variables dans les Bundles d'automatisation déclaratifs.

Clé	Type	Description
default	Tout	La valeur par default de la variable.
description	Chaîne	La description de la variable.
lookup	Carte	Le nom de l'objet alert, cluster_policy, cluster, dashboard, instance_pool, job, metastore, pipeline, query, service_principal, ou warehouse pour lequel récupérer un ID. Voir variables. name .lookup.
type	Chaîne	Le type de la variable, simple ou complexe. Ne définissez cette clé que si la variable est complexe. Valeurs valides : complex.

Clé	Type	Description
default	Tout	La valeur par default de la variable.
description	Chaîne	La description de la variable.
lookup	Carte	Le nom de l'objet alert, cluster_policy, cluster, dashboard, instance_pool, job, metastore, pipeline, query, service_principal, ou warehouse pour lequel récupérer un ID. Voir variables. name .lookup.
type	Chaîne	Le type de la variable, simple ou complexe. Ne définissez cette clé que si la variable est complexe. Valeurs valides : complex.

variables. name .lookup

Type: Map

Le nom de l'objet alert, cluster_policy, cluster, dashboard, instance_pool, Job, metastore, pipeline, query, Service Principal ou warehouse pour lequel récupérer un ID. Pour information sur l'utilisation de la recherche, consultez Récupérer la valeur d'ID d'un objet.

Clé	Type	Description
alert	Chaîne	Le nom de l'alerte pour laquelle récupérer un ID.
cluster	Chaîne	Le nom du cluster pour lequel récupérer un ID.
cluster_policy	Chaîne	Le nom de la cluster_policy pour laquelle récupérer un ID.
dashboard	Chaîne	Le nom du tableau de bord pour lequel récupérer un ID.
instance_pool	Chaîne	Le nom du pool d'instances pour lequel récupérer un ID.
job	Chaîne	Le nom du Job pour lequel récupérer un ID.
metastore	Chaîne	Le nom du metastore pour lequel récupérer un ID.
notification_destination	Chaîne	Le nom de la notification_destination pour laquelle récupérer un ID. Ajouté dans la version 0.236.0 de la CLI Databricks
pipeline	Chaîne	Le nom du pipeline pour lequel récupérer un ID.
query	Chaîne	Le nom de la query pour laquelle récupérer un ID.
service_principal	Chaîne	Le nom du Service Principal pour lequel récupérer un ID.
warehouse	Chaîne	Le nom du warehouse pour lequel récupérer un ID.

Clé	Type	Description
alert	Chaîne	Le nom de l'alerte pour laquelle récupérer un ID.
cluster	Chaîne	Le nom du cluster pour lequel récupérer un ID.
cluster_policy	Chaîne	Le nom de la cluster_policy pour laquelle récupérer un ID.
dashboard	Chaîne	Le nom du tableau de bord pour lequel récupérer un ID.
instance_pool	Chaîne	Le nom du pool d'instances pour lequel récupérer un ID.
job	Chaîne	Le nom du Job pour lequel récupérer un ID.
metastore	Chaîne	Le nom du metastore pour lequel récupérer un ID.
notification_destination	Chaîne	Le nom de la notification_destination pour laquelle récupérer un ID. Ajouté dans la version 0.236.0 de la CLI Databricks
pipeline	Chaîne	Le nom du pipeline pour lequel récupérer un ID.
query	Chaîne	Le nom de la query pour laquelle récupérer un ID.
service_principal	Chaîne	Le nom du Service Principal pour lequel récupérer un ID.
warehouse	Chaîne	Le nom du warehouse pour lequel récupérer un ID.

Workspace

Type: Map

Définit le Workspace Databricks pour le bundle. Le fichier de configuration du bundle peut contenir une seule cartographie de niveau supérieur workspace pour spécifier les paramètres de Workspace Databricks non par défaut à utiliser.

important

Les chemins d’accès valides au workspace Databricks commencent soit par /Workspace, soit, pour les artefacts, /Volumesest également pris en charge. Les chemins d’accès personnalisés au workspace sont automatiquement préfixés par /Workspace; par conséquent, si vous utilisez une substitution de chemin d’accès au workspace dans votre chemin d’accès personnalisé, par exemple ${workspace.file_path}, vous n’avez pas besoin de préfixer le chemin d’accès par /Workspace.

Clé	Type	Description
account_id	Chaîne	L’ID de compte Databricks. Ajouté à la version 0,296.0 de Databricks CLI
artifact_path	Chaîne	Le chemin d'artefact à utiliser dans le workspace pour les déploiements et les exécutions de job.
auth_type	Chaîne	Type d’authentification à utiliser, particulièrement important dans les cas où l’interface CLI Databricks déduit un type d’authentification inattendu. Consultez Autoriser l’accès aux ressources Databricks.
azure_client_id	Chaîne	L'ID du client Azure. Consultez Workspace Authentication.
azure_environment	Chaîne	L'environnement Azure. Consultez Workspace Authentication.
azure_login_app_id	Chaîne	L'ID de l'application de connexion Azure. Consultez Workspace Authentication.
azure_tenant_id	Chaîne	L'ID du tenant Azure. Consultez Workspace Authentication.
azure_use_msi	Booléen	Utilisation de MSI pour Azure. Consultez Workspace Authentication.
azure_workspace_resource_id	Chaîne	L'ID de ressource du Workspace Azure. Consultez Workspace Authentication.
client_id	Chaîne	L'ID du client pour le workspace. Consultez Workspace Authentication.
file_path	Chaîne	Le chemin du fichier à utiliser dans le Workspace pour les déploiements et les exécutions de Job. Voir Workspace.file_path.
google_service_account	Chaîne	Le nom du compte de service Google. Consultez Workspace Authentication.
host	Chaîne	L'URL d'hôte du workspace Databricks. Consultez Noms, URL et ID d’instance du Workspace. La définition du mappage host indique au CLI Databricks de trouver un profil correspondant dans votre fichier .databrickscfg, puis d’utiliser les champs de ce profil pour déterminer le type d’authentification Databricks à utiliser. Si plusieurs profils avec un champ host correspondant existent dans votre fichier .databrickscfg, vous devez alors utiliser le mappage profile (ou les options de ligne de commande --profile ou -p) pour spécifier un profil.
profile	Chaîne	Le nom de profil du Workspace Databricks. Consultez workspace.profile.
resource_path	Chaîne	Le chemin des ressources du Workspace. Ajouté dans la version 0.230.0 de Databricks CLI
root_path	Chaîne	Le chemin racine du Workspace Databricks. Consultez workspace.root_path.
state_path	Chaîne	Le chemin d'état du Workspace. Cette clé correspond par default au chemin par default de ${workspace.root}/state et représente le chemin au sein de votre workspace pour stocker les informations d'état Terraform concernant les déploiements.
workspace_id	Entier	L’ID du Workspace Databricks. Ajouté dans la version 0.285.0 de Databricks CLI

Clé	Type	Description
account_id	Chaîne	L’ID de compte Databricks. Ajouté à la version 0,296.0 de Databricks CLI
artifact_path	Chaîne	Le chemin d'artefact à utiliser dans le workspace pour les déploiements et les exécutions de job.
auth_type	Chaîne	Type d’authentification à utiliser, particulièrement important dans les cas où l’interface CLI Databricks déduit un type d’authentification inattendu. Consultez Autoriser l’accès aux ressources Databricks.
azure_client_id	Chaîne	L'ID du client Azure. Consultez Workspace Authentication.
azure_environment	Chaîne	L'environnement Azure. Consultez Workspace Authentication.
azure_login_app_id	Chaîne	L'ID de l'application de connexion Azure. Consultez Workspace Authentication.
azure_tenant_id	Chaîne	L'ID du tenant Azure. Consultez Workspace Authentication.
azure_use_msi	Booléen	Utilisation de MSI pour Azure. Consultez Workspace Authentication.
azure_workspace_resource_id	Chaîne	L'ID de ressource du Workspace Azure. Consultez Workspace Authentication.
client_id	Chaîne	L'ID du client pour le workspace. Consultez Workspace Authentication.
file_path	Chaîne	Le chemin du fichier à utiliser dans le Workspace pour les déploiements et les exécutions de Job. Voir Workspace.file_path.
google_service_account	Chaîne	Le nom du compte de service Google. Consultez Workspace Authentication.
host	Chaîne	L'URL d'hôte du workspace Databricks. Consultez Noms, URL et ID d’instance du Workspace. La définition du mappage host indique au CLI Databricks de trouver un profil correspondant dans votre fichier .databrickscfg, puis d’utiliser les champs de ce profil pour déterminer le type d’authentification Databricks à utiliser. Si plusieurs profils avec un champ host correspondant existent dans votre fichier .databrickscfg, vous devez alors utiliser le mappage profile (ou les options de ligne de commande --profile ou -p) pour spécifier un profil.
profile	Chaîne	Le nom de profil du Workspace Databricks. Consultez workspace.profile.
resource_path	Chaîne	Le chemin des ressources du Workspace. Ajouté dans la version 0.230.0 de Databricks CLI
root_path	Chaîne	Le chemin racine du Workspace Databricks. Consultez workspace.root_path.
state_path	Chaîne	Le chemin d'état du Workspace. Cette clé correspond par default au chemin par default de ${workspace.root}/state et représente le chemin au sein de votre workspace pour stocker les informations d'état Terraform concernant les déploiements.
workspace_id	Entier	L’ID du Workspace Databricks. Ajouté dans la version 0.285.0 de Databricks CLI

Authentification du Workspace

Le mappage de workspace peut également contenir des mappages pour spécifier le mécanisme d'authentification Databricks à utiliser. S'ils ne sont pas spécifiés dans le mappage de workspace de niveau supérieur, ils doivent être spécifiés dans un mappage de workspace en tant qu'enfant d'une ou plusieurs des cibles dans le mappage de cibles de niveau supérieur.

• Pour l'authentification OAuth machine-to-machine (M2M), le mapping client_id est utilisé. Vous pouvez également définir cette valeur dans la variable d'environnement locale DATABRICKS_CLIENT_ID. Ou vous pouvez créer un profil de configuration avec la valeur client_id, puis spécifier le nom du profil avec le mappage profile (ou en utilisant les options --profile ou -p lors de l'exécution des commandes validate, deploy, run et destroy du bundle avec le Databricks CLI). Voir Autoriser l’accès du Service Principal à Databricks avec OAuth.

remarque

Vous ne pouvez pas spécifier de valeur de secret client dans le fichier de configuration du bundle. Au lieu de cela, définissez la variable d'environnement locale DATABRICKS_CLIENT_SECRET. Ou vous pouvez ajouter la valeur client_secret à un profil de configuration, puis spécifier le nom du profil avec le mappage profile (ou en utilisant les options --profile ou -p lors de l'exécution des commandes de validation, de déploiement, d'exécution et de destruction du bundle avec la CLI Databricks).

workspace.root_path

Ce mappage workspace peut contenir un mappage root_path pour spécifier un chemin racine non-default à utiliser dans le Workspace pour les déploiements et les exécutions de workflow, par exemple :

YAML

workspace:
  root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}

Par default, pour root_path, le CLI Databricks utilise le chemin par default de /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}, qui utilise des substitutions.

important

N'utilisez pas un chemin /Shared (tel que /Shared/.bundle/prod/...) comme root_path de production. Le dossier /Shared est accessible en écriture par tous les utilisateurs du workspace, ce qui signifie que n'importe qui pourrait modifier votre code de production déployé, les définitions de job et les bibliothèques. Déployez plutôt dans un dossier dont l'accès en écriture est contrôlé par les ACL de dossier, et n'accordez l'accès en écriture qu'à l'identité qui déploie le bundle.

Databricks recommande de déployer des bundles de production à l'aide d'un Service Principal et de restreindre l'accès en écriture à la production root_path à ce Service Principal.

workspace.artifact_path

Ce mappage workspace peut également contenir un mappage artifact_path pour spécifier un chemin d'artefact non default à utiliser dans le Workspace pour les déploiements et les exécutions de jobs, par exemple :

YAML

workspace:
  artifact_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/artifacts

Par default, pour artifact_path, le CLI Databricks utilise le chemin par default de ${workspace.root}/artifacts, qui utilise des substitutions.

remarque

Le mappage artifact_path ne prend pas en charge les chemins Databricks File System (DBFS).

workspace.file_path

Ce mappage workspace peut également contenir un mappage file_path pour spécifier un chemin de fichier non default à utiliser dans le Workspace pour les déploiements et les exécutions de job, par exemple :

YAML

workspace:
  file_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/files

Par default, pour file_path, le CLI Databricks utilise le chemin par default de ${workspace.root}/files, qui utilise des substitutions.

important

Vous ne pouvez pas spécifier de variables personnalisées pour ces valeurs d’authentification en utilisant la syntaxe ${var.*}.

Workspace.profil

remarque

Databricks vous recommande d'utiliser le mappage host (ou les options --profile ou -p lorsque vous exécutez les commandes de validation, de déploiement, d'exécution et de suppression du bundle avec la CLI Databricks) au lieu du mappage profile, car cela rend vos fichiers de configuration de bundle plus portables.

Le mappage profile spécifie le nom d'un profil de configuration à utiliser pour s'authentifier sur ce Workspace Databricks. Ce profil de configuration correspond à celui que vous avez créé lorsque vous avez configuré la CLI Databricks.

Objets courants

git

Type: Map

Définit les détails du contrôle de version git. Ceci est utile pour propager les métadonnées de déploiement qui peuvent être utilisées ultérieurement pour identifier les Ressources. Par exemple, vous pouvez tracer l'origine du repository d'un Job déployé par CI/CD.

Chaque fois que vous exécutez une commande bundle telle que validate, deploy ou run, la commande bundle renseigne l'arborescence de configuration de la commande avec les paramètres default suivants :

Pour récupérer ou remplacer les paramètres Git, votre bundle doit se trouver dans un répertoire associé à un repository Git, par exemple un répertoire local initialisé en exécutant la commande git clone. Si le répertoire n'est pas associé à un repository Git, ces paramètres Git sont vides.

Clé	Type	Description
branch	Chaîne	Le nom de la Branch Git actuelle. C'est la même valeur que vous obtiendriez si vous exécutiez la commande git branch --show-current depuis votre référentiel cloné. Vous pouvez utiliser des substitutions pour faire référence à cette valeur avec vos fichiers de configuration de bundle, comme ${bundle.git.branch}.
origin_url	Chaîne	L'URL d'origine du repository. C'est la même valeur que vous obtiendriez si vous exécutiez la commande git config --get remote.origin.url depuis votre référentiel cloné. Vous pouvez utiliser des substitutions pour faire référence à cette valeur avec vos fichiers de configuration de bundle, comme ${bundle.git.origin_url}.

Clé	Type	Description
branch	Chaîne	Le nom de la Branch Git actuelle. C'est la même valeur que vous obtiendriez si vous exécutiez la commande git branch --show-current depuis votre référentiel cloné. Vous pouvez utiliser des substitutions pour faire référence à cette valeur avec vos fichiers de configuration de bundle, comme ${bundle.git.branch}.
origin_url	Chaîne	L'URL d'origine du repository. C'est la même valeur que vous obtiendriez si vous exécutiez la commande git config --get remote.origin.url depuis votre référentiel cloné. Vous pouvez utiliser des substitutions pour faire référence à cette valeur avec vos fichiers de configuration de bundle, comme ${bundle.git.origin_url}.

Exemples

Vous pouvez remplacer les paramètres origin_url et branch dans le mappage git de votre mappage bundle de niveau supérieur si nécessaire :

YAML

bundle:
  git:
    origin_url: <some-non-default-origin-url>
    branch: <some-non-current-branch-name>