Projetos com integração padrão Git

Colaboração

Se desejar trabalhar com outras pessoas no mesmo conteúdo de arquivos em um repositório Git específico, será possível incluir esses usuários como colaboradores em seu projeto. Esses usuários não precisam criar seus próprios projetos baseados no mesmo repositório Git . Eles podem trabalhar e testar em seus próprios clones do repositório e, em seguida, mesclar suas mudanças quando seu código estiver pronto. Ao adicionar colaboradores ao seu projeto, você pode acompanhar facilmente quem está trabalhando nele. Isso significa que você não precisa verificar a interface Git do usuário para ver quem está fazendo alterações.

Além de serem adicionados como colaboradores, os usuários devem ter seu próprio token de acesso para o repositório associado.

1. Inclua usuários como colaboradores no projeto e designe a eles a função Admin ou Editor . Você pode convidar apenas usuários que já possuam IBM Cloud Pak for Data uma conta. Consulte Incluindo colaboradores.
2. Dê a todos os colaboradores as permissões de acesso apropriadas para o repositório Git .
3. Os colaboradores são solicitados a criar e enviar seu próprio token de acesso pessoal quando eles puxam a filial Git para seu clone local. Veja Criando tokens de acesso pessoal para um repositório Git.

Ferramentas e ativos que podem ser usados em projetos com integração padrão do Git

Não é possível executar nenhuma das ações a seguir em projetos com a integração padrão do Git :

• Implementar no espaço
• Exportar projeto
• Importar ativos para um projeto não vazio

Se você estiver trabalhando em um projeto com integração Git padrão, o Git repositório poderá conter ativos adicionados a partir de outro projeto que usa o mesmo Git repositório, e você não poderá trabalhar com todos os ativos extraídos de um Git repositório. Para obter mais informações, consulte Solução de problemas do Watson Studio.

Ao selecionar os dados Local Git, você pode criar ativos de dados a partir de qualquer arquivo que escolher em seu clone local. Por exemplo, se você executar um notebook que gera um .csv arquivo, poderá usá-lo para torná-lo um ativo de dados que poderá ser refinado usando Data Refinery.

Se você salvar um fluxo de Data Refinery por exemplo, não apenas um arquivo .flow salvo que contém o próprio fluxo, mas o projeto cria um ativo que aponta para esse fluxo e que permite que você tenha metadados para esse ativo. Se você carregar um arquivo de dados, ele será carregado na pasta de dados do projeto e um recurso de dados também será criado para esse arquivo.

Os ativos do projeto e seus metadados são armazenados nos seguintes locais bem definidos dentro do Git repositório:

• assettypes: contém um conjunto de arquivos JSON que definem os tipos e outras características dos ativos. O conjunto de arquivos, se houver, que existe nesta pasta depende do conjunto de serviços que foram instalados.

• assets: contém todos os arquivos relevantes para o ativo e um arquivo de metadados com as informações especificadas pelo usuário (como uma descrição). Há uma pasta para cada tipo de ativo, com uma pasta .METADATA que contém os arquivos JSON com os metadados.

  Por exemplo, para um ativo de dados e um modelo salvo, você veria:

  assets/.METADATA
  assets/.METADATA/wml_model.mymodel1.json
  assets/.METADATA/data_asset.cars.json
  assets/data_asset/cars.csv
  assets/wml_model/mymodel1/7ca4e02d-fe0b-4832-921e-448bf05f435e
  assets/wml_model/mymodel1/3bbb4b08-2d84-4099-8d90-7e9f4fb496f5
  

  Você pode editar arquivos, por exemplo os arquivos JSON de metadados, para atualizar a descrição de um ativo. No entanto, é necessário ter cuidado ao editar esses arquivos, pois os metadados necessários para cada tipo de recurso são diferentes e não estão documentados, o que pode resultar em um comportamento inesperado se as alterações não forem válidas. Você nunca deve excluir arquivos manualmente nestes diretórios. Em vez disso, exclua os ativos apenas usando a interface do usuário do projeto.

  Não há descoberta automática para ativos recém-adicionados. Por exemplo, se você adicionar arquivos de modelo válidos para ./wml_model (e não usar a interface com o usuário do projeto), os modelos não serão registrados como ativos no projeto.

  Quando você pressiona atualizações para o Repositório Git externo, sempre inclua todos os arquivos sob os diretórios assettypes e assets incluindo assets/.METADATA. Esses arquivos são necessários para gerenciar os ativos do projeto de forma consistente para todos os colaboradores em todos os ramos Git .

Notebooks e scripts

Os cadernos e scripts não são ativos do projeto em um projeto Git padrão e não possuem metadados associados que são mantidos pelo Watson Studio. Em vez disso, os cadernos e scripts são arquivos de código arbitrário. Também não há um versionamento de ativos dentro de um projeto padrão Git . O controle de versão é feito por meio do versionamento inerente ao repositório Git .

Você desenvolve e testa notebooks e scripts no Jupyterlab e no RStudio. Não há restrições quanto à estrutura Git de diretórios que você usa, nem quanto às Git operações que você realiza.

Além disso, você tem controle total sobre o conteúdo .gitignore dos arquivos em seu clone para os arquivos que não deseja manter no Git repositório. Um .gitignore arquivo padrão é incluído no momento em que você cria o projeto, ignorando os arquivos principais e as informações de execução da tarefa (arquivo de metadados e registros, como arquivos assets/.METADATA/job_run.*assets/job_run e ). Se você quiser ignorar outros arquivos, você deve adicionar esses arquivos no arquivo padrão .gitignore e não usar o seu próprio arquivo .gitignore .

Python As funções não são atualmente suportadas em projetos com integração Git padrão.

Empregos para scripts ou notebooks

Você pode criar uma tarefa na página Tarefas do seu projeto selecionando Nova tarefa. Em seguida, procure o script ou notebook que deseja usar como ponto de entrada para o trabalho.

Quando o trabalho é iniciado, todo o conteúdo do seu Git clone fica disponível (montado). O notebook ou script que você selecionou como ponto de entrada chama quaisquer outros scripts ou notebooks em seu clone, que por sua vez chamam outros arquivos no projeto. Veja Criando empregos baseados em código.