Pular para o conteúdo principal

O que aconteceu com o Databricks Repos?

Repos agora são chamados de pastas Git . Assim como Repos, as pastas Git permitem sincronizar pastas workspace com repositórios Git remotos para controle de versão.

O que essa mudança significa para mim?

A funcionalidade principal não mudou, apenas a terminologia. As operações da UI agora se referem a "pastas Git " em vez de "Repos".

Anteriormente, você criou uma pasta com suporte Gitselecionando Novo > repositório :

A nova opção de menu " " usada para se referir a um " Repo "

Agora, selecione Novo > Pasta Git .

A opção de menu "New" agora solicita que o senhor crie uma pasta Git ""

Essa alteração simplifica o trabalho com pastas controladas por versão:

  • Organização flexível de pastas : Crie pastas Git em qualquer nível da árvore de arquivos workspace . Por exemplo, /Workspace/Users/<user email>/level_1/level_2/level_3/<Git folder name>. Repos só poderiam existir em um nível fixo como /Workspace/Repos/<user email>/<Repo name>.
nota

As pastas Git podem conter tipos ativos que Repos não suportam, como o ativo Databricks SQL e os experimentos MLflow . Databricks adiciona suporte à serialização para mais ativos ao longo do tempo.

  • Interface simplificada : Trabalhe com Git diretamente no seu workspace sem precisar navegar até uma área separada Repos .

O que mudou?

  • As pastas do Git podem existir fora do diretório /Repos .
  • Para criar uma pasta Git, selecione Novo > Pasta Git . Novas pastas Git aparecem em /Workspace/Users/<user-email>/.
  • As pastas Git podem existir em qualquer nível abaixo de /Workspace/Users/<user-email>/ e você pode ter várias pastas Git.
  • Pastas Git suportam tipos ativos que Repos não suportam. Com o tempo, Databricks adiciona suporte à serialização para mais tipos ativos.
  • Pastas Git exigem um URL de repositório remoto. Repos não tinham esse requisito.

O que acontece com meus Repos atuais?

Repos agora estão integrados à interface do usuário workspace em /Workspace/Repos em vez de um nó de repositório separado de nível superior.

  • Os caminhos /Repos existentes continuam a funcionar. Tanto /Repos quanto /Workspace/Repos se referem à mesma pasta, portanto os caminhos nas referências jobs, dbutils.notebook.run e %run não precisam ser alterados.
  • Em casos raros, pode ser necessário realizar uma modificação única workspace para que esse redirecionamento funcione. Consulte Referências a objetos workspace.

Databricks recomenda a criação de novas pastas Git em vez de Repos. Colocar repositórios Git no mesmo local que outros ativos workspace torna-os mais fáceis de descobrir e gerenciar.

Permissões de pasta Git

As pastas Git usam as mesmas permissões de pastasworkspace que outras pastas workspace . A maioria das operações do Git requer a permissão CAN_MANAGE .

Versão do Databricks Runtime para executar código em pastas Git.

Para um comportamento consistente entre pastas Git e Repos legados, use Databricks Runtime 15.0 ou superior.

Comportamento do diretório de trabalho atual (CWD)

Databricks Runtime 14.0 e versões superiores suportam caminhos relativos e proporcionam uma experiência consistente de diretório de trabalho atual (CWD) para todos os notebooks. Versões anteriores do Databricks Runtime podem apresentar comportamento inconsistente do diretório de trabalho atual (CWD) entre pastas Git e pastas não-Git.

Comportamento de sys.path em Python

Databricks Runtime 14.3 e versões superiores fornecem o mesmo comportamento sys.path em pastas Git que em Repos legados. Versões anteriores não adicionam automaticamente o diretório raiz repo a sys.path para pastas Git . Como solução alternativa, adicione manualmente o caminho da pasta a sys.path.

Para exemplos, consulte Importar módulos Python e R.

precedência da biblioteca Python

Databricks Runtime 14.3 e versões superiores fornecem a mesma precedência da bibliotecaPython em pastas Git que em Repos legados.