Compilación de repositorios de GitHub

Azure DevOps Services

Azure Pipelines puede crear y validar automáticamente todas las solicitudes de incorporación de cambios y confirmaciones en el repositorio de GitHub. En este artículo, se describe cómo configurar la integración entre GitHub y Azure Pipelines.

Si no está familiarizado con la integración de canalizaciones con GitHub, siga los pasos descritos en Creación de su primera canalización. Vuelva a este artículo para obtener más información sobre cómo configurar y personalizar la integración entre GitHub y Azure Pipelines.

Organizaciones y usuarios

GitHub y Azure Pipelines son dos servicios independientes que se integran bien juntos. Cada uno de ellos tiene su propia organización y administración de usuarios. En esta sección, se hace una recomendación sobre cómo replicar la organización y los usuarios de GitHub en Azure Pipelines.

Las organizaciones

La estructura de GitHub consta de organizaciones y cuentas de usuario que contienen repositorios. Consulte la documentación de GitHub.

La estructura de Azure DevOps consiste en organizaciones que contienen proyectos. Consulte Planeamiento de la estructura de la organización.

Azure DevOps puede reflejar la estructura de GitHub con:

• Una organización de DevOps para la organización o la cuenta de usuario de GitHub
• Proyectos de DevOps para los repositorios de GitHub

Para configurar una estructura idéntica en Azure DevOps:

1. Cree una organización de DevOps con el nombre de su organización o cuenta de usuario de GitHub. Tendrá una dirección URL como https://dev.azure.com/your-organization.
2. En la organización de DevOps, cree proyectos con el nombre de sus repositorios. Tendrán direcciones URL como https://dev.azure.com/your-organization/your-repository.
3. En el proyecto de DevOps, cree canalizaciones con el nombre de la organización de GitHub y el repositorio que compilan, como your-organization.your-repository. De este modo, queda claro para qué repositorios son.

Siguiendo este patrón, los repositorios de GitHub y los proyectos de Azure DevOps tendrán rutas de dirección URL coincidentes. Por ejemplo:

Usuarios

Los usuarios de GitHub no obtienen acceso automáticamente a Azure Pipelines. Azure Pipelines no tiene conocimiento de las identidades de GitHub. Por este motivo, no hay ninguna manera de configurar Azure Pipelines para notificar automáticamente a los usuarios un error de compilación o un error de validación de solicitudes de incorporación de cambios mediante su identidad de GitHub y su dirección de correo electrónico. Debe crear explícitamente nuevos usuarios en Azure Pipelines para replicar los usuarios de GitHub. Una vez creados nuevos usuarios, puede configurar sus permisos en Azure DevOps para reflejar sus permisos en GitHub. También puede configurar notificaciones en DevOps mediante su identidad de DevOps.

Roles de organización de GitHub

Los roles de los miembros de la organización de GitHub se encuentran en https://github.com/orgs/your-organization/people (reemplace your-organization).

Los permisos de los miembros de la organización de DevOps se encuentran en https://dev.azure.com/your-organization/_settings/security (reemplace your-organization).

A continuación, se muestran los roles de una organización de GitHub y los roles equivalentes de una organización de Azure DevOps.

Roles de cuenta de usuario de GitHub

Una cuenta de usuario de GitHub tiene un rol, que es propiedad de la cuenta.

Los permisos de los miembros de la organización de DevOps se encuentran en https://dev.azure.com/your-organization/_settings/security (reemplace your-organization).

El rol de cuenta de usuario de GitHub se asigna a los permisos de la organización de DevOps como se indica a continuación.

Permisos de repositorio de GitHub

Los permisos del repositorio de GitHub se encuentran en https://github.com/your-organization/your-repository/settings/collaboration (reemplace your-organization y your-repository).

Los permisos del proyecto de DevOps se encuentran en https://dev.azure.com/your-organization/your-project/_settings/security (reemplace your-organization y your-project).

Los permisos equivalentes entre repositorios de GitHub y proyectos de Azure DevOps son los siguientes.

Si el repositorio de GitHub concede permiso a equipos, puede crear equipos coincidentes en la sección Teams de la configuración del proyecto de Azure DevOps. A continuación, agregue los equipos a los grupos de seguridad anteriores, al igual que los usuarios.

Permisos específicos de la canalización

Para conceder permisos a usuarios o equipos para canalizaciones específicas en un proyecto de DevOps, siga estos pasos:

1. Visite la página Canalizaciones del proyecto (por ejemplo, https://dev.azure.com/your-organization/your-project/_build).
2. Seleccione la canalización para la que se van a establecer permisos específicos.
3. En el menú contextual "...", seleccione Seguridad.
4. Seleccione Agregar... para agregar un usuario, un equipo o un grupo específicos y personalizar sus permisos para la canalización.

Acceso a repositorios de GitHub

Se debe conceder acceso a Azure Pipelines a los repositorios para desencadenar sus compilaciones y recuperar su código durante las compilaciones.

Hay tres tipos de autenticación para conceder acceso a Azure Pipelines a los repositorios de GitHub al crear una canalización.

Autenticación de aplicaciones de GitHub

La aplicación de GitHub de Azure Pipelines es el tipo de autenticación recomendado para las canalizaciones de integración continua. Después de instalar la aplicación de GitHub en la cuenta u organización de GitHub, la canalización se ejecutará sin usar su identidad personal de GitHub. Las compilaciones y las actualizaciones de estado de GitHub se realizarán mediante la identidad de Azure Pipelines. La aplicación funciona con comprobaciones de GitHub para mostrar resultados de compilación, prueba y cobertura de código en GitHub.

Para usar la aplicación de GitHub, instálela en la organización o en la cuenta de usuario de GitHub de algunos o todos los repositorios. La aplicación de GitHub se puede instalar y desinstalar desde la página principal de la aplicación.

Después de la instalación, la aplicación de GitHub se convertirá en el método predeterminado de autenticación de Azure Pipelines en GitHub (en lugar de OAuth) cuando se creen canalizaciones para los repositorios.

Si instala la aplicación de GitHub para todos los repositorios de una organización de GitHub, no es necesario preocuparse de que Azure Pipelines envíe correos electrónicos masivos ni configure automáticamente canalizaciones en su nombre. Como alternativa a instalar la aplicación para todos los repositorios, los administradores del repositorio pueden instalarla para repositorios individuales de uno en uno. Esto requiere más trabajo para los administradores, pero no tiene ninguna ventaja ni desventaja.

Permisos necesarios en GitHub

La instalación de la aplicación gitHub de Azure Pipelines requiere que sea propietario de la organización de GitHub o administrador del repositorio. Además, para crear una canalización para un repositorio de GitHub con desencadenadores de integración continua y solicitud de incorporación de cambios, debe tener configurados los permisos de GitHub necesarios. De lo contrario, el repositorio no aparecerá en la lista de repositorios al crear una canalización. En función del tipo de autenticación y la propiedad del repositorio, asegúrese de que esté configurado el acceso adecuado.

• Si el repositorio está en su cuenta personal de GitHub, instale la aplicación de GitHub de Azure Pipelines en su cuenta personal de GitHub y podrá enumerar este repositorio al crear la canalización en Azure Pipelines.

• Si el repositorio está en la cuenta personal de GitHub de otra persona, la otra persona debe instalar la aplicación de GitHub de Azure Pipelines en su cuenta personal de GitHub. Debe haber sido agregado como colaborador en la configuración del repositorio, en "Colaboradores". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico. Una vez hecho esto, puede crear una canalización para ese repositorio.

• Si el repositorio está en una organización de GitHub de su propiedad, instale la aplicación de GitHub de Azure Pipelines en la organización de GitHub. También debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos".

• Si el repositorio está en una organización de GitHub propiedad de otra persona, un propietario de la organización de GitHub o un administrador del repositorio debe instalar la aplicación de GitHub de Azure Pipelines en la organización. Debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico.

Permisos de aplicaciones de GitHub

La aplicación de GitHub solicita los siguientes permisos durante la instalación:

Solución de problemas de instalación de la aplicación de GitHub

GitHub puede mostrar un error como, por ejemplo:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Esto significa que es probable que la aplicación de GitHub ya esté instalada para su organización. Al crear una canalización para un repositorio de la organización, se usará automáticamente la aplicación de GitHub para conectarse a GitHub.

Creación de canalizaciones en varias organizaciones y proyectos de Azure DevOps

Una vez instalada la aplicación de GitHub, se pueden crear canalizaciones para los repositorios de la organización en diferentes proyectos y organizaciones de Azure DevOps. Sin embargo, si crea canalizaciones para un único repositorio en varias organizaciones de Azure DevOps, solo las confirmaciones o solicitudes de incorporación de cambios de GitHub pueden desencadenar automáticamente las canalizaciones de la primera organización. Las compilaciones manuales o programadas siguen siendo posibles en organizaciones secundarias de Azure DevOps.

Autenticación de OAuth

OAuth es el tipo de autenticación más sencilla con la que empezar a trabajar en repositorios de la cuenta personal de GitHub. Las actualizaciones de estado de GitHub se realizarán en nombre de su identidad personal de GitHub. Para que las canalizaciones sigan funcionando, el acceso al repositorio debe permanecer activo. Algunas características de GitHub, como Comprobaciones, no están disponibles con OAuth y requieren la aplicación de GitHub.

Para usar OAuth, seleccione Seleccionar otra conexión debajo de la lista de repositorios al crear una canalización. A continuación, seleccione Autorizar para iniciar sesión en GitHub y autorizar con OAuth. Se guardará una conexión OAuth en su proyecto de Azure DevOps para su uso posterior y para su uso en la canalización que se va a crear.

Permisos necesarios en GitHub

Para crear una canalización para un repositorio de GitHub con desencadenadores de integración continua y solicitud de incorporación de cambios, debe tener configurados los permisos de GitHub necesarios. De lo contrario, el repositorio no aparecerá en la lista de repositorios al crear una canalización. En función del tipo de autenticación y la propiedad del repositorio, asegúrese de que esté configurado el acceso adecuado.

• Si el repositorio está en su cuenta personal de GitHub, al menos una vez, autentíquese en GitHub con OAuth con sus credenciales de la cuenta personal de GitHub. Esto se puede hacer en la configuración del proyecto de Azure DevOps en Canalizaciones > Conexiones de servicio > Nueva conexión de servicio > GitHub > Autorizar. Conceda a Azure Pipelines acceso a los repositorios en "Permisos" aquí.

• Si el repositorio está en la cuenta personal de GitHub de otra persona, al menos una vez, la otra persona debe autenticarse en GitHub con OAuth con sus credenciales de la cuenta personal de GitHub. Esto se puede hacer en la configuración del proyecto de Azure DevOps en Canalizaciones > Conexiones de servicio > Nueva conexión de servicio > GitHub > Autorizar. La otra persona debe conceder a Azure Pipelines acceso a sus repositorios en "Permisos" aquí. Debe haber sido agregado como colaborador en la configuración del repositorio, en "Colaboradores". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico.

• Si el repositorio está en una organización de GitHub de su propiedad, al menos una vez, autentíquese en GitHub con OAuth con las credenciales de la cuenta personal de GitHub. Esto se puede hacer en la configuración del proyecto de Azure DevOps en Canalizaciones > Conexiones de servicio > Nueva conexión de servicio > GitHub > Autorizar. Conceda a Azure Pipelines acceso a su organización en "Acceso a la organización" aquí. Debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos".

• Si el repositorio está en una organización de GitHub propiedad de otra persona, al menos una vez, el propietario de la organización de GitHub se debe autenticar en GitHub con OAuth con las credenciales de su cuenta personal de GitHub. Esto se puede hacer en la configuración del proyecto de Azure DevOps en Canalizaciones > Conexiones de servicio > Nueva conexión de servicio > GitHub > Autorizar. El propietario de la organización debe conceder a Azure Pipelines acceso a la organización en "Acceso a la organización" aquí. Debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico.

Revocar el acceso de OAuth

Después de autorizar a Azure Pipelines a usar OAuth, para revocarlo más adelante y evitar su uso posterior, visite Aplicaciones de OAuth en la configuración de GitHub. También puede eliminarlo de la lista de conexiones de servicio de GitHub en la configuración del proyecto de Azure DevOps.

Autenticación de token de acceso personal (PAT)

Los PAT son efectivamente lo mismo que OAuth, pero permiten controlar qué permisos se conceden a Azure Pipelines. Las compilaciones y las actualizaciones de estado de GitHub se realizarán en nombre de su identidad personal de GitHub. Para que las compilaciones sigan funcionando, el acceso al repositorio debe permanecer activo.

Para crear un PAT, visite Tokens de acceso personal en la configuración de GitHub. Los permisos necesarios son repo, admin:repo_hook, read:user y user:email. Estos son los mismos permisos necesarios al usar OAuth anteriormente. Copie el PAT generado en el Portapapeles y péguelo en una nueva conexión de servicio de GitHub en la configuración del proyecto de Azure DevOps. Para facilitar una recuperación futura, asigne un nombre a la conexión de servicio en función de su nombre de usuario de GitHub. Estará disponible en el proyecto de Azure DevOps para su uso posterior al crear canalizaciones.

Permisos necesarios en GitHub

Para crear una canalización para un repositorio de GitHub con desencadenadores de integración continua y solicitud de incorporación de cambios, debe tener configurados los permisos de GitHub necesarios. De lo contrario, el repositorio no aparecerá en la lista de repositorios al crear una canalización. En función del tipo de autenticación y la propiedad del repositorio, asegúrese de que esté configurado el acceso siguiente.

• Si el repositorio está en su cuenta personal de GitHub, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: repo, admin:repo_hook, read:user y user:email.

• Si el repositorio está en la cuenta personal de GitHub de otra persona, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: repo, admin:repo_hook, read:user y user:email. Debe haber sido agregado como colaborador en la configuración del repositorio, en "Colaboradores". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico.

• Si el repositorio está en una organización de GitHub de su propiedad, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: repo, admin:repo_hook, read:user y user:email. Debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos".

• Si el repositorio está en una organización de GitHub propiedad de otra persona, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: repo, admin:repo_hook, read:user y user:email. Debe haber sido agregado como colaborador (o su equipo debe haber sido agregado) en la configuración del repositorio en "Colaboradores y equipos". Acepte la invitación para ser un colaborador mediante el vínculo que se le envía por correo electrónico.

Revocar el acceso con PAT

Después de autorizar a Azure Pipelines a usar un PAT, para eliminarlo más adelante y evitar su uso, visite Tokens de acceso personal en la configuración de GitHub. También puede eliminarlo de la lista de conexiones de servicio de GitHub en la configuración del proyecto de Azure DevOps.

Desencadenadores de integración continua

Los desencadenadores de integración continua (CI) hacen que una canalización se ejecute siempre que inserte una actualización en las ramas especificadas o inserte etiquetas especificadas.

trigger:
- main
- releases/*

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

# A pipeline with no CI trigger
trigger: none

Omisión de la integración continua para confirmaciones individuales

También puede indicar a Azure Pipelines que omita la ejecución de una canalización que normalmente desencadenaría una inserción. Solo tiene que incluir [skip ci] en el mensaje o descripción de cualquiera de las confirmaciones que forman parte de una inserción y Azure Pipelines omitirá la ejecución de CI para esta inserción. También puede usar algunas de las variaciones siguientes.

• [skip ci] o [ci skip]
• skip-checks: true o skip-checks:true
• [skip azurepipelines] o [azurepipelines skip]
• [skip azpipelines] o [azpipelines skip]
• [skip azp] o [azp skip]
• ***NO_CI***

Uso del tipo de desencadenador en condiciones específicas

Es un escenario común para ejecutar diferentes pasos, trabajos o fases en la canalización en función del tipo de desencadenador que inició la ejecución. Puede hacerlo mediante la variable Build.Reason del sistema. Por ejemplo, agregue la siguiente condición al paso, trabajo o fase para excluirla de las validaciones de PR.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportamiento de los desencadenadores cuando se crean nuevas ramas

Es habitual configurar varias canalizaciones para el mismo repositorio. Por ejemplo, puede que tenga una canalización para compilar los documentos de la aplicación y otra para compilar el código fuente. Puede configurar desencadenadores de CI con filtros para ramas adecuados y filtros de ruta de acceso en cada una de estas canalizaciones. Por ejemplo, puede que desee que una canalización se desencadene al insertar una actualización en la carpeta docs y otra para desencadenarla al insertar una actualización en el código de la aplicación. En estos casos, debe comprender cómo se desencadenan las canalizaciones cuando se crea una nueva rama.

Este es el comportamiento al insertar una nueva rama (que coincide con los filtros para ramas) en el repositorio:

• Si la canalización tiene filtros de ruta de acceso, solo se desencadenará si la nueva rama tiene cambios en los archivos que coinciden con ese filtro de ruta de acceso.
• Si la canalización no tiene filtros de ruta de acceso, se desencadenará aunque no haya cambios en la nueva rama.

Caracteres comodín

Al especificar una rama, etiqueta o ruta de acceso, puede usar un nombre exacto o un carácter comodín. Los patrones de caracteres comodín permiten * coincidencias con cero o más caracteres y ? con un solo carácter.

• Si inicia el patrón con * en una canalización de YAML, debe encapsular el patrón entre comillas, como "*-releases".
• Para ramas y etiquetas:
  • Un carácter comodín puede aparecer en cualquier parte del patrón.
• Para rutas de acceso:
  • En Azure DevOps Server 2022 y versiones posteriores, incluida Azure DevOps Services, un carácter comodín puede aparecer en cualquier parte de un patrón de ruta de acceso y puede usar * o ?.
  • En Azure DevOps Server 2020 y versiones anteriores, puede incluirlo * como carácter final, pero no realiza nada diferente a especificar el nombre del directorio por sí mismo. Es posible que no pueda incluirlo* en medio de un filtro de ruta de acceso y que no pueda usar ?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Desencadenadores de solicitud de incorporación de cambios

Los desencadenadores de solicitud de incorporación de cambios (PR) hacen que se ejecute una canalización cada vez que se abre una solicitud de incorporación de cambios con una de las ramas de destino especificadas, o bien cuando se realizan actualizaciones en esa solicitud de incorporación de cambios.

pr:
- main
- releases/*

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

# no PR triggers
pr: none

Si tiene una solicitud de incorporación de cambios abierta e inserta cambios en su rama de origen, es posible que se ejecuten varias canalizaciones:

• Las canalizaciones que tienen un desencadenador de solicitud de incorporación de cambios en la rama de destino de la solicitud de incorporación de cambios se ejecutarán en la confirmación de combinación (el código combinado entre las ramas de origen y destino de la solicitud de incorporación de cambios), independientemente de si existen confirmaciones insertadas cuyos mensajes o descripciones contengan [skip ci] (o cualquiera de sus variantes).
• Las canalizaciones desencadenadas por cambios en la rama de origen de la solicitud de incorporación de cambios, si no hay confirmaciones insertadas cuyos mensajes o descripciones contengan [skip ci] (o cualquiera de sus variantes). Si al menos una confirmación insertada contiene [skip ci], las canalizaciones no se ejecutarán.

Por último, después de combinar la solicitud de incorporación de cambios, Azure Pipelines ejecutará las canalizaciones de CI desencadenadas por inserciones en la rama de destino si el mensaje o la descripción de la confirmación de combinación no contiene [skip ci] (o cualquiera de sus variantes).

Ramas protegidas

Puede ejecutar una compilación de validación con cada confirmación o solicitud de incorporación de cambios destinada a una rama, e incluso evitar que se combinen las solicitudes de incorporación de cambios hasta que una compilación de validación se realice correctamente.

Para configurar compilaciones de validación obligatorias para un repositorio de GitHub, debe ser su propietario, un colaborador con el rol de administrador o un miembro de la organización de GitHub con el rol de escritura.

1. En primer lugar, cree una canalización para el repositorio y compílela al menos una vez para que su estado se publique en GitHub, lo que hace que GitHub tenga en cuenta el nombre de la canalización.

2. A continuación, siga la documentación de GitHub para configurar ramas protegidas en la configuración del repositorio.

   Para la comprobación de estado, seleccione el nombre de la canalización en la lista Comprobaciones de estado.

   

Contribuciones de orígenes externos

Si el repositorio de GitHub es de código abierto, puede hacer que el proyecto de Azure DevOps sea público para que cualquiera pueda ver los resultados de compilación, los registros y los resultados de prueba de la canalización sin iniciar sesión. Cuando los usuarios externos a la organización bifurcan el repositorio y envían solicitudes de incorporación de cambios, pueden ver el estado de las compilaciones que validan automáticamente esas solicitudes de incorporación de cambios.

Debe tener en cuenta las siguientes consideraciones al usar Azure Pipelines en un proyecto público al aceptar contribuciones de orígenes externos.

• Restricciones de acceso
• Validación de contribuciones de bifurcaciones
• Consideraciones importantes de seguridad

Restricciones de acceso

Tenga en cuenta las siguientes restricciones de acceso al ejecutar canalizaciones en proyectos públicos de Azure DevOps:

• Secretos: de manera predeterminada, los secretos asociados a la canalización no están disponibles para validar solicitudes de incorporación de cambios de las bifurcaciones. Consulte Validación de contribuciones de bifurcaciones.
• Acceso entre proyectos: todas las canalizaciones de un proyecto público de Azure DevOps se ejecutan con un token de acceso restringido al proyecto. Las canalizaciones de un proyecto público pueden acceder a recursos como artefactos de compilación o resultados de prueba solo dentro del proyecto y no en otros proyectos de la organización de Azure DevOps.
• Paquetes de Azure Artifacts: si las canalizaciones necesitan acceso a los paquetes de Azure Artifacts, debe conceder explícitamente permiso a la cuenta Project Build Service para acceder a las fuentes de paquetes.

Contribuciones de bifurcaciones

Al crear una canalización, se desencadena automáticamente para las solicitudes de incorporación de cambios de las bifurcaciones del repositorio. Puede cambiar este comportamiento, teniendo en cuenta cuidadosamente cómo afecta a la seguridad. Para habilitar o deshabilitar este comportamiento:

1. Vaya al proyecto de Azure DevOps. Seleccione Canalizaciones, busque la canalización y seleccione Editar.
2. Seleccione la pestaña Desencadenadores. Después de habilitar el desencadenador de solicitud de incorporación de cambios, habilite o deshabilite la casilla Compilar solicitudes de incorporación de cambios desde las bifurcaciones de este repositorio.

De manera predeterminada con las canalizaciones de GitHub, los secretos asociados a la canalización de compilación no están disponibles para las compilaciones de las solicitudes de incorporación de cambios de las bifurcaciones. Estos secretos están habilitados de manera predeterminada con las canalizaciones de GitHub Enterprise Server. Los secretos incluyen:

• Un token de seguridad con acceso al repositorio de GitHub.
• Estos elementos, si la canalización los usa:
  • Credenciales de la conexión de servicio
  • Archivos de la biblioteca de archivos seguros
  • Variables de compilación marcadas como secretas

Para omitir esta precaución en las canalizaciones de GitHub, habilite la casilla Poner secretos a disposición de las compilaciones de bifurcaciones. Tenga en cuenta el efecto de esta configuración en la seguridad.

Para obtener más información, consulte Protección del repositorio: bifurcaciones.

Puede definir de forma centralizada cómo las canalizaciones compilan solicitudes de incorporación de cambios desde repositorios de GitHub bifurcadas mediante el control Limitar solicitudes de incorporación de cambios de compilación de repositorios de GitHub bifurcadas. Está disponible en el nivel de organización y proyecto. Puede optar por:

• Deshabilitación de la creación de solicitudes de incorporación de cambios desde repositorios bifurcados
• Compilación segura de solicitudes de incorporación de cambios desde repositorios bifurcados
• Personalización de reglas para compilar solicitudes de incorporación de cambios desde repositorios bifurcados

A partir de Sprint 229, para mejorar la seguridad de las canalizaciones, Azure Pipelines ya no compila automáticamente las solicitudes de incorporación de cambios de repositorios de GitHub bifurcados. En el caso de los nuevos proyectos y organizaciones, el valor predeterminado de la configuración Limitar la compilación de solicitudes de incorporación de cambios de repositorios de GitHub bifurcados es Deshabilitar la compilación de solicitudes de incorporación de cambios de repositorios bifurcados.

Al elegir la opción Compilar de forma segura las solicitudes de incorporación de cambios de repositorios bifurcadas, todas las canalizaciones, la organización o todo el proyecto, no pueden hacer que los secretos estén disponibles para las compilaciones de PR desde repositorios bifurcados, no pueden hacer que estas compilaciones tengan los mismos permisos que las compilaciones normales y deben desencadenarse mediante un comentario de solicitud de incorporación de cambios. Los proyectos todavía pueden decidir no permitir que las canalizaciones compilen dichas solicitudes de incorporación de cambios.

Al elegir la opción Personalizar, puede definir cómo restringir la configuración de canalización. Por ejemplo, puede asegurarse de que todas las canalizaciones requieran un comentario para crear un PR a partir de un repositorio de GitHub bifurcado, cuando el PR pertenece a personas que no son miembros del equipo ni contribuyentes. Sin embargo, puede optar por permitir que los secretos estén disponibles para dichas compilaciones. Los proyectos pueden decidir no permitir que las canalizaciones compilen dichas solicitudes de incorporación de cambios, o que las compilen de forma segura, o que tengan una configuración aún más restrictiva que la especificada en el nivel de organización.

El control está desactivado para las organizaciones existentes. A partir de septiembre de 2023, las nuevas organizaciones tienen activadas de manera predeterminada solicitudes de incorporación de cambios de compilación segura de repositorios bifurcadas.

Consideraciones importantes de seguridad

Un usuario de GitHub puede bifurcar el repositorio, cambiarlo y crear una solicitud de incorporación de cambios para proponer cambios en el repositorio. Esta solicitud de incorporación de cambios podría contener código malintencionado para ejecutarse como parte de la compilación desencadenada. Este código puede causar daños de las siguientes maneras:

• Filtrar secretos de la canalización. Para mitigar este riesgo, no habilite la casilla Poner secretos a disposición de las compilaciones de bifurcaciones si el repositorio es público o los usuarios que no son de confianza pueden enviar solicitudes de incorporación de cambios que desencadenen automáticamente compilaciones. Esta opción está deshabilitada de manera predeterminada.

• Poner en peligro la máquina que ejecuta el agente para robar código o secretos de otras canalizaciones. Para mitigar esto:

  • Use un grupo de agentes hospedado por Microsoft para compilar las solicitudes de incorporación de cambios de las bifurcaciones. Las máquinas del agente hospedado por Microsoft se eliminan inmediatamente después de completar una compilación, por lo que no hay ningún impacto duradero si están en peligro.

  • Si debe usar un agente autohospedado, no almacene ningún secreto ni realice otras compilaciones y versiones que usen secretos en el mismo agente, a menos que el repositorio sea privado y confíe en los creadores de las solicitudes de incorporación de cambios.

Desencadenadores de comentarios

Los colaboradores del repositorio pueden comentar una solicitud de incorporación de cambios para ejecutar manualmente una canalización. Estos son algunos motivos comunes por los que puede querer hacerlo:

• Es posible que no desee compilar automáticamente las solicitudes de incorporación de cambios de usuarios desconocidos hasta que se puedan revisar sus cambios. Quiere que uno de los miembros del equipo revise primero su código y, a continuación, ejecutar la canalización. Esto se usa normalmente como medida de seguridad al compilar código aportado desde repositorios bifurcados.
• Es posible que desee ejecutar un conjunto de pruebas opcional o una compilación de validación más.

Para habilitar desencadenadores de comentarios, debe seguir los dos pasos siguientes:

1. Habilite los desencadenadores de solicitud de incorporación de cambios para la canalización y asegúrese de que no ha excluido la rama de destino.
2. En el portal web de Azure Pipelines, edite la canalización y elija Más acciones, Desencadenadores. A continuación, en Validación de las solicitudes de incorporación de cambios, habilite Requerir el comentario de un miembro del equipo antes de compilar una solicitud de incorporación de cambios.
   • Seleccione En todas las solicitudes de incorporación de cambios para requerir el comentario de un miembro del equipo antes de compilar una solicitud de incorporación de cambios. Con este flujo de trabajo, un miembro del equipo revisa la solicitud de incorporación de cambios y desencadena la compilación con un comentario una vez que la solicitud de incorporación de cambios se considera segura.
   • Seleccione Solo en las solicitudes de incorporación de cambios de miembros que no son del equipo para requerir el comentario de un miembro del equipo solo cuando alguien que no sea miembro del equipo realice una solicitud de incorporación de cambios. En este flujo de trabajo, un miembro del equipo no necesita una revisión secundaria de un miembro del equipo para desencadenar una compilación.

Con estos dos cambios, la compilación de validación de solicitudes de incorporación de cambios no se desencadenará automáticamente, a menos que esté seleccionada la opción Solo en las solicitudes de incorporación de cambios de miembros que no son del equipo y la solicitud de incorporación de cambios la realice un miembro del equipo. Solo los propietarios y colaboradores del repositorio con permiso de "escritura" pueden desencadenar la compilación comentando en la solicitud de incorporación de cambios con /AzurePipelines run o /AzurePipelines run <pipeline-name>.

Se pueden emitir los comandos siguientes a Azure Pipelines en comentarios:

Solución de problemas de desencadenadores de comentarios de solicitud de incorporación de cambios

Si tiene los permisos del repositorio necesarios, pero las canalizaciones no se desencadenan mediante los comentarios, asegúrese de que su pertenencia sea pública en la organización del repositorio o agréguese directamente como colaborador del repositorio. Las canalizaciones no pueden ver a los miembros privados de la organización a menos que sean colaboradores directos o pertenezcan a un equipo que sea un colaborador directo. Puede cambiar la pertenencia a la organización de GitHub de privada a pública aquí (reemplace Your-Organization por el nombre de la organización): https://github.com/orgs/Your-Organization/people.

Ejecuciones informativas

Una ejecución informativa indica que Azure DevOps no pudo recuperar el código fuente de una canalización YAML. La recuperación del código fuente se produce en respuesta a eventos externos, por ejemplo, una confirmación insertada. También ocurre en respuesta a los desencadenadores internos, por ejemplo, para comprobar si hay cambios en el código e iniciar una ejecución programada o no. La recuperación del código fuente puede producir un error por varias razones, siendo una de las más frecuentes la limitación de solicitudes por parte del proveedor del repositorio de Git. La existencia de una ejecución informativa no significa necesariamente que Azure DevOps vaya a ejecutar la canalización.

Una ejecución informativa es similar a la de la captura de pantalla siguiente.

Puede reconocer una ejecución informativa por los atributos siguientes:

• El estado es Canceled.
• La duración es < 1s.
• El nombre de la ejecución contiene uno de los siguientes textos:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• El nombre de la ejecución contiene generalmente el error de BitBucket o GitHub que hizo que no se pudiera cargar la canalización de YAML.
• Sin fases, trabajos o pasos

Más información sobre las ejecuciones informativas.

Restauración

Cuando se desencadena una canalización, Azure Pipelines extrae el código fuente del repositorio de Git de Azure Repos. Puede controlar varios aspectos de su funcionamiento.

Versión preferida de Git

El agente de Windows incluye su propia copia de Git. Si prefiere proporcionar su propio Git en lugar de usar la copia incluida, establezca System.PreferGitFromPath en true. Esta configuración siempre es TRUE en agentes que no son de Windows.

Restauración de rutas de acceso

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submódulos

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

La canalización de compilación restaurará los submódulos de Git siempre que sean:

• Sin autenticar: Un repositorio público y no autenticado sin credenciales necesarias para clonar o capturar.

• Autenticado:

  • Incluido en el mismo proyecto que el repositorio de Git de Azure Repos especificado anteriormente. Las mismas credenciales que usa el agente para obtener los orígenes del repositorio principal se usan para obtener los orígenes de los submódulos.

  • Se ha agregado mediante una dirección URL relativa al repositorio principal. Por ejemplo

    • Esta se restauraría: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      En este ejemplo, el submódulo hace referencia a un repositorio (FabrikamFiber) en la misma organización de Azure DevOps, pero en un proyecto diferente (FabrikamFiberProject). Las mismas credenciales que usa el agente para obtener los orígenes del repositorio principal se usan para obtener los orígenes de los submódulos. Esto requiere que el token de acceso al trabajo tenga acceso al repositorio en el segundo proyecto. Si ha restringido el token de acceso al trabajo como se explica en la sección anterior, no podrá hacerlo. Puede permitir que el token de acceso al trabajo acceda al repositorio del segundo proyecto mediante (a) conceder explícitamente acceso a la cuenta del servicio de compilación del proyecto en el segundo proyecto o (b) mediante tokens de acceso con ámbito de recopilación en lugar de tokens de ámbito de proyecto para toda la organización. Para más información sobre estas opciones y sus implicaciones de seguridad, consulte Acceso a repositorios, artefactos y otros recursos.

    • Este no se restauraría: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativa al uso de la opción Desprotección de submódulos

En algunos casos, no se puede usar la opción Desprotección de submódulos. Es posible que tenga un escenario en el que se necesite un conjunto diferente de credenciales para acceder a los submódulos. Esto puede ocurrir, por ejemplo, si el repositorio principal y los repositorios de los submódulos no se almacenan en la misma organización de Azure DevOps o si el token de acceso al trabajo no tiene acceso al repositorio en un proyecto diferente.

Si no puede usar la opción Desprotección de submódulos, puede usar un paso de script personalizado para recuperar submódulos. En primer lugar, obtenga un token de acceso personal (PAT) y añada un prefijo con pat:. A continuación, codifique en Base64 esta cadena con prefijo para crear un token de autenticación básico. Por último, agregue este script a la canalización:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Asegúrese de reemplazar "<BASE64_ENCODED_STRING>" por la cadena "pat:token" codificada en Base64.

Use una variable secreta en el proyecto o la canalización de compilación para almacenar el token de autenticación básico que generó. Use esa variable para rellenar el secreto en el comando de Git anterior.

Sincronizar etiquetas

El paso de restauración usa la opción --tags de recuperar el contenido de un repositorio de Git. Esto hace que el servidor recupere todas las etiquetas, así como todos los objetos a los que apuntan esas etiquetas. Esto aumenta el tiempo para ejecutar la tarea en una canalización, especialmente si tiene un repositorio grande con una serie de etiquetas. Además, el paso de restauración sincroniza las etiquetas incluso cuando se habilita la opción de recuperación superficial, lo que posiblemente acaba con su propósito. Para reducir la cantidad de datos recuperados o extraídos de un repositorio de Git, Microsoft ha agregado una nueva opción para restaurar y controlar el comportamiento de las etiquetas de sincronización. Esta opción está disponible tanto en canalizaciones clásicas como en YAML.

Si desea sincronizar etiquetas al restaurar un repositorio, se puede configurar en YAML estableciendo la propiedad fetchTags y en la interfaz de usuario mediante la configuración de etiquetas de sincronización.

steps:
- checkout: self
  fetchTags: true

Comportamiento predeterminado

• En el caso de las canalizaciones existentes creadas antes del lanzamiento del sprint 209 de Azure DevOps, publicada en septiembre de 2022, el valor predeterminado de las etiquetas de sincronización sigue siendo el mismo que el comportamiento existente antes de agregar las opciones de etiquetas de sincronización, que es true.
• En el caso de las nuevas canalizaciones creadas después del sprint 209 de Azure DevOps, el valor predeterminado de las etiquetas de sincronización es false.

Recuperación de cambios superficiales

Es posible que quiera limitar la distancia de la descarga del historial. De hecho, esto da como resultado git fetch --depth=n. Si el repositorio es grande, esta opción podría hacer que la canalización de compilación sea más eficaz. El repositorio puede ser grande si ha estado en uso durante mucho tiempo y tiene un historial considerable. También puede ser grande si ha agregado y eliminado archivos grandes más adelante.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

En estos casos, esta opción puede ayudarle a conservar los recursos de red y almacenamiento. También puede ahorrar tiempo. La razón por la que no siempre ahorra tiempo es que, en algunas situaciones, es posible que el servidor tenga que dedicar tiempo a calcular las confirmaciones para descargar a la profundidad que especifique.

No sincronizar orígenes

Es posible que quiera omitir la recuperación de nuevas confirmaciones. Esta opción puede ser útil en los casos en los que desee:

• iniciar, configurar y recuperar en Git con sus propias opciones personalizadas.

• usar una canalización de compilación para ejecutar la automatización (por ejemplo, algunos scripts) y que no dependa del código en el control de versiones.

steps:
- checkout: none  # Don't sync sources

Limpiar compilación

Puede realizar diferentes formas de limpieza del directorio de trabajo del agente autohospedado antes de que se ejecute una compilación.

En general, para un rendimiento más rápido de los agentes autohospedados, no limpie el repositorio. En este caso, para obtener el mejor rendimiento, asegúrese de que también está compilando incrementalmente; para ello, deshabilite cualquier opción Limpiar de la tarea o herramienta que esté usando para compilar.

Si necesita limpiar el repositorio (por ejemplo, para evitar problemas causados por archivos residuales de una compilación anterior), se indican las opciones a continuación.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

git clean -ffdx
git reset --hard HEAD

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Etiquetar orígenes

Es posible que quiera etiquetar los archivos de código fuente para permitir que su equipo identifique fácilmente qué versión de cada archivo se incluye en la compilación completada. También tiene la opción de especificar si el código fuente debe etiquetarse para todas las compilaciones o solo para compilaciones correctas.

En formato de etiquetas puede usar variables definidas por el usuario y predefinidas que tengan un ámbito de "All". Por ejemplo:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Las cuatro primeras variables están predefinidas. My.Variable puede definirlas en la pestaña variables.

La canalización de compilación etiqueta los orígenes con una etiqueta Git.

Algunas variables de compilación pueden producir un valor que no sea una etiqueta válida. Por ejemplo, variables como $(Build.RequestedFor) y $(Build.DefinitionName) pueden contener espacios en blanco. Si el valor contiene espacios en blanco, la etiqueta no se crea.

Una vez que la canalización de compilación etiquete los orígenes, se agrega automáticamente un artefacto con la referencia refs/tags/{tag} de Git a la compilación completada. Esto proporciona a su equipo una rastreabilidad adicional y una manera más fácil de navegar desde la compilación hasta el código compilado. La etiqueta se considera un artefacto de compilación, ya que la compilación la genera. Cuando la compilación se elimina manualmente o mediante una directiva de retención, la etiqueta también se elimina.

Variables predefinidas

Al compilar un repositorio de GitHub, la mayoría de las variables predefinidas están disponibles para los trabajos. Sin embargo, dado que Azure Pipelines no reconoce la identidad de un usuario que realiza una actualización en GitHub, las siguientes variables se establecen en la identidad del sistema en lugar de en la identidad del usuario:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Actualizaciones de estado

Hay dos tipos de estados que Azure Pipelines publica de nuevo en GitHub: estados básicos y Ejecuciones de comprobación de GitHub. La funcionalidad Comprobaciones de GitHub solo está disponible con aplicaciones de GitHub.

Los estados de la canalización se muestran en varios lugares de la interfaz de usuario de GitHub.

• En el caso de las solicitudes de incorporación de cambios, se muestran en la pestaña Conversaciones de PR.
• En el caso de las confirmaciones individuales, se muestran al mantener el puntero sobre la marca de estado después de la hora de confirmación en la pestaña de confirmaciones del repositorio.

Conexiones con PAT o OAuth de GitHub

En el caso de las canalizaciones que usan conexiones de GitHub con PAT u OAuth, los estados se devuelven a la confirmación o la solicitud de incorporación de cambios que desencadenó la ejecución. La API de estado de GitHub se usa para publicar estas actualizaciones. Estos estados contienen información limitada: estado de la canalización (error, correcto), dirección URL para volver a vincular a la canalización de compilación y una breve descripción del estado.

Los estados de las conexiones con PAT u OAuth de GitHub solo se envían en el nivel de ejecución. En otras palabras, puede tener un único estado actualizado para toda una ejecución. Si tiene varios trabajos en una ejecución, no puede publicar un estado independiente para cada trabajo. Sin embargo, varias canalizaciones pueden publicar estados independientes en la misma confirmación.

Comprobaciones de GitHub

En el caso de las canalizaciones configuradas mediante la aplicación de GitHub de Azure Pipelines, el estado se devuelve en forma de comprobaciones de GitHub. Las comprobaciones de GitHub permiten enviar información detallada sobre el estado y la prueba de la canalización, la cobertura de código y los errores. La API de comprobaciones de GitHub se puede encontrar aquí.

Para cada canalización que usa la aplicación de GitHub, se devuelven comprobaciones para la ejecución general y cada trabajo de esa ejecución.

GitHub permite tres opciones cuando una o varias ejecuciones de comprobación producen un error en una solicitud de incorporación de cambios o una confirmación. Puede elegir "volver a ejecutar" la comprobación individual, volver a ejecutar todas las comprobaciones con errores en esa solicitud de incorporación de cambios o confirmación, o volver a ejecutar todas las comprobaciones, independientemente de si se realizaron correctamente inicialmente o no.

Al hacer clic en el vínculo "Volver a ejecutar" situado junto al nombre de la ejecución de comprobación, Azure Pipelines volverá a intentar la ejecución que generó la comprobación. La ejecución resultante tendrá el mismo número de ejecución y usará la misma versión del código fuente, la configuración y el archivo YAML que la compilación inicial. Solo se volverán a ejecutar los trabajos con errores en la ejecución inicial y los trabajos dependientes del flujo descendente. Hacer clic en el vínculo "Volver a ejecutar todas las comprobaciones con errores" tendrá el mismo efecto. Este es el mismo comportamiento que hacer clic en "Reintentar ejecución" en la interfaz de usuario de Azure Pipelines. Al hacer clic en "Volver a ejecutar todas las comprobaciones", se producirá una nueva ejecución, con un nuevo número de ejecución y se recogerán los cambios en la configuración o en el archivo YAML.

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 se dividen en las siguientes categorías:

• Tipos de conexión: no estoy seguro de qué tipo de conexión estoy usando para conectar mi canalización a GitHub.
• 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.
• Actualizaciones de estado que faltan: mis solicitudes de incorporación de cambios de GitHub están bloqueadas porque Azure Pipelines no ha informado de una actualización de estado.

Tipos de conexión

Para solucionar problemas de desencadenadores, ¿cómo sé el tipo de conexión de GitHub que estoy usando para mi canalización?

La solución de problemas con desencadenadores depende en gran medida del tipo de conexión de GitHub que use en la canalización. Hay dos maneras de determinar el tipo de conexión: desde GitHub y desde Azure Pipelines.

• Desde GitHub: si un repositorio está configurado para usar la aplicación de GitHub, los estados de las solicitudes de incorporación de cambios y las confirmaciones serán ejecuciones de comprobación. Si el repositorio tiene Azure Pipelines configurado con conexiones OAuth o PAT, los estados serán el estilo "antiguo" de los estados. Una manera rápida de determinar si los estados son ejecuciones de comprobación o estados simples es examinar la pestaña "Conversación" en una solicitud de incorporación de cambios de GitHub.

  • Si el vínculo "Detalles" se redirige a la pestaña Comprobaciones, se trata de una ejecución de comprobación y el repositorio usa la aplicación.
  • Si el vínculo "Detalles" redirige a la canalización de Azure DevOps, el estado es un estado de "estilo antiguo" y el repositorio no usa la aplicación.

• Desde Azure Pipelines: también puede determinar el tipo de conexión inspeccionando la canalización en la interfaz de usuario de Azure Pipelines. Abra el editor de la canalización. Seleccione Desencadenadores para abrir el editor clásico de la canalización. A continuación, seleccione la pestaña YAML y, a continuación, el paso Obtener orígenes. Aparecerá el cartel Autorizado para usar la conexión:, que indica la conexión de servicio que se usó para integrar la canalización con GitHub. El nombre de la conexión de servicio es un hipervínculo. Selecciónelo para ir a las propiedades de la conexión de servicio. Las propiedades de la conexión de servicio indicarán el tipo de conexión que se usa:

  • Aplicación de Azure Pipelines indica la conexión de la aplicación de GitHub.
  • oauth indica la conexión de OAuth.
  • personalaccesstoken indica la autenticación con PAT.

¿Cómo puedo cambiar mi canalización para usar la aplicación de GitHub en lugar de OAuth?

El uso de una aplicación de GitHub en lugar de la conexión con OAuth o PAT es la integración recomendada entre GitHub y Azure Pipelines. Para cambiar a la aplicación de GitHub, siga estos pasos:

1. Vaya aquí e instale la aplicación en la organización de GitHub del repositorio.
2. Durante la instalación, se le redirigirá a Azure DevOps para elegir una organización y un proyecto de Azure DevOps. Elija la organización y el proyecto que contienen la canalización de compilación clásica para la que desea usar la aplicación. Esta opción asocia la instalación de la aplicación de GitHub a la organización de Azure DevOps. Si elige incorrectamente, puede visitar esta página para desinstalar la aplicación de GitHub de la organización de GitHub y empezar de nuevo.
3. En la página siguiente que aparece, no es necesario continuar con la creación de una nueva canalización.
4. Edite la canalización visitando la página Canalizaciones (por ejemplo, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)), seleccionando la canalización y haciendo clic en Editar.
5. Si se trata de una canalización YAML, seleccione el menú Desencadenadores para abrir el editor clásico.
6. Seleccione el paso "Obtener orígenes" en la canalización.
7. En la barra verde con el texto "Autorizado para usar la conexión", seleccione "Cambiar" y seleccione la conexión de la aplicación de GitHub con el mismo nombre que la organización de GitHub en la que instaló la aplicación.
8. En la barra de herramientas, seleccione "Guardar y poner en cola" y, a continuación, "Guardar y poner en cola". Seleccione el vínculo a la ejecución de canalización que se puso en cola para asegurarse de que se realiza correctamente.
9. Cree (o cierre y vuelva a abrir) una solicitud de incorporación de cambios en el repositorio de GitHub para comprobar que se pone en cola correctamente una compilación en su sección "Comprobaciones".

¿Por qué no se muestra un repositorio de GitHub para que elija en Azure Pipelines?

Según el tipo de autenticación y la propiedad del repositorio, se requieren permisos específicos.

• Si usa la aplicación de GitHub, consulte Autenticación de aplicación de GitHub.
• Si usa OAuth, consulte Autenticación de OAuth.
• Si usa PAT, consulte Autenticación de token de acceso personal (PAT).

Cuando selecciono un repositorio durante la creación de la canalización, obtengo el error "El repositorio {repo-name} está en uso con la aplicación de GitHub de Azure Pipelines en otra organización de Azure DevOps".

Esto significa que el repositorio ya está asociado a una canalización en otra organización. Los eventos de CI y PR de este repositorio no funcionarán, ya que se entregarán a la otra organización. Estos son los pasos que debe seguir para quitar la asignación a la otra organización antes de continuar con la creación de una canalización.

1. Abra una solicitud de incorporación de cambios en el repositorio de GitHub y haga el comentario /azp where. Esto informa de la organización de Azure DevOps a la que está asignado el repositorio.

2. Para cambiar la asignación, desinstale la aplicación de la organización de GitHub y vuelva a instalarla. Al reinstalarla, asegúrese de seleccionar la organización correcta cuando se le redirija a Azure DevOps.

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.

  

• ¿Usa la conexión de la aplicación de GitHub para conectar la canalización a GitHub? Consulte Tipos de conexión para determinar el tipo de conexión que tiene. Si usa una conexión de aplicación de GitHub, siga estos pasos:

  • ¿Se ha configurado correctamente la asignación entre GitHub y Azure DevOps? Abra una solicitud de incorporación de cambios en el repositorio de GitHub y haga el comentario /azp where. Esto informa de la organización de Azure DevOps a la que está asignado el repositorio.

    • Si no hay ninguna organización configurada para compilar este repositorio mediante la aplicación, vaya a https://github.com/<org_name>/<repo_name>/settings/installations y complete la configuración de la aplicación.

    • Si se notifica otra organización de Azure DevOps, alguien ya ha establecido una canalización para este repositorio en otra organización. Actualmente, tenemos la limitación de que solo podemos asignar un repositorio de GitHub a una sola organización de DevOps. Solo las canalizaciones de la primera organización de Azure DevOps se pueden desencadenar automáticamente. Para cambiar la asignación, desinstale la aplicación de la organización de GitHub y vuelva a instalarla. Al reinstalarla, asegúrese de seleccionar la organización correcta cuando se le redirija a Azure DevOps.

• ¿Usa OAuth o PAT para conectar la canalización a GitHub? Consulte Tipos de conexión para determinar el tipo de conexión que tiene. Si usa una conexión de GitHub, siga estos pasos:

  1. Las conexiones de OAuth y PAT se basan en webhooks para comunicar las actualizaciones a Azure Pipelines. En GitHub, vaya a la configuración del repositorio y, luego, a Webhooks. Compruebe que existan los webhooks. Normalmente, debería ver tres webhooks: push, pull_request y issue_comment. Si no aparecen, debe volver a crear la conexión de servicio y actualizar la canalización para usar la nueva conexión de servicio.

  2. Seleccione cada uno de los webhooks en GitHub y compruebe que la carga que corresponde a la confirmación del usuario exista y se haya enviado correctamente a Azure DevOps. Es posible que aparezca un error aquí si el evento no se pudo comunicar a Azure DevOps.

• GitHub podría limitar el tráfico desde Azure DevOps. Cuando Azure Pipelines recibe una notificación de GitHub, intenta ponerse en contacto con GitHub y recuperar más información sobre el repositorio y el archivo YAML. Si tiene un repositorio con un gran número de actualizaciones y solicitudes de incorporación de cambios, esta llamada puede producir un error debido a dicha limitación. En este caso, compruebe si puede reducir la frecuencia de las compilaciones mediante el procesamiento por lotes o filtros de ruta de acceso o rama más estrictos.

• ¿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.

No quiero que los usuarios invaliden la lista de ramas de los desencadenadores cuando actualizan el archivo YAML. ¿Cómo puedo hacerlo?

Los usuarios con permiso para contribuir al código pueden actualizar el archivo YAML e incluir o excluir ramas adicionales. Como resultado, los usuarios pueden incluir su propia característica o rama de usuario en su archivo YAML e insertar esa actualización en una característica o rama de usuario. Esto puede hacer que la canalización se desencadene para todas las actualizaciones de esa rama. Si desea evitar este comportamiento, puede hacer lo siguiente:

1. Edite la canalización en la interfaz de usuario de Azure Pipelines.
2. Vaya al menú Desencadenadores.
3. Seleccione Invalidar el desencadenador de integración continua de YAML desde aquí.
4. Especifique las ramas que se van a incluir o excluir para el desencadenador.

Al seguir estos pasos, se omiten los desencadenadores de integración continua especificados en el archivo YAML.

Error en la restauración

Veo el siguiente error en el archivo de registro durante el paso de restauración. ¿Cómo puedo corregirlo?

remote: Repository not found.
fatal: repository <repo> not found

Esto podría deberse a una interrupción de GitHub. Intente acceder al repositorio en GitHub y asegúrese de que puede hacerlo.

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.

Actualizaciones de estado que faltan

Mi solicitud de incorporación de cambios en GitHub está bloqueada, ya que Azure Pipelines no ha actualizado el estado.

Este podría ser un error transitorio que dio lugar a que Azure DevOps no pudiera comunicarse con GitHub. Vuelva a intentar la inserción en el repositorio en GitHub si usa la aplicación de GitHub. O bien, realice una actualización trivial a la solicitud de incorporación de cambios para ver si el problema se puede resolver.

Artículos relacionados

• Desencadenadores programados
• Desencadenadores de finalización de canalización