Compilación de repositorios de GitHub

  • Artículo

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.

GitHub organization structure

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

Azure DevOps organization structure

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

GitHub structure mapped to Azure DevOps

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:

Servicio Resolución
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

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.

Rol de organización de GitHub Equivalente en la organización de DevOps
Propietario Miembro de Project Collection Administrators
Administrador de facturación Miembro de Project Collection Administrators
Miembro Miembro de Project Collection Valid Users. De manera predeterminada, el grupo Miembro no tiene permiso para crear nuevos proyectos. Para cambiar el permiso, establezca el permiso Create new projects del grupo en Allow o cree un nuevo grupo con los permisos que necesite.

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.

Rol de cuenta de usuario de GitHub Equivalente en la organización de DevOps
Propietario Miembro de Project Collection Administrators

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.

Permisos de repositorio de GitHub Equivalente del proyecto de DevOps
Administración Miembro de Project Administrators
Escritura Miembro de Contributors
Leer Miembro de Readers

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

Para crear una nueva canalización, primero seleccione un repositorio de GitHub y, a continuación, un archivo YAML de ese repositorio. El repositorio en el que existe el archivo YAML se llama repositorio self. De forma predeterminada, este es el repositorio que compila la canalización.

Más adelante puede configurar la canalización para restaurar un repositorio diferente o varios repositorios. Para información sobre cómo hacerlo, consulte la restauración de varios repositorios.

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.

Tipo de autenticación Canalizaciones ejecutadas mediante Funciona con comprobaciones de GitHub
1. Aplicación de GitHub La identidad de Azure Pipelines Sí
2. OAuth Su identidad personal de GitHub No
3. Token de acceso personal (PAT) Su identidad personal de GitHub No

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:

Permiso Uso del permiso por parte de Azure Pipelines
Acceso de escritura al código Solo tras una acción deliberada por su parte, Azure Pipelines simplificará la creación de una canalización mediante la confirmación de un archivo YAML en una rama seleccionada del repositorio de GitHub.
Acceso de lectura a los metadatos Azure Pipelines recuperará los metadatos de GitHub para mostrar el repositorio, las ramas y los problemas asociados a una compilación en el resumen de la compilación.
Acceso de lectura y escritura a las comprobaciones Azure Pipelines leerá y escribirá sus propios resultados de compilación, prueba y cobertura de código que se mostrarán en GitHub.
Acceso de lectura y escritura a las solicitudes de incorporación de cambios Solo tras una acción deliberada por su parte, Azure Pipelines simplificará la creación de una canalización mediante la creación de una solicitud de incorporación de cambios de un archivo YAML en una rama seleccionada del repositorio de GitHub. Las canalizaciones recuperan los metadatos de la solicitud para mostrarlos en los resúmenes de compilación asociados a las solicitudes de incorporación de cambios.

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.

Las canalizaciones YAML se configuran de forma predeterminada con un desencadenador de CI en todas las ramas, a menos que la opción Deshabilitar desencadenador de CI de YAML implícito, introducida en el sprint 227 de Azure DevOps, esté habilitada. La opción Deshabilitar desencadenador de CI de YAML implícito se puede configurar en el nivel de organización o en el nivel de proyecto. Cuando la opción Deshabilitar desencadenador de CI de YAML implícito está habilitada, los desencadenadores de CI para canalizaciones YAML no están habilitados si la canalización YAML no tiene una sección trigger. De forma predeterminada, Deshabilitar desencadenador de CI de YAML implícito no está habilitada.

Ramas

Puede controlar qué ramas obtienen desencadenadores de CI con una sintaxis simple:

trigger:
- main
- releases/*

Puede especificar el nombre completo de la rama (por ejemplo, main) o un carácter comodín (por ejemplo, releases/*). Consulte Caracteres comodín para obtener información sobre la sintaxis de caracteres comodín.

Nota:

No se pueden usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (una vez desencadenado el desencadenador).

Nota:

Si usa plantillas para crear archivos YAML, solo puede especificar desencadenadores en el archivo YAML principal para la canalización. No se pueden especificar desencadenadores en los archivos de plantilla.

Para desencadenadores más complejos que usan exclude o batch, debe usar la sintaxis completa tal y como se muestra en el ejemplo siguiente.

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

En el ejemplo anterior, la canalización se desencadenará si se inserta un cambio en main o en cualquier rama de versiones. Sin embargo, no se desencadenará si se realiza un cambio en una rama de versiones que comienza por old.

Si especifica una cláusula exclude sin una cláusula include, es equivalente a especificar * en la cláusula include.

Además de especificar nombres de rama en las listas branches, también puede configurar desencadenadores basados en etiquetas con el formato siguiente:

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

Si no ha especificado ningún desencadenador y la opción Deshabilitar desencadenador de CI de YAML implícito no está habilitada, el valor predeterminado es como si escribiera:

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

Importante

Cuando se especifica un desencadenador, se reemplaza el desencadenador implícito predeterminado y solo se insertan en ramas configuradas explícitamente para incluirse en el desencadenamiento de una canalización. Las inclusiones se procesan primero y, a continuación, se quitan de esa lista.

Ejecuciones de procesamiento por lotes de CI

Si hay muchos miembros del equipo que cargan cambios a menudo, es posible que desee reducir el número de ejecuciones que inicie. Si establece batch en true, cuando se ejecuta una canalización el sistema espera hasta que se completa la ejecución y entonces inicia otra ejecución con todos los cambios que aún no se han compilado.

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

Nota:

batch no se admite en desencadenadores de recursos de repositorio.

Para aclarar este ejemplo, supongamos que insertar A para main hace que se ejecute la canalización anterior. Mientras se ejecuta esa canalización, se realizan inserciones adicionales de B y C en el repositorio. Estas actualizaciones no inician nuevas ejecuciones independientes inmediatamente. Sin embargo, una vez completada la primera ejecución, todas las inserciones hasta ese momento se procesan por lotes y se inicia una nueva ejecución.

Nota:

Si la canalización tiene varios trabajos y fases, la primera ejecución todavía debe alcanzar un estado terminal completando u omitiendo todos sus trabajos y fases antes de que se pueda iniciar la segunda ejecución. Por este motivo, debe tener cuidado al usar esta característica en una canalización con varias fases o aprobaciones. Si quiere procesar por lotes las compilaciones en tales casos, se recomienda dividir el proceso de CI / CD en dos canalizaciones: una para la compilación (con procesamiento por lotes) y otra para las implementaciones.

Rutas de acceso

Puede especificar rutas de acceso de archivo para incluir o excluir.

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

Al especificar rutas de acceso, debe especificar explícitamente las ramas en las que se desencadenará si usa Azure DevOps Server 2019.1 o versiones anteriores. No se puede desencadenar una canalización solo con un filtro de ruta de acceso; también debe tener un filtro para ramas y los archivos modificados que coincidan con el filtro de ruta de acceso deben ser de una rama que coincida con el filtro para ramas. Si usa Azure DevOps Server 2020 o posterior, puede omitir el filtro branches de todas las ramas junto con el filtro de ruta de acceso.

Se admiten caracteres comodín para los filtros de ruta de acceso. Por ejemplo, puede incluir todas las rutas de acceso que coincidan con src/app/**/myapp*. Puede usar caracteres comodín (**, * o ?)) al especificar filtros de ruta de acceso.

  • Las rutas de acceso siempre se especifican en relación a la raíz del repositorio.
  • Si no establece filtros de ruta de acceso, la carpeta raíz del repositorio se incluye implícitamente de forma predeterminada.
  • Si excluye una ruta de acceso, tampoco puede incluirla a menos que la especifique en una carpeta más profunda. Por ejemplo, si excluye /tools, puede incluir /tools/trigger-runs-on-these.
  • El orden de los filtros de ruta de acceso no es importante.
  • Las rutas de acceso de Git distinguen mayúsculas de minúsculas. Asegúrese de usar mayúsculas o minúsculas de manera idéntica a las carpetas reales.
  • No se pueden usar variables en rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya activado el desencadenador).

Etiquetas

Además de especificar etiquetas en las listas branches como se describe en la sección anterior, puede especificar directamente etiquetas para incluir o excluir:

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

Si no especifica ningún desencadenador de etiqueta, las etiquetas no desencadenarán canalizaciones de forma predeterminada.

Importante

Si especifica etiquetas en combinación con filtros para ramas, el desencadenador se activará si se cumple el filtro para ramas o si se cumple el filtro de etiquetas. Por ejemplo, si una etiqueta insertada satisface el filtro para ramas, la canalización se desencadena incluso si el filtro de etiquetas excluye la etiqueta, ya que la inserción satisface el filtro para ramas.

No participar en CI

Deshabilitación del desencadenador de CI

Puede optar por no participar en desencadenadores de CI por completo especificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

Al insertar un cambio en una rama, se evalúa el archivo YAML de esa rama para determinar si se debe iniciar una ejecución de integración continua.

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.

Ramas

Puede especificar las ramas de destino al validar las solicitudes de incorporación de cambios. Por ejemplo, para validar las solicitudes de incorporación de cambios destinadas a main y releases/*, puede usar el siguiente desencadenador pr.

pr:
- main
- releases/*

Esta configuración inicia una nueva ejecución la primera vez que se crea una solicitud de incorporación de cambios y después de cada actualización realizada en ella.

Puede especificar el nombre completo de la rama (por ejemplo, main) o un carácter comodín (por ejemplo, releases/*).

Nota:

No se pueden usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (una vez desencadenado el desencadenador).

Nota:

Si usa plantillas para crear archivos YAML, solo puede especificar desencadenadores en el archivo YAML principal para la canalización. No se pueden especificar desencadenadores en los archivos de plantilla.

GitHub crea una nueva referencia cuando se crea una solicitud de incorporación de cambios. La referencia apunta a una confirmación de combinación, que es el código combinado entre las ramas de origen y de destino de la solicitud de incorporación de cambios. La canalización de validación de la solicitud de incorporación de cambios compila la confirmación a la que apunta esta referencia. Esto significa que el archivo YAML que se usa para ejecutar la canalización también es una combinación entre la rama de origen y la rama de destino. Como resultado, los cambios realizados en el archivo YAML de la rama de origen de la solicitud de incorporación de cambios pueden invalidar el comportamiento definido por el archivo YAML de la rama de destino.

Si no aparece ningún desencadenador pr en el archivo YAML, las validaciones de solicitudes de incorporación de cambios se habilitan automáticamente para todas las ramas, como si escribiera el siguiente desencadenador pr. Esta configuración desencadena una compilación cuando se crea cualquier solicitud de incorporación de cambios y cuando las confirmaciones entran en la rama de origen de cualquier solicitud de incorporación de cambios activa.

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

Importante

Cuando se especifica un desencadenador pr con un subconjunto de ramas, solo se desencadena una canalización cuando las actualizaciones se insertan en esas ramas.

En el caso de desencadenadores más complejos que necesitan excluir determinadas ramas, debe usar la sintaxis completa, como se muestra en el ejemplo siguiente. En este ejemplo, en las solicitudes de incorporación de cambios se valida que se excluya el destino main o releases/* y la rama releases/old*.

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

Rutas de acceso

Puede especificar rutas de acceso de archivo para incluir o excluir. Por ejemplo:

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

Sugerencias:

  • Azure Pipelines devuelve un estado neutro a GitHub cuando decide no ejecutar una compilación de validación debido a una regla de exclusión de ruta de acceso. Esto proporciona una dirección clara a GitHub que indica que Azure Pipelines ha completado su procesamiento. Para obtener más información, consulte Publicación de un estado neutro en GitHub cuando se omite una compilación.
  • Ahora, se admiten caracteres comodín con filtros de ruta de acceso.
  • Las rutas de acceso siempre se especifican en relación con la raíz del repositorio.
  • Si no establece filtros de ruta de acceso, la carpeta raíz del repositorio se incluye implícitamente de forma predeterminada.
  • Si excluye una ruta de acceso, tampoco puede incluirla a menos que la especifique en una carpeta más profunda. Por ejemplo, si excluye /tools, puede incluir /tools/trigger-runs-on-these.
  • El orden de los filtros de ruta de acceso no es importante.
  • Las rutas de acceso de Git distinguen mayúsculas de minúsculas. Asegúrese de usar mayúsculas o minúsculas de manera idéntica a las carpetas reales.
  • No se pueden usar variables en rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya activado el desencadenador).
  • Azure Pipelines devuelve un estado neutro a GitHub cuando decide no ejecutar una compilación de validación debido a una regla de exclusión de ruta de acceso.

Varias actualizaciones de solicitud de incorporación de cambios

Puede especificar si las actualizaciones adicionales de una solicitud de incorporación de cambios deben cancelar las ejecuciones de validación en curso de la misma solicitud de incorporación de cambios. El valor predeterminado es true.

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

Validación de borradores de solicitud de incorporación de cambios

De manera predeterminada, los desencadenadores de solicitud de incorporación de cambios se activan con los borradores de solicitudes de incorporación de cambios y las solicitudes de incorporación de cambios que están listas para su revisión. Para deshabilitar los desencadenadores de solicitudes de incorporación de cambios para los borradores de solicitudes de incorporación de cambios, establezca la propiedad drafts en false.

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

Excluirse de la validación de solicitudes de incorporación de cambios

Puede excluirse de la validación de solicitudes de incorporación de cambios por completo especificando pr: none.

# no PR triggers
pr: none

Para más información, consulte Desencadenador de solicitud de incorporación de cambios en el esquema YAML.

Nota:

Si no se activa el desencadenador pr, siga los pasos de solución de problemas de las preguntas más frecuentes.

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.

    GitHub pipeline status check

Importante

Si la canalización no aparece en esta lista, asegúrese de lo siguiente:

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

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

Importante

Esta configuración afecta a la seguridad de la canalización.

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:

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.

Nota:

Al habilitar compilaciones de bifurcación para acceder a secretos, Azure Pipelines restringe de forma predeterminada el token de acceso usado para estas. El acceso a los recursos abiertos es más limitado que con un token de acceso normal. Para conceder a las compilaciones de bifurcación los mismos permisos que tienen las compilaciones normales, habilite la opción Hacer que las compilaciones de bifurcación tengan los mismos permisos que las compilaciones normales.

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

Screenshot of centralized control settings for how pipelines build PRs from forked GitHub repositories.

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:

Get-Help Resultado
/AzurePipelines help Mostrar la ayuda de todos los comandos admitidos.
/AzurePipelines help <command-name> Mostrar la ayuda del comando especificado.
/AzurePipelines run Ejecutar todas las canalizaciones asociadas a este repositorio y cuyos desencadenadores no excluyan esta solicitud de incorporación de cambios.
/AzurePipelines run <pipeline-name> Ejecutar la canalización especificada a menos que sus desencadenadores excluyan esta solicitud de incorporación de cambios.

Nota:

Para mayor brevedad, puede comentar mediante /azp en lugar de /AzurePipelines.

Importante

Las respuestas a estos comandos aparecerán en la discusión de la solicitud de incorporación de cambios solo si la canalización usa la aplicación de GitHub de Azure Pipelines.

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.

Screenshot of an informational pipeline run.

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.

Nota:

Al incluir un paso de restauración en la canalización, se ejecuta el siguiente comando: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Si esto no satisface sus necesidades, puede optar por excluir la restauración integrada con checkout: none, y a continuación usar una tarea de script para realizar su propia restauración.

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

Si va a restaurar un único repositorio, el código fuente se restaurará en un directorio denominado s de forma predeterminada. En el caso de las canalizaciones YAML, puede cambiar esto especificando checkout con un path. La ruta de acceso especificada es relativa a $(Agent.BuildDirectory). Por ejemplo: si el valor de la ruta de acceso de restauración es mycustompath y $(Agent.BuildDirectory) es C:\agent\_work\1, el código fuente se restaurará en C:\agent\_work\1\mycustompath.

Si usa varios pasos checkout, restaura varios repositorios y no especifica explícitamente la carpeta mediante path, cada repositorio se coloca en una subcarpeta s llamada después del repositorio. Por ejemplo, si restaura dos repositorios llamados tools y code, el código fuente se restaurará en C:\agent\_work\1\s\tools y C:\agent\_work\1\s\code.

Tenga en cuenta que el valor de la ruta de restauración no se puede establecer para subir los niveles de directorio por encima de $(Agent.BuildDirectory), por lo que path\..\anotherpath dará como resultado una ruta de restauración válida (es decir, C:\agent\_work\1\anotherpath), y no un valor como ..\invalidpath (es decir, C:\agent\_work\invalidpath).

Puede configurar el valor path en el paso de restauración de la canalizació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

Submódulos

Puede configurar el valor submodules en el paso de restauración de la canalización si desea descargar archivos de 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.

Nota:

P: ¿Por qué no puedo usar un administrador de credenciales de Git en el agente?R: El almacenamiento de las credenciales de submódulo en un administrador de credenciales de Git instalado en el agente de compilación privado no suele ser efectivo, ya que el administrador de credenciales puede pedir que vuelva a escribir las credenciales cada vez que se actualice el submódulo. Esto no es deseable durante las compilaciones automatizadas cuando la interacción del usuario no es posible.

Sincronizar etiquetas

Importante

La característica de sincronización de etiquetas es compatible con Azure Repos Git a partir de Azure DevOps Server 2022.1.

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.

Puede configurar el valor fetchTags en el paso de desprotección de la canalización.

Para configurar el valor en YAML, establezca la propiedad fetchTags.

steps:
- checkout: self
  fetchTags: true

También puede configurar este valor mediante la opción Etiquetas de sincronización en la interfaz de usuario de configuración de canalización.

  1. Edite la canalización de YAML y elija Más acciones y Desencadenadores.

    Screenshot of more triggers menu.

  2. Elija YAML y Obtener orígenes.

    Screenshot of Get sources.

  3. Configure la opción Etiquetas de sincronización.

    Screenshot of Sync tags setting.

Nota:

Si establece fetchTags explícitamente en el paso checkout, esa configuración tiene prioridad sobre la configuración de la interfaz de usuario de configuración de canalización.

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.

Nota:

Si establece fetchTags explícitamente en el paso checkout, esa configuración tiene prioridad sobre la configuración de la interfaz de usuario de configuración de canalización.

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.

Importante

Las nuevas canalizaciones creadas después de la actualización de sprint 209 de septiembre de 2022 de Azure DevOps tienen habilitada la recuperación de cambios superficiales de forma predeterminada y configurada con una profundidad de 1. Anteriormente, el valor predeterminado no era la recuperación de cambios superficiales. Para comprobar la canalización, vea la configuración de recuperación de cambios superficiales en la interfaz de usuario de configuración de canalización, tal como se describe en la sección siguiente.

Puede configurar el valor fetchDepth en el paso de restauración de la canalizació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

También puede configurar la profundidad de la recuperación estableciendo la opción Profundidad superficial en la interfaz de usuario de configuración de canalización.

  1. Edite la canalización de YAML y elija Más acciones y Desencadenadores.

    Screenshot of more triggers menu.

  2. Elija YAML y Obtener orígenes.

    Screenshot of Get sources.

  3. Configure el valor de recuperación de cambios superficiales. Desactive Recuperación de cambios superficiales para deshabilitar la recuperación de cambios superficiales o active la casilla y escriba una profundidad para habilitarla.

    Screenshot of options.

Nota:

Si establece fetchDepth explícitamente en el paso checkout, esa configuración tiene prioridad sobre la configuración de la interfaz de usuario de configuración de canalización. Al establecer fetchDepth: 0 se recupera todo el historial y se invalida la configuración derecuperación de cambios superficiales.

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.

Nota

Cuando se inicia la canalización, la rama que se va a compilar se resuelve en un identificador de confirmación. A continuación, el agente recupera la rama y comprueba la confirmación deseada. Hay una ventana pequeña entre resolver una rama en un identificador de confirmación y cuando el agente realiza la restauración. Si la rama se actualiza rápidamente y establece un valor muy pequeño para la recuperación de cambios superficial, es posible que la confirmación no exista cuando el agente intente extraerla. Si esto sucede, aumente la configuración de profundidad de la recuperación de cambios superficial.

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.

Puede configurar la opción No sincronizar orígenes en el paso de desprotección de la canalización estableciendo checkout: none.

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

Nota:

Cuando se usa esta opción, el agente también omite la ejecución de comandos de Git que limpian el repositorio.

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.

Nota

La limpieza no es eficaz si usa un agente hospedado por Microsoft porque obtendrá un nuevo agente cada vez.

Puede configurar el valor clean en el paso de desprotección de la canalizació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

Cuando clean se establece en true en la canalización de compilación, deshace los cambios en $(Build.SourcesDirectory). Más concretamente, los siguientes comandos de Git se ejecutan antes de recuperar el origen.

git clean -ffdx
git reset --hard HEAD

Para obtener más opciones, puede configurar el valor workspace de un trabajo.

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

Esto proporciona las siguientes opciones de limpieza.

  • salidas: la misma operación que la configuración de limpieza descrita en la tarea de restauración anterior, además de: elimina y vuelve a crear $(Build.BinariesDirectory). Tenga en cuenta que $(Build.ArtifactStagingDirectory) y $(Common.TestResultsDirectory) siempre se eliminan y se vuelven a crear antes de cada compilación, independientemente de cualquiera de estas configuraciones.

  • recursos: elimina y vuelve a crear $(Build.SourcesDirectory). Esto da como resultado el inicio de un repositorio de Git local nuevo para cada compilación.

  • todos: elimina y vuelve a crear $(Agent.BuildDirectory). Esto da como resultado el inicio de un repositorio de Git local nuevo para cada compilación.

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.

Actualmente no puede configurar esta opción en YAML, pero puede hacerlo en el editor clásico. Al editar una canalización YAML, puede acceder al editor clásico si elige Desencadenadores en el menú del editor de YAML.

Configure Git options, YAML.

En el editor clásico, elija YAML, elija la tarea Obtener orígenes y, a continuación, configure las propiedades deseadas allí.

From the Classic editor, choose YAML > Get sources.

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.

GitHub checks rerun

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 rama Predeterminada para la configuración de 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 manualmente el nombre de la rama deseada.

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.

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.

    Pipeline settings UI.

    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.

    Override YAML trigger from here.

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