Compilación de repositorios de GitHub Enterprise Server

Azure DevOps Services

Puede integrar el servidor local de GitHub Enterprise con Azure Pipelines. Su servidor local puede estar expuesto a Internet o no.

Si se puede acceder al servidor de GitHub Enterprise desde los servidores que ejecutan el servicio Azure Pipelines, entonces:

• puede configurar canalizaciones de compilación y YAML clásicas.
• puede configurar desencadenadores de CI, PR y programados.

Si no se puede acceder al servidor de GitHub Enterprise desde los servidores que ejecutan el servicio Azure Pipelines, entonces:

• solo puede configurar canalizaciones de compilación clásicas.
• solo puede iniciar compilaciones manuales o programadas.
• no puede configurar canalizaciones de YAML.
• no puede configurar desencadenadores de CI o PR para las canalizaciones de compilación clásicas.

Si el servidor local es accesible desde agentes hospedados por Microsoft, puede usarlos para ejecutar las canalizaciones. De lo contrario, deberá configurar agentes autohospedados que puedan acceder al servidor local y capturar el código.

Accesible desde Azure Pipelines

Lo primero que hay que comprobar es si el servidor de GitHub Enterprise es accesible desde el servicio Azure Pipelines.

1. En la interfaz de usuario de Azure DevOps, vaya a la configuración del proyecto y seleccione Conexiones de servicio en Canalizaciones.
2. Seleccione Nueva conexión de servicio y elija Servidor de GitHub Enterprise como tipo de conexión.
3. Escriba la información necesaria para crear una conexión al servidor de GitHub Enterprise.
4. Seleccione Comprobar en el panel de conexión de servicio.

Si se supera la comprobación, los servidores que ejecutan el servicio Azure Pipelines pueden acceder al servidor de GitHub Enterprise local. Puede continuar y configurar la conexión. A continuación, puede usar esta conexión de servicio al crear una canalización de YAML o de compilación clásica. También puede configurar desencadenadores de CI y PR para la canalización. La mayoría de las características de Azure Pipelines que funcionan con GitHub también funcionan con el servidor de GitHub Enterprise. Revise la documentación de GitHub para comprender estas características. Estas son algunas diferencias:

• La integración entre GitHub y Azure Pipelines se facilita a través de una aplicación de Azure Pipelines en el Marketplace de GitHub. Esta aplicación permite configurar una integración sin tener que confiar en el token de OAuth de un usuario determinado. No tenemos una aplicación similar que funcione con el servidor de GitHub Enterprise. Por lo tanto, debe usar un token de acceso personal, un nombre de usuario y una contraseña, o OAuth para configurar la conexión entre Azure Pipelines y el servidor de GitHub Enterprise.
• Azure Pipelines admite varias características de seguridad de GitHub para validar las contribuciones de bifurcaciones externas. Por ejemplo, los secretos almacenados en una canalización no están disponibles para un trabajo en ejecución. Estas protecciones no están disponibles al trabajar con el servidor de GitHub Enterprise.
• Los desencadenadores de comentarios no están disponibles con el servidor de GitHub Enterprise. No puede usar comentarios en una solicitud de incorporación de cambios del repositorio de servidor de GitHub Enterprise para desencadenar una canalización.
• Las comprobaciones de GitHub no están disponibles en el servidor de GitHub Enterprise. Todas las actualizaciones de estado se realizan a través de estados básicos.

No accesible desde Azure Pipelines

Cuando se produce un error en la comprobación de una conexión del servidor de GitHub Enterprise como se explica en la sección anterior, Azure Pipelines no puede comunicarse con el servidor. Esto es probable que se deba a la configuración de la red empresarial. Por ejemplo, un firewall de la red puede impedir que el tráfico externo llegue a los servidores. Tiene dos opciones en este caso:

• Trabaje con el departamento de TI para abrir una ruta de acceso de red entre Azure Pipelines y el servidor de GitHub Enterprise. Por ejemplo, puede agregar excepciones a las reglas de firewall para permitir que fluya el tráfico de Azure Pipelines. Consulte la sección sobre direcciones IP de Azure DevOps para ver qué direcciones IP debe permitir. Además, debe tener una entrada DNS pública para el servidor de GitHub Enterprise para que Azure Pipelines pueda resolver el FQDN del servidor en una dirección IP. Con todos estos cambios, intente crear y comprobar una conexión del servidor de GitHub Enterprise en Azure Pipelines.

• En lugar de usar una conexión del servidor de GitHub Enterprise, puede usar una conexión Otro Git. Asegúrese de desactivar la opción Intentar acceder a este servidor Git desde Azure Pipelines. Con este tipo de conexión, solo puede configurar una canalización de compilación clásica. Los desencadenadores de CI y PR no funcionarán en esta configuración. Solo puede iniciar ejecuciones de canalización manuales o programadas.

Accesible desde agentes hospedados por Microsoft

Otra decisión que posiblemente tiene que tomar es si usar agentes hospedados por Microsoft o agentes autohospedados para ejecutar las canalizaciones. Esto suele reducirse a si los agentes hospedados por Microsoft pueden acceder al servidor. Para comprobar si pueden, cree una canalización sencilla para usar agentes hospedados por Microsoft y asegúrese de agregar un paso para comprobar el código fuente del servidor. Si es correcto, puede seguir usando agentes hospedados por Microsoft.

No accesible desde agentes hospedados por Microsoft

Si se produce un error en la canalización de prueba simple mencionada en la sección anterior con el mensaje TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, no se puede acceder al servidor de GitHub Enterprise desde agentes hospedados por Microsoft. De nuevo, probablemente se deba a que hay un firewall que bloquea el tráfico de estos servidores. Tiene dos opciones en este caso:

• Trabaje con el departamento de TI para abrir una ruta de acceso de red entre agentes hospedados por Microsoft y el servidor de GitHub Enterprise. Consulte la sección sobre redes en los agentes hospedados por Microsoft.

• Empiece a usar agentes autohospedados o agentes de conjunto de escalado. Estos agentes se pueden configurar dentro de la red y, por tanto, tendrán acceso al servidor de GitHub Enterprise. Estos agentes solo requieren conexiones salientes a Azure Pipelines. No es necesario abrir un firewall para las conexiones entrantes. Asegúrese de que el nombre del servidor especificado al crear la conexión del servidor de GitHub Enterprise se pueda resolver desde los agentes autohospedados.

Direcciones IP de Azure DevOps

Azure Pipelines envía solicitudes al servidor de GitHub Enterprise para:

• Consultar una lista de repositorios durante la creación de canalizaciones (canalizaciones clásicas y YAML)
• Buscar archivos YAML existentes durante la creación de canalizaciones (canalizaciones YAML)
• Proteger archivos YAML (canalizaciones de YAML)
• Registrar un webhook durante la creación de canalizaciones (canalizaciones clásicas y YAML)
• Presentar un editor para archivos YAML (canalizaciones de YAML)
• Resolver plantillas y expandir archivos YAML antes de la ejecución (canalizaciones de YAML)
• Comprobar si hay cambios desde la última ejecución programada (canalizaciones clásicas y YAML)
• Capturar detalles sobre la confirmación más reciente y mostrarlos en la interfaz de usuario (canalizaciones clásicas y YAML)

Puede observar que las canalizaciones YAML requieren fundamentalmente la comunicación entre Azure Pipelines y el servidor de GitHub Enterprise. Por lo tanto, no es posible configurar una canalización YAML si el servidor de GitHub Enterprise no está visible para Azure Pipelines.

Cuando use una conexión Otro Git para configurar una canalización clásica, deshabilite la comunicación entre el servicio Azure Pipelines y el servidor de GitHub Enterprise y use agentes autohospedados para compilar código, obtendrá una experiencia degradada:

• Tendrá que escribir el nombre del repositorio manualmente durante la creación de la canalización.
• No puede usar desencadenadores de CI o PR, ya que Azure Pipelines no puede registrar un webhook en el servidor de GitHub Enterprise.
• No puede usar desencadenadores programados con la opción de compilar solo cuando hay cambios.
• No puede ver información sobre la confirmación más reciente en la interfaz de usuario.

Si desea configurar canalizaciones YAML o si desea mejorar la experiencia con canalizaciones clásicas, es importante habilitar la comunicación desde Azure Pipelines al servidor de GitHub Enterprise.

Para permitir que el tráfico de Azure DevOps llegue al servidor de GitHub Enterprise, agregue las direcciones IP o las etiquetas de servicio especificadas en Conexiones entrantes a la lista de permitidos del firewall. Si usa ExpressRoute, asegúrese de incluir también intervalos IP de ExpressRoute en la lista de permitidos del firewall.

Limitaciones

• Para obtener el mejor rendimiento, se recomienda un máximo de 50 canalizaciones en un único repositorio. Para obtener un rendimiento aceptable, se recomienda un máximo de 100 canalizaciones en un único repositorio. El tiempo necesario para procesar una inserción en un repositorio aumenta con el número de canalizaciones de ese repositorio. Cada vez que hay una inserción en un repositorio, Azure Pipelines debe cargar todas las canalizaciones de YAML en ese repositorio para averiguar si alguna de ellas debe ejecutarse, y la carga de cada canalización incurre en una penalización de rendimiento. Además de los problemas de rendimiento, tener demasiadas canalizaciones en un único repositorio puede dar lugar a una limitación en el lado de GitHub, ya que Azure Pipelines puede realizar demasiadas solicitudes en un breve período de tiempo.

• El uso de las plantillas extends e include en una canalización afecta a la velocidad a la que Azure Pipelines realiza solicitudes de API de GitHub y puede dar lugar a una limitación en el lado de GitHub. Antes de ejecutar una canalización, Azure Pipelines debe generar el código YAML completo, por lo que debe capturar todos los archivos de plantilla.

• Azure Pipelines carga un máximo de 2000 ramas de un repositorio en listas desplegables del Portal de Azure DevOps, por ejemplo, en la ventana Seleccione una rana para la configuración de Rama predeterminada para compilaciones manuales y programadas o al elegir una rama al ejecutar una canalización manualmente.

  Si no ve la rama deseada en la lista, escriba el nombre de la rama deseada manualmente en el campo Rama predeterminada para compilaciones manuales y programadas.

  Si hace clic en los puntos suspensivos y abre el cuadro de diálogo Seleccione una rama y lo cierra sin elegir una rama válida en la lista desplegable, es posible que vea un mensaje de Algunos valores requieren atención y Este valor es necesario debajo de Rama predeterminada para compilaciones manuales y programadas. Para solucionar este mensaje, vuelva a abrir la canalización y escriba el nombre directamente en el campo Rama predeterminada para compilaciones manuales y programadas.

Preguntas más frecuentes

Los problemas relacionados con la integración de GitHub Enterprise se dividen en las siguientes categorías:

• Desencadenadores con errores: mi canalización no se desencadena cuando inserto una actualización en el repositorio.
• Error de restauración: mi canalización se desencadena, pero se produce un error en el paso de restauración.
• Versión incorrecta: mi canalización se ejecuta, pero usa una versión inesperada del código fuente o YAML.

Desencadenadores con errores

Acabo de crear una nueva canalización de YAML con desencadenadores de CI/PR, pero la canalización no se desencadena.

Siga cada uno de estos pasos para solucionar problemas relacionados con los desencadenadores con errores:

• ¿Se reemplazan los desencadenadores CI o PR YAML por la configuración de las canalizaciones en la interfaz de usuario? Al editar la canalización, elija ... y, luego, Desencadenadores.

  

  Compruebe la opción de configuración Invalidar el desencadenador de YAML desde aquí para los tipos de desencadenador (integración continua o validación de solicitudes de incorporación de cambios) disponibles para el repositorio.

  

• Los webhooks se usan para comunicar actualizaciones de GitHub Enterprise a Azure Pipelines. En GitHub Enterprise, vaya a la configuración del repositorio y, luego, a Webhooks. Compruebe que existen los webhooks. Normalmente debería ver dos webhooks: push, pull_request. Si no es así, debe volver a crear la conexión de servicio y actualizar la canalización para usar la nueva conexión de servicio.

• Seleccione cada uno de los webhooks de GitHub Enterprise y compruebe que la carga que corresponde a la confirmación del usuario existe y se envió correctamente a Azure DevOps. Es posible que vea un error aquí si el evento no se pudo comunicar a Azure DevOps.

• Cuando Azure Pipelines recibe una notificación de GitHub, intenta ponerse en contacto con GitHub y obtener más información sobre el repositorio y el archivo YAML. Si el servidor de GitHub Enterprise está detrás de un firewall, es posible que este tráfico no llegue al servidor. Consulte Direcciones IP de Azure DevOps y compruebe que haya concedido excepciones a todas las direcciones IP necesarias. Estas direcciones IP pueden haber cambiado desde que configuró al principio las reglas de excepción.

• ¿La canalización está en pausa o deshabilitada? Abra el editor de la canalización y seleccione Configuración para comprobarlo. Si la canalización está en pausa o deshabilitada, los desencadenadores no funcionan.

• ¿Ha actualizado el archivo YAML en la rama correcta? Si inserta una actualización en una rama, el archivo YAML de esa misma rama rige el comportamiento de la integración continua. Si inserta una actualización en una rama de origen, el archivo YAML resultante de combinar la rama de origen con la rama de destino rige el comportamiento de la solicitud de incorporación de cambios. Asegúrese de que el archivo YAML de la rama correcta tiene la configuración de integración continua o solicitud de incorporación de cambios necesaria.

• ¿Ha configurado el desencadenador correctamente? Al definir un desencadenador de YAML, puede especificar cláusulas de inclusión y exclusión de ramas, etiquetas y rutas de acceso. Asegúrese de que la cláusula de inclusión coincida con los detalles de la confirmación y que la cláusula de exclusión no los excluya. Compruebe la sintaxis de los desencadenadores y asegúrese de que es correcta.

• ¿Ha usado variables para definir el desencadenador o las rutas de acceso? Esto no se admite.

• ¿Ha usado plantillas para el archivo YAML? Si es así, asegúrese de que los desencadenadores estén definidos en el archivo YAML principal. No se admiten desencadenadores definidos dentro de los archivos de plantilla.

• ¿Ha excluido las ramas o rutas de acceso en las que insertó los cambios? Para comprobarlo, inserte un cambio en una ruta de acceso incluida en una rama incluida. Tenga en cuenta que las rutas de acceso de los desencadenadores distinguen mayúsculas de minúsculas. Asegúrese de usar las mismas mayúsculas o minúsculas que en las carpetas reales al especificar las rutas de acceso en los desencadenadores.

• ¿Acaba de insertar una nueva rama? Si es así, es posible que la nueva rama no inicie una nueva ejecución. Consulte la sección "Comportamiento de los desencadenadores cuando se crean nuevas ramas".

Mis desencadenadores de integración continua o de solicitud de incorporación de cambios funcionaban bien. Sin embargo, ahora no funcionan.

En primer lugar, siga los pasos de solución de problemas de la pregunta anterior y siga estos pasos adicionales:

• ¿Tiene conflictos de combinación en la solicitud de incorporación de cambios? Si una solicitud de incorporación de cambios no ha desencadenado una canalización, ábrala y compruebe si tiene un conflicto de combinación. Resuelva el conflicto de combinación.

• ¿Experimenta un retraso en el procesamiento de eventos de inserción o de solicitud de incorporación de cambios? Para comprobar un retraso, observe si el problema es específico de una sola canalización o es común a todas las canalizaciones o repositorios del proyecto. Si una actualización de inserción o de solicitud de incorporación de cambios en cualquiera de los repositorios muestra este síntoma, podríamos estar experimentando retrasos en el procesamiento de los eventos de actualización. Estos son algunos de los motivos por los que puede producirse un retraso:

  • Estamos experimentando una interrupción del servicio en nuestra página de estado. Si la página de estado muestra un problema, nuestro equipo debe haber empezado a trabajar en él. Compruebe la página con frecuencia por si hay actualizaciones del problema.
  • El repositorio contiene demasiadas canalizaciones YAML. Para obtener el mejor rendimiento, se recomienda un máximo de 50 canalizaciones en un único repositorio. Para obtener un rendimiento aceptable, se recomienda un máximo de 100 canalizaciones en un único repositorio. Cuantas más canalizaciones haya, más lento será el procesamiento de una inserción en ese repositorio. Cada vez que se inserta en un repositorio, Azure Pipelines debe cargar todas las canalizaciones YAML de ese repositorio, para averiguar si alguna de ellas necesita ejecutarse y cada canalización nueva conlleva una penalización de rendimiento.
  • La instancia de GitHub Enterprise Server puede estar infraaprovisionada, lo que ralentiza las solicitudes de procesamiento de Azure Pipelines. Obtenga más información sobre las consideraciones de hardware para GitHub Enterprise Server.

Error en la restauración

¿Usa agentes hospedados por Microsoft? Si es así, es posible que estos agentes no puedan acceder a el servidor de GitHub Enterprise. Consulte No accesible desde agentes hospedados por Microsoft para obtener más información.

Versión incorrecta

En la canalización se usa una versión incorrecta del archivo YAML. ¿A qué se debe?

• En el caso de los desencadenadores de integración continua, el archivo YAML que se encuentra en la rama que va a insertar se evalúa para ver si se debe ejecutar una compilación de integración continua.
• En el caso de los desencadenadores de solicitud de incorporación de cambios, el archivo YAML resultante de combinar las ramas de origen y destino de la solicitud de incorporación de cambios se evalúa para ver si se debe ejecutar una compilación de solicitud de incorporación de cambios.