Clonar el proyecto en RStudio Server (una vez que se suba del local al remoto)
Clonar el proyecto una vez que el colaborador inicial lo haya subido a GitLab
Una de estas se presentó de inmediato en el cual una vez que un colaborador sube su repositorio a GitLab (artículo pasado) al entrar en juego un segundo colaborador si bien le permitió clonar el proyecto sin problema al intentar hacer un commit (modificación del proyecto) usando la interfaz de RStudio Server se lanza el siguiente error.
>>> /usr/bin/git commit -F /tmp/RtmpstQ7JZ/git-commit-message-d1a0f631ec45a.txt --gpg-signerror: gpg failed to sign the data:
gpg: omitido "nombre apellido <usuario@correo.com.mx>": No tenemos la clave secreta
[GNUPG:] INV_SGNR 9 Nombre Apellido <usuario@correo.com.mx>
[GNUPG:] FAILURE sign 17
gpg: signing fail
ed: No tenemos la clave secreta
fatal: falló al escribir el objeto commit
La modificación en esta ocasión fue no agregar un script sino modificar el existente (se agrega una CURP para calcular su dígito).
La explicación es que por alguna razón el usuario definió en el software GIT "firmar" con clave GPG, y al no existir esta firma no permite hacer el "commit".
Por lo que lo que se tuvo que hacer fue forzarlo usando la terminal y el comando de Git directamente.
usuario@equipo:~/Ruta$ commit -m "agregue una CURP" --no-gpg-sign
[master 71b5ccc] agregue una CURP
1 file changed, 4 insertions(+), 2 deletions(-)
Lo que se hace es poner la opción --no-gpg-sign y con ello se puede hacer el "commit".
Del mismo modo para hacer las operaciones "push" se hacen también usando la instrucción con la consola.
usuario@equipo:~/Ruta$git push -u origin master
En la siguiente ventana podemos observar que el "push" se
Se tiene que realizar otras pruebas (casos de uso) para ver y asegurar que los cambios en el repositorio se realicen de forma exitosa.Hasta el siguiente artículo.
Miguel Araujo.
Comentarios
Publicar un comentario