Limites et FAQ relatives à l’intégration de Git à des dossiers Git Databricks

L’intégration de dossiers Git Databricks et Git présente des limites qui sont spécifiées dans les sections suivantes. Pour obtenir des informations générales, consultez Limites de Databricks

Passer à :

• Limites des fichiers et des référentiels
• Types de ressources pris en charge dans les dossiers Git
• FAQ : Configuration de dossiers Git

Limites des fichiers et des référentiels

Azure Databricks n’impose pas de limite à la taille d’un dépôt. Toutefois :

• Les branches de travail sont limitées à 1 gigaoctet (Go).
• Les fichiers supérieurs à 10 Mo ne peuvent pas être consultés dans l’interface utilisateur Azure Databricks.
• Les fichiers individuels de l’espace de travail sont soumis à une limite de taille distincte. Pour en savoir plus, consultez les Limitations.

Databricks recommande que dans un référentiel :

• Le total de toutes les ressouces d’espace de travail et des fichiers ne dépasse pas 20 000.

Pour toute opération Git, l’utilisation de la mémoire est limitée à 2 Go et les écritures sur disque sont limitées à 4 Go. La limite étant fixée par opération, un échec se produit si vous tentez de cloner un repo Git dont la taille actuelle est de 5 Go. Toutefois, si vous clonez un dépôt Git de 3 Go en une seule opération et que vous y ajoutez 2 Go par la suite, l’opération de téléchargement suivante réussira.

Vous pouvez recevoir un message d’erreur si votre référentiel dépasse ces limites. Il se peut également que vous receviez une erreur de délai d’expiration lors du clonage du référentiel, mais l’opération pourrait se terminer en arrière-plan.

Pour utiliser un référentiel supérieur aux limites de taille, essayez d’effectuer une extraction éparse.

Si vous devez écrire des fichiers temporaires que vous ne souhaitez pas conserver après l’arrêt du cluster, l’écriture des fichiers temporaires dans $TEMPDIR évite de dépasser les limites de taille des branches et offre de meilleures performances que l’écriture dans le répertoire de travail actuel (CWD) si le CWD se trouve dans le système de fichiers de l’espace de travail. Pour plus d’informations, voir Où dois-je écrire les fichiers temporaires sur Azure Databricks ?.

Nombre maximal de dossiers Git par espace de travail

Vous pouvez au plus avoir 2 000 dossiers Git par espace de travail. Si vous avez besoin d’un nombre supérieur, contactez le support Databricks.

Récupération de fichiers supprimés de dossiers Git dans votre espace de travail

Les actions d’espace de travail sur les dossiers Git varient en termes de récupération de fichiers. Certaines actions autorisent la récupération via le dossier Corbeille, tandis que d’autres ne le font pas. Les fichiers précédemment validés et envoyés à une branche distante peuvent être restaurés à l’aide de l’historique de validation Git pour le référentiel Git distant. Ce tableau décrit le comportement et la récupération de chaque action :

Action	Le fichier est-il récupérable ?
Supprimer un fichier avec un navigateur d’espace de travail	Oui, à partir du dossier Corbeille
Ignorer un nouveau fichier avec la boîte de dialogue Dossier Git	Oui, à partir du dossier Corbeille
Ignorer un fichier modifié avec la boîte de dialogue Dossier Git	Non, le fichier est parti
reset (dur) pour les modifications de fichier non validées	Non, les modifications de fichier sont supprimées
reset (dur) pour les fichiers non validés, nouvellement créés	Non, les modifications de fichier sont supprimées
Changer de branches avec la boîte de dialogue Dossier Git	Oui, à partir du dépôt Git distant
Autres opérations Git (Commit &Push, etc.) à partir de la boîte de dialogue dossier Git	Oui, à partir du dépôt Git distant
PATCH opérations de mise à jour /repos/id à partir de l’API Repos	Oui, à partir du dépôt Git distant

Les fichiers supprimés d’un dossier Git par le biais d’opérations Git de l’interface utilisateur de l’espace de travail peuvent être récupérés à partir de l’historique des branches distantes à l’aide de la ligne de commande Git (ou d’autres outils Git) si ces fichiers ont été précédemment validés et envoyés au dépôt distant. Les actions de l’espace de travail varient en fonction de la récupération des fichiers. Certaines actions autorisent la récupération à travers la corbeille, tandis que d’autres ne le font pas. Les fichiers précédemment validés et envoyés à une branche distante peuvent être restaurés via l’historique de validation Git. Le tableau ci-dessous présente le comportement et la récupération de chaque action :

Prise en charge de référentiel unique

Databricks recommande de ne pas créer de dossiers Git soutenus par des monorepos, où un monorepo est un grand référentiel Git à organisation unique avec plusieurs milliers de fichiers à travers de nombreux projets.

Types de ressources pris en charge dans les dossiers Git

Seuls certains types d’actifs Azure Databricks sont pris en charge par les dossiers Git. Un type de ressource pris en charge peut être sérialisé, contrôlé par la version et envoyé (push) au dépôt Git de stockage.

Actuellement, les types d'actifs pris en charge sont :

Type de ressource	Détails
Fichier	Les fichiers sont des données sérialisées et peuvent inclure n'importe quoi, des bibliothèques aux binaires en passant par le code et les images. Pour plus d’informations, consultez Que sont les fichiers d’espace de travail ?
Notebook	Les notebooks sont spécifiquement les formats de fichiers de notebook pris en charge par Databricks. Les notebooks sont considérés comme un type de ressource Azure Databricks distinct des fichiers, car ils ne sont pas sérialisés. Les dossiers Git déterminent un notebook par l’extension de fichier (par exemple .ipynb) ou par les extensions de fichier combinées avec un marqueur spécial dans le contenu du fichier (par exemple, un # Databricks notebook source commentaire au début des .py fichiers sources).
Dossier	Un dossier est une structure spécifique à Azure Databricks qui représente des informations sérialisées sur un regroupement logique de fichiers dans Git. Comme prévu, l’utilisateur(-trice) le considère comme un « dossier » lorsqu’il consulte un dossier Azure Databricks Git ou y accède avec l’interface CLI Azure Databricks.

Les types de ressources Azure Databricks qui ne sont actuellement pas pris en charge dans les dossiers Git incluent les éléments suivants :

• Requêtes DBSQL
• Alertes
• Tableaux de bord (y compris les tableaux de bord hérité)
• Expériences
• Espaces Genie

Lorsque vous utilisez vos ressources dans Git, observez les limitations suivantes dans le nommage de fichier :

• Un dossier ne peut pas contenir de notebook portant le même nom qu’un autre notebook, fichier ou dossier dans le même référentiel Git, même si l’extension de fichier diffère. (Pour les notebooks au format source, l’extension est .py pour python, .scala pour Scala, .sql pour SQL et .r pour R. Pour les notebooks au format IPYNB, l’extension est .ipynb.) Par exemple, vous ne pouvez pas utiliser un notebook au format source nommé test1.py et un notebook IPYNB nommé test1 dans le même dossier Git, car le fichier de notebook Python au format source (test1.py) sera sérialisé en tant que test1, ce qui engendrera un conflit.
• Le caractère / n’est pas pris en charge dans les noms de fichiers. Par exemple, vous ne pouvez pas avoir de fichier nommé i/o.py dans votre dossier Git.

Si vous tentez d’effectuer des opérations Git sur des fichiers qui ont des noms avec ces modèles, vous obtiendrez un message « Erreur lors de l’extraction de l’état Git ». Si vous recevez cette erreur de façon inattendue, passez en revue les noms de fichiers des ressources dans votre référentiel Git. Si vous trouvez des fichiers avec des noms avec ces modèles qui causent des conflits, renommez-les et réessayez l’opération.

Remarque

Vous pouvez déplacer des ressources existantes non supportées dans un dossier Git, mais vous ne pouvez pas livrer les modifications de ces ressources dans le référentiel. Vous ne pouvez pas créer de nouveaux actifs non pris en charge dans un dossier Git.

Formats du notebook

Databricks considère deux types de formats de notebooks spécifiques à Databricks : « source » et « ipynb ». Lorsqu’un utilisateur valide un notebook au format « source », la plateforme Azure Databricks valide un fichier plat avec un suffixe de langue, tel que .py, , .sql.scalaou .r. Un notebook au format source contient uniquement du code source et ne contient aucune sortie comme les affichages de tableau et les visualisations qui sont les résultats de l’exécution du notebook.

Le format « ipynb » comporte toutefois des sorties associées. Ces artefacts sont automatiquement envoyés au référentiel Git qui sauvegarde le dossier Git lors de l’envoi (push) du notebook .ipynb qui les a générés. Si vous souhaitez valider des sorties avec le code, utilisez le format de notebook « ipynb » et configurez la configuration pour permettre à un utilisateur de valider les sorties générées. Par conséquent, « ipynb » prend également en charge une meilleure expérience d’affichage dans Databricks pour les notebooks envoyés vers les référentiels Git distants au moyen de dossiers Git.

Format source du notebook	Détails
source	Il peut s’agir de n’importe quel fichier de code avec un suffixe standard de fichier qui signale le langage du code, comme .py, .scala, .r et .sql. Les notebooks « source » sont traités comme des fichiers texte et n’incluent aucune sortie associée lorsqu’ils sont validés dans un dépôt Git.
ipynb	Les fichiers « ipynb » se terminent par .ipynb et peuvent, s’ils sont configurés, envoyer (push) des sorties (telles que des visualisations) du dossier Git Databricks vers le référentiel de stockage Git. Un notebook .ipnynb peut contenir du code dans n’importe quel langage pris en charge par les notebooks Databricks (malgré la partie py de .ipynb).

Si vous souhaitez que les sorties soient renvoyées à votre dépôt après l’exécution d’un notebook, utilisez un notebook (Jupyter) .ipynb. Si vous souhaitez simplement exécuter le notebook et le gérer dans Git, utilisez un format « source » comme .py.

Pour en savoir plus sur les formats de notebooks pris en charge, consultez Exporter et importer des notebooks Databricks.

Remarque

Que sont les « sorties » ?

Les sorties sont les résultats de l’exécution d’un notebook sur la plateforme Databricks, y compris l’affichage de tables et les visualisations.

Comment savoir quel est le format utilisé par un notebook, en dehors de l’extension du fichier ?

En haut d’un notebook géré par Databricks, il existe généralement un commentaire indiquant le format en une ligne. Par exemple, pour un notebook « source » .py, vous allez voir une ligne qui ressemble à ceci :

# Databricks notebook source

Pour des fichiers .ipynb, le suffixe du fichier est utilisé pour indiquer qu’il s’agit du format de notebook « ipynb ».

Notebooks IPYNB dans les dossiers Databricks Git

La prise en charge de notebooks Jupyter (fichiers .ipynb) est disponible dans les dossiers Git. Vous pouvez cloner des référentiels avec .ipynb des notebooks, les utiliser dans Azure Databricks, puis les valider et les envoyer en tant que .ipynb notebooks. Les métadonnées, telles que le tableau de bord du bloc-notes, sont conservées. Les administrateurs peuvent contrôler si les sorties peuvent être validées ou pas.

Autoriser la validation de la sortie .ipynb du notebook

Par défaut, le paramètre d’administration des dossiers Git n’autorise pas la validation de sortie du notebook .ipynb. Les administrateurs de l’espace de travail peuvent modifier ce paramètre :

1. Accédez aux paramètres Paramètres d’administration > Espace de travail.

2. Sous Dossiers Git> Autoriser les dossiers Git à exporter les sorties IPYNB, sélectionner Autoriser : Les sorties IPYNB peuvent être activées.

   

Important

Lorsque des sorties sont incluses, les configurations de tableau de bord et la visualisation sont conservées au format de fichier .ipynb.

Contrôler les validations de l’artefact de sortie du notebook IPYNB

Lorsque vous validez un fichier .ipynb, Databricks crée un fichier config pour vous permet de contrôler la façon dont vous validez les sorties : .databricks/commit_outputs.

1. Si vous avez un fichier de notebook .ipynb, mais aucun fichier config dans votre référentiel, ouvrez le mode État Git.

2. Dans la boite de dialogue de notification, cliquez sur Créer un fichier commit_outputs.

   

Vous pouvez également générer des fichiers config à partir du menu Fichier. Le menu Fichier dispose d’un contrôle qui vous permet de mettre à jour automatiquement le fichier config pour spécifier l’inclusion ou l’exclusion des sorties pour un notebook spécifique.

1. Dans le menu Fichier, sélectionnez Valider les sorties des notebooks.

   

2. Dans la boîte de dialogue, confirmez votre choix de valider les sorties de notebook.

   

Convertir un bloc-notes source en IPYNB

Vous pouvez convertir un notebook source existant dans un dossier Git en notebook IPYNB via l’interface utilisateur Azure Databricks.

1. Ouvrez un bloc-notes source dans votre espace de travail.

2. Sélectionnez Fichier dans le menu de l’espace de travail, puis sélectionnez Modifier le format du bloc-notes [source]. Si le bloc-notes est déjà au format IPYNB, [source] est [ipynb] dans l’élément de menu.

   

3. Dans la boîte de dialogue modale, sélectionnez « Format du bloc-notes Jupyter (.ipynb) », puis cliquez sur Modifier.

   

Vous pouvez également :

• Créer des nouveaux notebooks .ipynb.
• Affichez les diffs comme code diff (modifications du code dans les cellules) ou diff brut (modifications du code présentées sous forme de syntaxe JSON, notamment des sorties de notebook sous forme de métadonnées).

Pour plus d’informations sur les types de notebooks pris en charge dans Azure Databricks, consultez Exporter et importer des notebooks Databricks.

Forum aux questions : Configuration du dossier Git

Où est stocké le contenu d’un dépôt Azure Databricks ?

Le contenu d’un dépôt est temporairement cloné sur disque dans le plan de contrôle. Les fichiers de notebook Azure Databricks sont stockés dans la base de données du plan de contrôle, tout comme les notebooks dans l’espace de travail principal. Des fichiers non-notebooks sont stockés sur un disque pendant au plus 30 jours.

Les dossiers Git prennent-ils en charge les serveurs Git locaux ou auto-hébergés ?

Les dossiers Git Databricks prennent en charge l’intégration managée autogérée GitHub Enterprise, Bitbucket Server, Azure DevOps Server et GitLab, si le serveur est accessible par Internet. Pour obtenir plus de détails sur l’intégration de dossiers Git à un serveur Git local, lisez Serveur proxy Git pour dossiers Git.

Pour intégrer un serveur Bitbucket, un serveur GitHub Enterprise ou une instance d’abonnement autogérée GitLab qui n’est pas accessible par Internet, contactez l’équipe de votre compte Azure Databricks.

Quels types de ressources Databricks sont pris en charge par des dossiers Git ?

Pour plus d’informations sur les types de ressources pris en charge, lisez les types de ressources pris en charge dans les dossiers Git.

Les dossiers Git prennent-ils en charge les fichiers .gitignore ?

Oui. Si vous ajoutez un fichier à votre dépôt et que vous ne souhaitez pas qu’il soit suivi par Git, créez un fichier .gitignore ou utilisez un clone à partir de votre dépôt distant et ajoutez le nom de fichier, y compris l’extension.

.gitignore fonctionne uniquement pour les fichiers qui ne sont pas déjà suivis par Git. Si vous ajoutez un fichier déjà suivi par Git à un fichier .gitignore, le fichier est toujours suivi par Git.

Puis-je créer des dossiers de niveau supérieur qui ne sont pas des dossiers utilisateur ?

Oui, les administrateurs peuvent créer des dossiers de niveau supérieur à une profondeur. Les dossiers Git ne prennent pas en charge des niveaux de dossiers supplémentaires.

Les dossiers Git prennent-ils en charge les sous-modules Git ?

Non. Vous pouvez cloner un dépôt contenant des sous-modules Git, mais les sous-modules ne sont pas clonés.

Azure Data Factory (ADF) prend-il en charge les dossiers Git ?

Oui.

Gestion de la source

Pourquoi les tableaux de bord du notebook disparaissent-ils lorsque j’extrais ou bascule vers une autre branche ?

Il s’agit actuellement d’une limitation, car les fichiers sources du notebook Azure Databricks ne stockent pas les informations relatives au tableau de bord du notebook.

Si vous souhaitez conserver les tableaux de bord dans le référentiel Git, remplacez le format du notebook par .ipynb (le format de notebook Jupyter). Par défaut, .ipynb prend en charge les définitions de tableau de bord et de visualisation. Si vous souhaitez conserver les données du graphique (points de données), vous devez valider le notebook avec des sorties.

Pour en savoir plus sur la validation des sorties de notebook .ipynb, consultez l’article Autoriser la validation de la sortie du notebook .ipynb.

Les dossiers Git prennent-ils en charge la fusion de branche ?

Oui. Vous pouvez également créer une demande de tirage (pull request) et de la fusionner par le biais de votre fournisseur Git.

Puis-je supprimer une branche d’un dépôt Azure Databricks ?

Non. Pour supprimer une branche, vous devez travailler dans votre fournisseur Git.

Si une bibliothèque est installée sur un cluster et si une bibliothèque du même nom est incluse dans un dossier au sein d’un dépôt, quelle bibliothèque est importée ?

La bibliothèque figurant dans le dépôt est importée. Pour plus d’informations sur la priorité de la bibliothèque dans Python, consultez Priorité de la bibliothèque Python.

Puis-je extraire la dernière version d’un dépôt à partir de Git avant d’exécuter un travail sans me servir d’un outil d’orchestration externe ?

Non. En général, vous pouvez l’intégrer en tant que pré-validation sur le serveur Git de sorte que chaque envoi à une branche (principale/produit) met à jour le dépôt Production.

Puis-je exporter un dépôt ?

Vous pouvez exporter des notebooks, des dossiers ou un dépôt entier. Vous ne pouvez pas exporter de fichiers non-notebooks. Si vous exportez un dépôt entier, les fichiers non-notebooks ne sont pas inclus. Si vous souhaitez exporter, utilisez la commande workspace export dans l’interface CLI Databricks ou utilisez l’API Espace de travail.

Sécurité, authentification et jetons

Problème avec une stratégie d’accès conditionnel (CAP) pour Microsoft Entra ID

Lorsque vous essayez de cloner un référentiel, vous pouvez obtenir un message d’erreur « Accès refusé » dans les cas suivants :

• Azure Databricks est configuré pour utiliser Azure DevOps avec l’authentification Microsoft Entra ID.
• Vous avez activé une stratégie d’accès conditionnel dans Azure DevOps et une stratégie d’accès conditionnel Microsoft Entra ID.

Pour résoudre ce problème, ajoutez une exclusion à la stratégie d’accès conditionnel (CAP) pour l’adresse IP ou les utilisateurs d’Azure Databricks.

Pour en savoir plus, référez-vous à la section Politiques en matière d’accès conditionnel.

Liste verte avec des jetons Azure AD

Si vous utilisez Azure Active Directory (AAD) pour l’authentification auprès d’Azure DevOps, la liste verte par défaut limite les URL Git aux URL suivantes :

• dev.azure.com
• visualstudio.com

Pour plus d’informations, consultez Les listes vertes limitent l’utilisation du dépôt distant.

Les contenus des dossiers Git Azure Databricks sont-ils chiffrés ?

Les contenus des dossiers Git Azure Databricks sont chiffrés par Azure Databricks en utilisant une clé par défaut. Le chiffrement à l’aide de clés gérées par le client n’est pas pris en charge, sauf lorsqu’il s’agit de chiffrer les informations d’identification Git.

Comment et où les jetons GitHub sont-ils stockés dans Azure Databricks ? Qui aurait accès à partir d’Azure Databricks ?

• Les jetons d’authentification sont stockés dans le plan de contrôle Azure Databricks, et un employé d’Azure Databricks ne peut y accéder qu’à l’aide d’informations d’identification temporaires qui sont auditées.
• Azure Databricks journalise la création et la suppression de ces jetons, mais pas leur utilisation. Azure Databricks intègre une journalisation qui suit des opérations Git, qui pourraient être utilisées pour auditer l’utilisation des jetons par l’application Azure Databricks.
• GitHub Enterprise audite l’utilisation des jetons. D’autres services Git peuvent également avoir un audit de serveur Git.

Les dossiers Git prennent-ils en charge la signature GPG des commits ?

Non.

Les dossiers Git prennent-ils en charge SSH ?

Non, uniquement HTTPS.

Erreur lors de la connexion d’Azure Databricks à un référentiel Azure DevOps dans une autre location

Quand vous essayez de vous connecter à DevOps dans une location distincte, vous recevez le message Unable to parse credentials from Azure Active Directory account. Si le projet Azure DevOps se trouve dans une location Microsoft Entra ID différente d’Azure Databricks, vous devez utiliser un jeton d’accès d’Azure DevOps. Consultez la section Se connecter à un référentiel Azure DevOps à l’aide d’un jeton DevOps.

CI/CD et MLOps

Les modifications entrantes suppriment l’état du notebook

Les opérations Git qui modifient le code source du notebook entraînent la perte de l’état du notebook, y compris les sorties des cellules, les commentaires, l’historique des versions et les widgets. Par exemple, git pull peut modifier le code source d’un notebook. Dans ce cas, les dossiers Git Databricks doivent remplacer le notebook existant pour importer les modifications. git commit et push ou la création d’une nouvelle branche n’affectent pas le code source du notebook, de sorte que l’état de celui-ci est préservé dans ces opérations.

Important

Les expériences MLflow ne fonctionnent pas dans les dossiers Git avec DBR 14.x ou des versions inférieures.

Puis-je créer une expérience MLflow dans un dépôt ?

Il existe deux types d’expériences MLflow : un espace de travail et un bloc-notes. Pour obtenir plus d’informations sur les deux types d’expériences MLflow, consultez Organiser des exécutions d’apprentissage avec des expériences MLflow.

Dans des dossiers Git, vous pouvez appeler mlflow.set_experiment("/path/to/experiment") pour une expérience MLflow de l’un des types et y journaliser des exécutions, mais cette expérience et les exécutions associées ne sont pas archivées dans un contrôle de code source.

Expériences MLflow d’espace de travail

Vous ne pouvez pas créer des expériences MLflow d’espace de travail dans un dossier Git Databricks (dossier Git). Si plusieurs utilisateurs utilisent des dossiers Git distincts pour collaborer sur le même code ML, journalisez des exécutions MLflow dans une expérience MLflow créée dans un dossier d’espace de travail normal.

Expériences MLflow de notebook

Vous pouvez créer des expériences de notebook dans un dossier Git Databricks. Si vous archivez votre notebook dans un contrôle de code source en tant que fichier .ipynb, vous pouvez journaliser des exécutions MLflow dans une expérience MLflow automatiquement créée et associée. Pour obtenir plus d’informations, parcourez la création d’expériences de notebook.

Empêcher la perte de données dans les expériences MLflow

Les expériences MLflow de notebook créées à l’aide de Databricks Jobs avec du code source dans un référentiel distant sont stockées dans un emplacement de stockage temporaire. Ces expériences persistent initialement après l’exécution du flux de travail, mais risquent d’être supprimées ultérieurement lors de la suppression planifiée de fichiers dans un stockage temporaire. Databricks recommande d’utiliser des expériences MLflow d’espace de travail avec Jobs et des sources Git distantes.

Avertissement

Chaque fois que vous passez à une branche qui ne contient pas le notebook, vous risquez de perdre les données d’expérience MLflow associées. Cette perte devient définitive si vous n’accédez pas à la branche précédente dans les 30 jours.

Si vous souhaitez récupérer les données d’expérience manquantes avant l’expiration des 30 jours, redonnez le nom d’origine au notebook, ouvrez le notebook, cliquez sur l’icône « expérience » sur le côté droit du volet (cette opération appelle efficacement l’API mlflow.get_experiment_by_name()) pour pouvoir consulter les exécutions et l’expérience récupérées. Après 30 jours, toute expérience MLflow orpheline est supprimée définitivement pour répondre aux politiques de conformité du RGDP.

Pour empêcher cette situation, Databricks vous recommande d’éviter de renommer complètement des notebooks dans des référentiels ou, si vous renommez un notebook, de cliquer sur l’icône « expérience » sur le côté gauche du volet immédiatement après le changement de nom d’un notebook.

Que se passe-t-il si un travail notebook est en cours d’exécution dans un espace de travail alors qu’une opération Git est en cours ?

À tout moment pendant une opération Git en cours, certains notebooks dans le dépôt peuvent avoir été mis à jour et d’autres non. Cela peut entraîner un comportement imprévisible.

Prenons un exemple où notebook A appelle notebook Z avec une commande %run. Si un travail, exécuté pendant une opération Git, lance la version la plus récente de notebook A, mais que notebook Z n’a pas encore été mis à jour, alors la commande %run du notebook A risque de lancer l’ancienne version de notebook Z. Pendant l’opération Git, les états du notebook ne sont pas prévisibles et le travail peut échouer ou exécuter notebook A et notebook Z à partir de commits différents.

Pour éviter cette situation, utilisez plutôt des travaux basés sur Git (où la source est un fournisseur Git et non un chemin d’accès à l’espace de travail). Pour plus d’informations, consultez Utiliser Git avec des travaux.

Ressources

Pour plus d’informations sur les fichiers d’espace de travail Databricks, consultez Que sont les fichiers d’espace de travail ?.