Por lo menos hasta la versión 10.0.5, el «integrar» a la herramienta con un servicio Git (GitLab, GitHub, Bitbucket) es una pesadilla. ¿Es sencillo? ¿Es estable? ¿Es confiable? No, parece, tal vez, esas serían las respuestas. En la entrada previa mencionaba grosso modo los pasos a seguir para esto. Voy a hacer algunas precisiones y adiciones con el propósito de cerrar esta serie de entradas pero creo que habrá algunas adicionales en el futuro.

1.- Generación de llaves

Para el caso de macOS esto se lleva a cabo con el comando ssh-keygen, que preguntará por la ruta donde guardar el archivo de la llave y si se usará una frase (passphrase) como password. Mientras que la ruta puede ser cualquiera, se recomienda hacer uso de la ruta y nombre de archivo por defecto, pues es lo que Dataiku buscará (ejemplo) y no hace uso de una passphrase. La llave debe ser tipo RSA. Para copiar la llave al clipboard usar:

$ cd $HOME
$ cd .ssh
$ pbcopy <id_rsa.pub

2.- Registro de la llave

Para el caso de GitHub, hay dos opciones de registro de la llave pública (archivo con extensión .pub). Una es a nivel de cuenta (clic en el icono de usuario y luego en Settings > SSH and GPG keys). Esta opción tiene la desventaja de conferir acceso a quien haga uso de la llave a todos los repositorios. La otra alternativa limita el uso de la llave a un repositorio: clic en Settings del menú del repositorio y luego buscar en la opción Deploy Keys. En el registro se debe marcar que se permitirá tener acceso para escribir en el repositorio.

3.- Configuración en Dataiku

En Dataiku, dentro del proyecto, mediante la opción de menú … (tres puntos), se buscará Version Control. Después de dar clic se mostrará una barra de sub menú que indicará la rama actual y a su lado un indicados de cambios por subir o bajar que permite mostrar la opción de agregar un remote (un repositorio remoto). El enlace remoto a registrar debe ser el de SSH que tiene una forma como git@github.com:usuario/repositorio.git y que de obtiene de la interfaz de GitHub. Hecho esto, viene la primer parte complicada.

La documentación de Dataiku es pobre y muy obscura a este respecto. Por una parte pareciera indicar que el DataScienceStudio (DSS) esta diseñado para fácilmente integrarse y sacar provecho de los servicios Git pero se enfoca mucho a la librerías de código y plug-ins. Las respuestas a las preguntas de los usuarios en sus foros (o algunos otros) vuelven a recitar mucho de lo que la documentación indica pero es demasiado escueta en términos de sincronizar todo el proyecto con el servio Git (inlcuso se menciona que idealmente debe tratarse de un repositorio vacío). Quizás esto funciona bien (y lo dudo) con un proyecto que apenas inicio pero ¿qué pasa con los ya arrancados o cuándo se debe invitar a otros participantes? Es aquí donde inicia la pesadilla. Para ello se debe proceder de esta forma:

1. Crear el proyecto en el DSS, como uno «en blanco».
2. Registrar en Version Control el repositorio y que sea exitoso.
3. El registro permite que se activen otras opciones; hacer un Fetch y comprobar que se exitoso.
4. Desde una sesión en terminal, mediante una línea de comando, quitar del camino al archivo .gitignore:
   $ cd /Users/<user>/Library/DataScienceStudio/dss_home/config/projects/<proyecto>
$ git add .gitignore
$ git stash
$ git branch --set-upstream-to=origin/master master
$ git pull --allow-unrelated-histories
5. En este punto se indicará que hay conflictos que deben resolverse con el archivo params.json. Se deben resolver a favor del HEAD.
6. Terminada la edición:
   $ git add params.json
$ git commit -m 'Conflicts resolution for HEAD in params.json'
$ git push
$ git pull
7. Validar que las operaciones de pull y push funcionen en el DSS.
8. Regresar a la sesión de terminal y deshacerse del stash.
   $ git stash drop

Tras esto el servicio del repositorio Git queda debidamente sincronizado y lo que sigue es disciplina.

4.- Uso

Pese a lo que Dataiku indique, lo cierto es que el uso de Git en su producto se ve forzado. Primero, cuando en el proyecto «se crea una rama» se debe en realidad duplicar el proyecto. Segundo, cualquier conflicto git debe ser atendido por fuera del DSS. Tercero, debe ser uno muy cuidadoso y disciplinado para mantener debidamente actualizada su rama (debe evitarse que dos o más personas trabajen en una misma rama).

¿Y los merge? Eso parece una pesadilla aún por resolver y revisar en otro post.