He intentado añadir la integración de herramientas de GitHub a la cadena de herramientas. ¿Por qué no se añade la integración de herramientas?

Debe autorizar en GitHub para que IBM Cloud esté autorizado para acceder a la cuenta de GitHub.

La integración de herramientas de GitHub no se ha añadido a la cadena de herramientas. Si está utilizando Terraform o la API para crear la integración de herramientas de GitHub, el intento falla con el mensaje de error User is not authorized with https://api.github.com.

Si IBM Cloud no está autorizado para acceder a la cuenta de GitHub, la integración de herramientas no se añade a la cadena de herramientas.

Si está configurando la GitHub integración de herramientas mediante la consola mientras crea su cadena de herramientas, siga estos pasos para autorizar con GitHub:

1. En la sección Integraciones configurables, pulse GitHub.

2. Si está creando la cadena de herramientas en IBM Cloud Public y IBM Cloud no está autorizado a acceder a GitHub, seleccione el método de autenticación que se utilizará para acceder a Github.

   • Si elige OAuth, pulse Autorizar para ir al sitio web de GitHub. Si no tiene ninguna sesión de GitHub activa, se le solicitará que inicie sesión. Haga clic en Autorizar IBM para permitir que IBM Cloud acceda a su cuenta de GitHub.
   • Si elige Personal Access Token, especifique una señal de acceso personal válida para GitHub.

Si está utilizando la consola y ya tiene una cadena de herramientas, actualice la configuración de la integración de herramientas de GitHub:

1. Desde la IBM Cloud consola, haz clic en el Menú icono > DevOps. En la página Cadenas de herramientas, pulse la cadena de herramientas para abrir su página Visión general. Como alternativa, en la página Descripción general de la aplicación, en la tarjeta Entrega continua, haga clic en Ver cadena de herramientas > Descripción general.

2. En la página Visión general de la cadena de herramientas, en la tarjeta Repositorios, localice la integración de la herramienta GitHub.

3. Pulse el menú para acceder a las opciones de configuración y actualizar los valores de configuración para autorizar a IBM Cloud el acceso a GitHub.

   • Si elige OAuth, pulse Autorizar para ir al sitio web de GitHub. Si no tiene ninguna sesión de GitHub activa, se le solicitará que inicie sesión. Haga clic en Autorizar IBM para permitir que IBM Cloud acceda a su cuenta de GitHub.
   • Si elige Personal Access Token, proporcione una señal de acceso personal válida para GitHub.

4. Cuando haya terminado de configurar los ajustes, pulse Guardar integración.

Si utiliza Terraform o la API con el método de autenticación OAuth, cambie a utilizar una señal de acceso personal (PAT) para proporcionar acceso granular a un usuario o repositorio específico. Se recomienda autorizar con un PAT cuando se utiliza Terraform o la API. De lo contrario, puede utilizar la consola para autorizar a IBM Cloud a acceder a su cuenta de GitHub:

1. Desde la IBM Cloud consola, haz clic en el Menú icono > DevOps. En la página de cadenas de herramientas, localiza la cadena de herramientas a la que deseas añadir la integración de herramientas de GitHub. Haga clic en la cadena de herramientas para abrir su página de descripción general.
2. En la página Descripción general de la cadena de herramientas, haga clic en Añadir.
3. En la página Añadir integración de herramientas, pulse la tarjeta de herramienta GitHub.
4. En la página Configurar GitHub, pulse Autorizar para ir al sitio web de GitHub. Si no tiene ninguna sesión de GitHub activa, se le solicitará que inicie sesión. Haga clic en Autorizar IBM para permitir que IBM Cloud acceda a su cuenta de GitHub. Se le redirigirá a la página Configurar GitHub.
5. Cierre la página sin realizar ninguna acción adicional en la consola y, a continuación, intente crear de nuevo la integración de la herramienta GitHub con Terraform o la API.

¿Por qué no puedo utilizar la integración de herramientas de Git Repos and Issue Tracking en mi cadena de herramientas en una región de una cadena de herramientas dentro de una región distinta?

No se puede utilizar una instancia de Git Repos and Issue Tracking en varias regiones.

Cuando intento añadir la integración de herramientas de Git Repos and Issue Tracking a mi cadena de herramientas, recibo el siguiente mensaje de error:

Repository URL is not valid. The repository must be on {local GitLab URL}.

Donde {local GitLab URL} es el URL de la integración de herramientas de Git Repos and Issue Tracking, en la región en la que reside la cadena de herramientas.

Puesto que Git Repos and Issue Tracking se integra estrechamente con el servicio Continuous Delivery en la región en la que se ejecuta, no se puede utilizar una instancia de Git Repos and Issue Tracking en varias regiones.

En lugar de crear una integración de herramientas de Git Repos and Issue Tracking, cree una integración de GitLab genérica y utilice esta integración para que apunte al repositorio (repo) de Git Repos and Issue Tracking en una región distinta.

1. Desde la IBM Cloud consola, haz clic en el Menú icono > DevOps. En página Cadenas de herramientas, pulse la cadena de herramientas a la que desea añadir esta integración. Si lo prefiere, en la página Visión general de la app, en la tarjeta de Entrega continua, pulse Ver cadena de herramientas y luego Visión general.

2. Pulse Añadir herramienta.

3. En la sección Integraciones de herramientas, pulse GitLab.

4. Pulse el servidor de GitLab que desee utilizar. Si el servidor de GitLab en el que reside el repositorio al que desea acceder no aparece en esta lista, añada un servidor personalizado:

   a. Haga clic en Servidor personalizado.

   b. Escriba un nombre para el servidor. Este nombre de servidor aparecerá en la lista de servidores de GitLab disponibles.

   c. Escriba el URL raíz del servidor de GitLab personalizado.

   d. Especifique una señal de acceso personal para el servidor de GitLab personalizado. Si no tiene una señal de acceso personal, cree una.

5. Si tiene un repositorio de GitLab y desea utilizarlo, para el tipo de repositorio, pulse Existente y escriba el URL.

6. Si desea utilizar un repositorio de GitLab nuevo, escriba un nombre para el repositorio, escriba el URL para el repositorio que esté clonando o bifurcando, y seleccione el tipo de repositorio:

   a. Para crear un repositorio vacío, pulse Nuevo.

   b. Para crear una copia de un repositorio de GitLab, pulse Clonar.

   c. Para bifurcar un repositorio de GitLab para que pueda aportar cambios a través de solicitudes de fusión, pulse Bifurcar.

7. Si desea crear un repositorio público en el servidor, desmarque el recuadro de selección Convertir este repositorio en privado.

8. Si desea utilizar los problemas de GitLab para el seguimiento de problemas, marque el recuadro de selección Habilitar problemas de GitLab.

9. Si desea realizar un seguimiento del despliegue de cambios en el código mediante la creación de etiquetas y comentarios en las confirmaciones, y etiquetas y comentarios en los problemas a los que hacen referencia las confirmaciones, marque el recuadro de selección Hacer un seguimiento del despliegue cambios de código. Para obtener más información, consulte Seguimiento de la implantación del código con cadenas de herramientas.

10. Pulse Crear integración.

Para obtener más información sobre la configuración de una integración de herramientas de GitLab, consulte Configuración de GitLab.

¿Por qué no puedo clonar mi repositorio de Git Repos and Issue Tracking a través de https?

Debe utilizar una señal de acceso personal o una clave SSH para realizar operaciones de Git.

Intenta enviar por push o clonar un repositorio desde la línea de mandatos utilizando https y no puede autenticarse aunque haya especificado la contraseña correcta.

Git Repos and Issue Tracking utiliza un mecanismo de inicio de sesión único que no da soporte a la autenticación de Git que utiliza un nombre de usuario y una contraseña en la línea de mandatos.

Para realizar operaciones de Git como, por ejemplo, clonar o enviar por push, debe utilizar una señal de acceso personal o una clave SSH. Para obtener más información sobre la creación de una señal de acceso personal o una clave SSH, consulte la Guía de aprendizaje de iniciación.

¿Por qué se me solicita que me autentique cuando intento clonar mi repositorio de Git Repos and Issue Tracking mediante SSH?

Es posible que haya problemas con la ubicación o los permisos para la clave SSH privada, o que la línea de mandatos de Git no esté utilizando la clave SSH privada para la autenticación con Git Repos and Issue Tracking.

He añadido mi clave pública SSH mediante la interfaz de usuario de Git Repos and Issue Tracking. Cuando intento clonar un repositorio mediante SSH, se me solicita una contraseña o un código de seguridad, o se muestra un mensaje de error que indica que la autenticación ha fallado.

A raíz de los problemas de SSH siguientes, puede recibir una solicitud de autenticación o puede aparecer un mensaje de error:

• Es posible que la línea de mandatos de Git no esté utilizando la clave SSH privada para la autenticación con Git Repos and Issue Tracking.

• Es posible que la clave SSH privada no esté en la ubicación ~/.ssh/id_rsa predeterminada.

• Es posible que la clave SSH privada no tenga los permisos correctos (600).

Utilice cualquiera de los métodos siguientes para resolver este problema:

• Si utiliza la ubicación de clave SSH privada predeterminada, verifique los permisos de la carpeta ~/.ssh/ y el archivo de claves privadas ~/.ssh/id_rsa. Si los permisos son demasiado amplios, de forma predeterminada SSH no utiliza una clave privada. Asegúrese de que los permisos de la carpeta ~/.ssh/ se establecen en 700 y los permisos de la carpeta ~/.ssh/id_rsa se establecen en 600.

• Si la clave privada no se encuentra en la ubicación predeterminada, utilice el mandato siguiente para especificarlo en una variable de entorno:

  GIT_SSH_COMMAND='ssh -i/path/to/private_key_file' git clone git@host:owner/repo.git

• Para depurar este problema mediante la información de conexión, añada el distintivo -v o -vvv a la variable de entorno GIT_SSH_COMMAND:

  GIT_SSH_COMMAND='ssh -vvv git clone git@host:owner/repo.git

  GIT_SSH_COMMAND='ssh -vvv -i/path/to/private_key_file' git clone git@host:owner/repo.git

He intentado obtener cambios de mi repositorio Git Repos and Issue Tracking, ¿por qué aparece un error 504 Gateway Time-out?

El repositorio tiene un tamaño superior a 1 GB. El sistema de gestión de control de origen de Git no se ha diseñado para almacenar archivos binarios de gran tamaño.

Cuando intento completar una operación sobre un repositorio de Git Repos and Issue Tracking (como captar o clonar), he recibido un mensaje de error:

git fetch error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out fatal: The remote end hung up unexpectedly

Tiene un repositorio grande con un tamaño superior a 1 GB. El repositorio podría contener también archivos binarios que requieren más espacio que los archivos txt que están almacenados en un formato comprimido.

Para resolver este problema, puede utilizar cualquiera de los métodos siguientes:

• Reduzca el tamaño del repositorio de Git Repos and Issue Tracking. Para más información sobre cómo reducir el tamaño de su repositorio, vea Reducir el tamaño del repositorio usando Git.

• Utilice SSH para ignorar el tiempo de espera de clonación predeterminado de 180 segundos.

• Si está intentando clonar un repositorio, lleve a cabo una clonación poco profunda (git clone --depth) para reducir la cantidad de datos que se transfieren truncando el historial de confirmaciones. Para más información sobre cómo completar un clon superficial, consulta la documentación de ReferenciaGit.

He intentado añadir un usuario a mi proyecto de GitLab por correo electrónico, pero no ha recibido la invitación. ¿Cómo puedo añadirlo a mi proyecto?

La invitación puede estar bloqueada por el correo electrónico del usuario.

He invitado a un usuario a mi proyecto de GitLab utilizando su dirección de correo electrónico, que aparece en Git Repos and Issue Tracking, pero no ha recibido el correo electrónico.

El correo electrónico puede estar bloqueado por los filtros de correo no deseado de la bandeja de entrada de usuario.

Para resolver este problema, puede utilizar cualquiera de los métodos siguientes:

• Compruebe la carpeta de correo no deseado del correo electrónico para determinar si la invitación de correo electrónico se ha marcado como correo no deseado. Los correos electrónicos se envían desde una dirección noreply@. Actualice los filtros de correo no deseado para permitir correos electrónicos de esta dirección.

• Investigue si los filtros corporativos de correo no deseado que están fuera del control del usuario están bloqueando el correo electrónico. Solicite al usuario que inicie la sesión en la interfaz de usuario de Git Repos and Issue Tracking y que le envíe su ID de usuario. Puede añadir el usuario al proyecto de GitLab utilizando su ID de usuario.

Cuando utilizo Terraform para actualizar la configuración de una integración de herramientas Git existente, ¿por qué falla la configuración?

El recurso de integración de herramientas Git especifica un type de clone, fork o new, y especifica un repositorio de destino existente.

Cuando se utiliza Terraform para actualizar una integración de herramienta Git, la configuración falla con el mensaje de error The nonempty repository _REPO-URL_ already exists. Either delete the repository or change the Repository Type to 'Existing', donde REPO-URL es el URL del repositorio de destino.

Este error suele deberse a las acciones siguientes:

• El recurso Terraform de integración de herramientas Git especifica un type de clone, fork o new. Ha cambiado el repo_url dentro del bloque initialization del recurso al URL de un repositorio que existe.
• El recurso Terraform de integración de herramientas Git especifica un type de clone, fork o new. No ha cambiado repo_url, pero ha cambiado uno o más argumentos dentro del bloque initialization del recurso. En esta situación, el repositorio existe porque se creó cuando Terraform aplicó previamente el recurso de integración de herramientas Git.

Los tipos clone, fork y new indican a la integración de herramientas Git que cree el repositorio de destino (repo_url) en la premisa de que este repositorio no existe. Si la integración de herramientas encuentra el repositorio de destino, falla por diseño.

Cambie type de clone, fork o new a clone_if_not_exists, fork_if_not_exists o new_if_not_exists. Estos tipos indican a la integración de herramientas de Git que cree el repositorio de destino si no existe, o que utilice el repositorio de destino tal cual si existe.

Aunque puede utilizar otros métodos para resolver este error, estos métodos no se recomiendan porque puede perder información. Estos métodos también pueden requerir cambios en Terraform que no son buenas prácticas.

• Cambie repo_url por un repositorio que se cree cuando vuelva a aplicar Terraform. El cambio de un recurso de Terraform después de la creación inicial para evitar errores durante las actualizaciones posteriores es un anti-patrón. Este método también deja intacto el repositorio creado anteriormente, pero ya no está enlazado a la cadena de herramientas.
• Cambie type por existing y, a continuación, vuelva a aplicar Terraform. El cambio de un recurso de Terraform después de la creación inicial para evitar errores durante las actualizaciones posteriores es un anti-patrón.
• Suprima manualmente el repositorio de destino y, a continuación, vuelva a aplicar Terraform. No se recomiendan cambios manuales entre operaciones de Terraform automatizadas de otro modo. Si suprime el repositorio, la supresión no se puede deshacer y puede provocar una pérdida de datos permanente.