Compilación de repositorios de GitHub Enterprise Server

Puede integrar el servidor de GitHub Enterprise local con Azure Pipelines. Es posible que el servidor local se exponga a Internet o que no lo sea.

Si el GitHub Enterprise server es accesible desde los servidores que ejecutan Azure Pipelines servicio, a continuación:

• puede configurar la compilación clásica y las canalizaciones YAML.
• puede configurar CI, PR y desencadenadores programados.

Si el servidor GitHub Enterprise no es accesible desde los servidores que ejecutan Azure Pipelines servicio, a continuación:

• solo puede configurar canalizaciones de compilación clásicas
• solo puede iniciar compilaciones manuales o programadas.
• no se pueden configurar canalizaciones 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, debe configurar agentes auto-hospedados que puedan acceder al servidor local y capturar el código.

Accesible desde Azure Pipelines

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

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

Si se supera la comprobación, los servidores que ejecutan Azure Pipelines servicio pueden acceder a su servidor local GitHub Enterprise Server. Puede continuar y configurar la conexión. A continuación, puede usar esta conexión de servicio al crear una compilación clásica o una canalización DE YAML. 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 GitHub Enterprise Server. 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 Azure Pipelines en GitHub Marketplace. Esta aplicación permite configurar una integración sin tener que depender del token de OAuth de un usuario determinado. No tenemos una aplicación similar que funcione con GitHub Enterprise Server. Por lo tanto, debe usar un PAT, un nombre de usuario y una contraseña o OAuth para configurar la conexión entre Azure Pipelines y GitHub Enterprise servidor.
• Al trabajar con GitHub, Azure Pipelines admite una serie de características de seguridad 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 cuando se trabaja con GitHub Enterprise servidor.
• Los desencadenadores de comentario no están disponibles GitHub Enterprise servidor. No puede usar comentarios en una solicitud de GitHub Enterprise de extracción del repositorio del servidor para desencadenar una canalización.
• GitHub Las comprobaciones no están disponibles en GitHub Enterprise servidor. Todas las actualizaciones de estado se encuentran a través de estados básicos.

No se puede acceder desde Azure Pipelines

Cuando se produce un error en la comprobación de una conexión GitHub Enterprise Server, como se explica en la sección anterior, Azure Pipelines puede comunicarse con el servidor. Es probable que esto 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. En este caso, tiene dos opciones:

• Trabaje con el departamento de TI para abrir una ruta de acceso de red entre Azure Pipelines y GitHub Enterprise Server. Por ejemplo, puede agregar excepciones a las reglas de firewall para permitir que el tráfico de Azure Pipelines fluya a través de . Consulte la sección sobre Azure DevOps ips para ver qué direcciones IP debe permitir. Además, debe tener una entrada DNS pública para GitHub Enterprise Server 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 GitHub Enterprise Server en Azure Pipelines.

• En lugar de usar una conexión GitHub Enterprise Server, puede usar otra conexión de Git. Asegúrese de desactivar la opción Para 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 tenga que tomar es si usar agentes hospedados por Microsoft o agentes auto hospedados para ejecutar las canalizaciones. Esto suele decidir si los agentes hospedados por Microsoft pueden llegar 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 extraer el código fuente del servidor. Si esto sucede, puede seguir usando agentes hospedados por Microsoft.

No se puede acceder desde agentes hospedados por Microsoft

Si la canalización de prueba simple mencionada en la sección anterior produce el error , el servidor GitHub Enterprise server no es accesible desde los agentes 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 hospedados por Microsoft. Esto probablemente se deba a un firewall que bloquea el tráfico de estos servidores. En este caso, tiene dos opciones:

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

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

Azure DevOps Direcciones IP

Azure Pipelines envía solicitudes a GitHub Enterprise Server para:

• Consulta de una lista de repositorios durante la creación de canalizaciones (canalizaciones clásicas y YAML)
• Buscar archivos YAML existentes durante la creación de la canalización (canalizaciones de YAML)
• Archivos YAML de registro (canalizaciones de YAML)
• Registro de un webhook durante la creación de la canalización (canalizaciones clásicas y YAML)
• Presentación de un editor para archivos YAML (canalizaciones de YAML)
• Resolución de plantillas y expansión de archivos YAML antes de la ejecución (canalizaciones de YAML)
• Compruebe si hay cambios desde la última ejecución programada (canalizaciones clásicas y YAML)
• Capturar detalles sobre la confirmación más reciente y mostrarla en la interfaz de usuario (canalizaciones clásicas y YAML)

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

Cuando use Otra conexión de Git para configurar una canalización clásica, deshabilite la comunicación entre Azure Pipelines Service y GitHub Enterprise Server y use agentes auto-hospedados para compilar código, tendrá una experiencia degradada:

• Tendrá que escribir el nombre del repositorio manualmente durante la creación de la canalización.
• No se pueden usar desencadenadores de CI o pr Azure Pipelines no se puede registrar un webhook en GitHub Enterprise Server
• No se pueden usar desencadenadores programados con la opción de compilar solo cuando hay cambios.
• No se 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 que habilite la comunicación de Azure Pipelines a GitHub Enterprise Server.

Para permitir que el tráfico de Azure DevOps llegue a GitHub Enterprise Server, agregue las direcciones IP o 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.

Preguntas más frecuentes

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

• Desencadenadores con errores: Mi canalización no se desencadena cuando se inserta una actualización en el repositorio.
• Error de desprotección: Mi canalización se está desencadenando, pero se produce un error en el paso de finalización de la compra.
• Versión incorrecta: Mi canalización se ejecuta, pero usa una versión inesperada del origen o YAML.

Desencadenadores con errores

Acabo de crear una nueva canalización yaml con desencadenadores de CI/PR, pero la canalización no se está desencadenando.

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

• ¿Los desencadenadores de CI o PR de YAML se reemplazan por la configuración de canalización en la interfaz de usuario? Al editar la canalización, elija ... y, a continuación, Desencadenadores.

  

  Compruebe la opción Invalidar el desencadenador YAML desde aquí para ver los tipos de desencadenador (integración continua o validación de solicitud de incorporación de recursos) 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, a continuación, a Webhooks. Compruebe que los webhooks existen. Normalmente debería ver dos webhooks: push, pull_request. Si no lo hace, 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 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 GitHub Enterprise servidor está detrás de un firewall, es posible que este tráfico no llegue al servidor. Consulte Azure DevOps IP y compruebe que ha concedido excepciones a todas las direcciones IP necesarias. Es posible que estas direcciones IP cambien, ya que originalmente ha configurado las reglas de excepción.

• ¿La canalización está en pausa o deshabilitada? Abra el editor de la canalización y, a continuación, 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 ci. 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 pr. Asegúrese de que el archivo YAML de la rama correcta tenga la configuración de CI o PR necesaria.

• ¿Ha configurado el desencadenador correctamente? Al definir un desencadenador YAML, puede especificar cláusulas include y exclude para ramas, etiquetas y rutas de acceso. Asegúrese de que la cláusula include coincide con los detalles de la confirmación y de que la cláusula exclude no las excluye. Compruebe la sintaxis de los desencadenadores y asegúrese de que es precisa.

• ¿Ha usado variables para definir el desencadenador o las rutas de acceso? 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 los desencadenadores definidos dentro de los archivos de plantilla.

• ¿Ha excluido las ramas o rutas de acceso a las que ha incluido los cambios? Pruebe mediante la insertar 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 el mismo caso que el de las carpetas reales al especificar las rutas de acceso en los desencadenadores.

• ¿Acaba de insertar una rama nueva? 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 CI o PR han funcionado bien. Pero ahora han dejado de funcionar.

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

• ¿Tiene conflictos de combinación en la PR? Para una solicitud de solicitud de cambios que no desencadene 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 solicitudes de inserción? Normalmente, puede comprobarlo 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 inserción o una actualización de pr. en cualquiera de los repositorios presenta este síntoma, es posible que experimentemos retrasos en el procesamiento de los eventos de actualización. Compruebe si se está 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 para ver si hay actualizaciones sobre el problema.

Error de desprotección

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

Versión incorrecta

Se usa una versión incorrecta del archivo YAML en la canalización. ¿Por qué ocurre esto?

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