Compartir a través de

Compilación de repositorios de GitHub

  • Artículo

de Azure DevOps Services

Azure Pipelines puede compilar y validar automáticamente todas las solicitudes de incorporación de cambios y confirmarlas 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 la 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. Cada uno de ellos tiene su propia organización y administración de usuarios. En esta sección se recomienda cómo replicar la organización y los usuarios de GitHub en Azure Pipelines.

Organizaciones

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

estructura de la organización de GitHub

La estructura de Azure DevOps consta de organizaciones que contienen proyectos de . Consulte Planear la estructura organizativa.

estructura de la organización de Azure DevOps

Azure DevOps puede reflejar la estructura de GitHub con:

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

estructura de GitHub asignada a Azure DevOps

Para configurar una estructura idéntica en Azure DevOps:

  1. Cree una organización de DevOps denominada después de la organización de GitHub o la cuenta de usuario. Tendrá una dirección URL como https://dev.azure.com/your-organization.
  2. En la organización de DevOps, cree proyectos denominados después de los repositorios. Tendrán direcciones URL como https://dev.azure.com/your-organization/your-repository.
  3. En DevOps Project, cree canalizaciones denominadas después de la organización de GitHub y el repositorio que compilen, como your-organization.your-repository. A continuación, está claro para qué repositorios están.

Siguiendo este patrón, los repositorios de GitHub y Azure DevOps Projects tendrán rutas de acceso url coincidentes. Por ejemplo:

Servicio URL
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 es consciente 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 pr mediante su identidad y dirección de correo electrónico de GitHub. Debe crear explícitamente nuevos usuarios en Azure Pipelines para replicar 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 miembro de la organización de GitHub se encuentran en https://github.com/orgs/your-organization/people (reemplace your-organization).

Los permisos de miembro 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 de la organización de DevOps
Dueño Miembro de Project Collection Administrators
Administrador de facturación Miembro de Project Collection Administrators
Miembro Miembro de Project Collection Valid Users. De forma predeterminada, el grupo miembro carece de permiso para crear nuevos proyectos. Para cambiar el permiso, establezca el permiso de Create new projects del grupo en Allowo cree un nuevo grupo con 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 miembro 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 de la manera siguiente.

Rol de cuenta de usuario de GitHub Equivalente de la organización de DevOps
Dueño 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 Azure DevOps Projects son los siguientes.

Permiso de repositorio de GitHub Equivalente al proyecto de DevOps
Admin Miembro de Project Administrators
Escribir Miembro de Contributors
Leer Miembro de Readers

Si el repositorio de GitHub concede permiso a los 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 canalización, seleccione primero un repositorio de GitHub y, a continuación, un archivo YAML en ese repositorio. El repositorio en el que está presente el archivo YAML se denomina self repositorio. De forma predeterminada, este es el repositorio que compila la canalización.

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

Se debe conceder acceso a Azure Pipelines a los repositorios para desencadenar sus compilaciones y capturar 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 que se ejecutan mediante Funciona con comprobaciones de GitHub de
1. de aplicaciones de GitHub 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 gitHub de Azure Pipelines es el recomendado tipo de autenticación para canalizaciones de integración continua. Después de instalar la aplicación de GitHub en la cuenta o organización de GitHub, la canalización se ejecutará sin usar la 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 GitHub Checks para mostrar los resultados de compilación, prueba y cobertura de código en GitHub.

Para usar la aplicación de GitHub, instálela en su organización o cuenta de usuario de GitHub para algunos o todos los repositorios. La aplicación de GitHub se puede instalar y desinstalar desde la página principal de 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. Sin embargo, si la aplicación está instalada para todos los repositorios, el token usado por la aplicación tendrá acceso a todos los repositorios, incluidos los privados. Por motivos de seguridad, se recomienda separar repositorios privados y públicos en el nivel de organización. Esto significa tener una organización dedicada solo para proyectos públicos sin repositorios privados. Si, por algún motivo, es necesario tener repositorios públicos y privados en la misma organización, en lugar de usar el acceso para todos los repositorios, seleccione explícitamente los repositorios a los que debe tener acceso la aplicación. Esto requiere más trabajo para los administradores, pero garantiza una mejor administración de seguridad.

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 necesarios de GitHub. 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 gitHub de Azure Pipelines en su cuenta personal de GitHub. Debe agregarse como colaborador en la configuración del repositorio en "Colaboradores". Acepte la invitación para ser 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 propietaria, instale la aplicación gitHub de Azure Pipelines en la organización de GitHub. También debe agregarse como colaborador o el equipo debe agregarse en la configuración del repositorio en "Colaboradores y equipos".

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

Permisos de aplicación de GitHub

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

Permiso Uso del permiso de Azure Pipelines
Escritura del acceso al código Solo tras la acción deliberada, 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 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 la acción deliberada, Azure Pipelines simplificará la creación de una canalización mediante la creación de una solicitud de incorporación de cambios para un archivo YAML que se confirmó en una rama seleccionada del repositorio de GitHub. Pipelines recupera los metadatos de solicitud que se muestran en resúmenes de compilación asociados a las solicitudes de incorporación de cambios.

Solución de problemas de instalación de aplicaciones de GitHub

GitHub puede mostrar un error como:

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, la aplicación de GitHub se usará automáticamente 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 organizaciones y proyectos 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 las organizaciones secundarias de Azure DevOps.

Autenticación de OAuth

OAuth es el tipo de autenticación más sencillo con el que empezar a trabajar para repositorios en su 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 Elija una conexión diferente 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. Una conexión de OAuth se guardará en el proyecto de Azure DevOps para su uso posterior y se usará 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 necesarios de GitHub. 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 cuenta de GitHub personales. 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 cuenta de GitHub personales. 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 agregarse como colaborador en la configuración del repositorio en "Colaboradores". Acepte la invitación para ser colaborador mediante el vínculo que se le envía por correo electrónico.

  • Si el repositorio está en una organización de GitHub que posee, al menos una vez, autentíquese en GitHub con OAuth mediante sus credenciales de cuenta de GitHub personales. 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 agregarse como colaborador o se debe agregar el equipo, en la configuración del repositorio en "Colaboradores y equipos".

  • Si el repositorio está en una organización de GitHub que otra persona posee, al menos una vez, un propietario de la organización de GitHub debe autenticarse en GitHub con OAuth mediante sus credenciales de cuenta de GitHub personales. 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 de la organización" aquí. Debe agregarse como colaborador o se debe agregar el equipo, en la configuración del repositorio en "Colaboradores y equipos". Acepte la invitación para ser 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)

pats son efectivamente los mismos 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:usery user:email. Estos son los mismos permisos necesarios al usar OAuth anterior. 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 una recuperación futura, asigne un nombre a la conexión de servicio después del 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 necesarios de GitHub. 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 siguiente acceso.

  • 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:usery 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:usery user:email. Debe agregarse como colaborador en la configuración del repositorio en "Colaboradores". Acepte la invitación para ser colaborador mediante el vínculo que se le envía por correo electrónico.

  • Si el repositorio está en una organización de GitHub que posee, el PAT debe tener los ámbitos de acceso necesarios en tokens de acceso personal: repo, admin:repo_hook, read:usery user:email. Debe agregarse como colaborador o se debe agregar el equipo, en la configuración del repositorio en "Colaboradores y equipos".

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

Revocar el acceso PAT

Después de autorizar a Azure Pipelines a usar un PAT, para eliminarlo más adelante y evitar su uso posterior, 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 CI

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 de YAML se configuran de forma predeterminada con un desencadenador de CI en todas las ramas, a menos que la configuración de de desencadenador de CI de YAML implícito, introducida en sprint de Azure DevOps 227, esté habilitada. El deshabilitar el desencadenador de CI de YAML implícito se puede configurar en el nivel de organización o en el nivel de proyecto. Cuando el Deshabilitar el desencadenador de CI de YAML implícito está habilitado, los desencadenadores de CI para canalizaciones YAML no están habilitados si la canalización yaML no tiene una sección de trigger. De forma predeterminada, deshabilitar el desencadenador de CI de YAML implícito no está habilitado.

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 puede usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Nota

Si usa plantillas de 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 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 con old.

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

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

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

Si no especificó ningún desencadenador y el Deshabilitar el desencadenador implícito de CI de YAML configuración no está habilitado, 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, reemplaza el desencadenador implícito predeterminado y solo se insertan en ramas configuradas explícitamente para que se incluyan desencadenará una canalización. Las inclusión se procesan primero y, a continuación, se quitan de esa lista.

Ejecuciones de CI de procesamiento por lotes

Si tiene muchos miembros del equipo que cargan cambios a menudo, puede que desee reducir el número de ejecuciones que se inician. Si establece batch en true, cuando se ejecuta una canalización, el sistema espera hasta que se completa la ejecución y, a continuación, 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 los desencadenadores de recursos del repositorio.

Para aclarar este ejemplo, supongamos que una A de inserción para main hizo que se ejecutara la canalización anterior. Mientras se ejecuta esa canalización, se B y C se producen inserciones adicionales en el repositorio. Estas actualizaciones no inician nuevas ejecuciones independientes inmediatamente. Pero una vez completada la primera ejecución, todas las inserciones hasta ese momento de tiempo se agrupan 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 de terminal completando o omitiendo todos sus trabajos y fases antes de que se pueda iniciar la segunda ejecución. Por este motivo, debe tener precaución al usar esta característica en una canalización con varias fases o aprobaciones. Si desea 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.

Caminos

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 ramas en las que se desencadenará si usa Azure DevOps Server 2019.1 o versiones posteriores. No se puede desencadenar una canalización solo con un filtro de ruta de acceso; También debe tener un filtro de rama y los archivos modificados que coincidan con el filtro de ruta de acceso deben ser de una rama que coincida con el filtro de rama. Si usa Azure DevOps Server 2020 o versiones posteriores, puede omitir branches filtrar en 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 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 califique en una carpeta más profunda. Por ejemplo, si excluye /tools, podría incluir /tools/trigger-runs-on-these
  • El orden de los filtros de ruta de acceso no importa.
  • Las rutas de acceso de git distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que las carpetas reales.
  • No puede usar variables en las rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Etiquetas

Además de especificar etiquetas en las listas de branches como se trata 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 de rama, el desencadenador se activará si se cumple el filtro de rama o si se cumple el filtro de etiquetas. Por ejemplo, si una etiqueta insertada satisface el filtro de rama, la canalización se desencadena incluso si el filtro de etiquetas excluye la etiqueta, ya que la inserción satisface el filtro de rama.

No participar en CI

Deshabilitación del desencadenador de CI

Puede rechazar completamente los desencadenadores de CI especificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

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

Omisión de CI 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 la 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 cualquiera de las siguientes variaciones.

  • [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

Es un escenario común 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 del sistema Build.Reason. Por ejemplo, agregue la siguiente condición al paso, el trabajo o la fase para excluirla de las validaciones de PR.

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

Comportamiento de desencadenadores cuando se crean nuevas ramas

Es habitual configurar varias canalizaciones para el mismo repositorio. Por ejemplo, puede tener una canalización para compilar los documentos de la aplicación y otro para compilar el código fuente. Puede configurar desencadenadores de CI con filtros de rama y filtros de ruta de acceso adecuados 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 que se desencadene 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 de rama) 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á incluso si no hay ningún cambio 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 que * coincidan con cero o más caracteres y ? que coincidan con un solo carácter.

  • Si inicia el patrón con * en una canalización YAML, debe ajustar 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 las rutas de acceso:
    • En Azure DevOps Server 2022 y versiones posteriores, incluido Azure DevOps Services, un carácter comodín puede aparecer en cualquier lugar dentro de un patrón de ruta de acceso y puede usar * o ?.
    • En Azure DevOps Server 2020 y versiones anteriores, puede incluir * como carácter final, pero no hace nada diferente de especificar el nombre del directorio por sí mismo. Es posible que no incluya * en medio de un filtro de ruta de acceso y no use ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Desencadenadores de PR

Los desencadenadores de solicitud de incorporación de cambios (PR) hacen que una canalización se ejecute siempre que se abra una solicitud de incorporación de cambios con una de las ramas de destino especificadas o cuando se realicen actualizaciones en dicha 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 que tienen como destino main y releases/*, puede usar el siguiente desencadenador de pr.

pr:
- main
- releases/*

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

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

Nota

No puede usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Nota

Si usa plantillas de 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 un nuevo ref cuando se crea una solicitud de incorporación de cambios. La referencia apunta a un 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 pr compila la confirmación de que esta referencia apunta. Esto significa que el archivo YAML que se usa para ejecutar la canalización también es una combinación entre el origen y la rama de destino. Como resultado, los cambios realizados en el archivo YAML en la rama de origen de la solicitud de incorporación de cambios pueden invalidar el comportamiento definido por el archivo YAML en la rama de destino.

Si no aparecen desencadenadores 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 de 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 de pr con un subconjunto de ramas, una canalización solo se desencadena cuando se insertan actualizaciones en esas ramas.

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

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

Caminos

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 de :

  • 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 Estado post neutral en GitHub cuando se omite una compilación.
  • las tarjetas comodín ahora se admiten 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 califique en una carpeta más profunda. Por ejemplo, si excluye /tools, podría incluir /tools/trigger-runs-on-these
  • El orden de los filtros de ruta de acceso no importa.
  • Las rutas de acceso de git distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que las carpetas reales.
  • No puede usar variables en las rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado 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 más actualizaciones de una solicitud de incorporación de cambios deben cancelar las ejecuciones de validación en curso para la misma solicitud de incorporación de cambios. El valor predeterminado es true.

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

Borrador de validación de PR

De forma predeterminada, los desencadenadores de solicitud de incorporación de cambios se activan en las solicitudes de incorporación de cambios de borrador y las solicitudes de incorporación de cambios que están listas para su revisión. Para deshabilitar los desencadenadores de solicitud de incorporación de cambios para las solicitudes de incorporación de cambios de borrador, 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

No participar en la validación de pr

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

# no PR triggers
pr: none

Para obtener más información, consulte desencadenador de pr en el esquema yaML de .

Nota

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

Si tiene una solicitud de incorporación de cambios abierta e inserta cambios en su rama de origen, se pueden ejecutar varias canalizaciones:

  • Las canalizaciones que tienen un desencadenador de pr 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 de destino de la solicitud de incorporación de cambios), independientemente de si existen confirmaciones insertadas cuyos mensajes o descripciones contienen [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 ninguna confirmación insertada cuyos mensajes o descripciones contienen [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 contienen [skip ci] (ni ninguna de sus variantes).

Ramas protegidas

Puede ejecutar una compilación de validación con cada solicitud de confirmación o incorporación de cambios que tenga como destino una rama e incluso impedir que las solicitudes de incorporación de cambios se combinen 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 Administrador o un miembro de la organización de GitHub con el rol Escribir.

  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.

    comprobación del estado de la canalización de GitHub

Importante

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

  • Usa de autenticación de aplicaciones de GitHub
  • La canalización se ha ejecutado al menos una vez en la última semana.

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 cualquier usuario pueda ver los resultados de compilación, los registros y los resultados de las pruebas 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 forma predeterminada, los secretos asociados a la canalización no están disponibles para las validaciones de solicitudes de incorporación de cambios de bifurcaciones. Consulte Validar 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 pruebas 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 paquetes de Azure Artifacts, debe conceder explícitamente permiso a la cuenta del servicio de compilación de proyectos 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 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 de . Después de habilitar el desencadenador de solicitud de incorporación de cambios , habilite o deshabilite las solicitudes de incorporación de cambios de compilación de bifurcación de este repositorio casilla.

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

  • Un token de seguridad con acceso al repositorio de GitHub.
  • Estos elementos, si la canalización las usa:
    • credenciales de de conexión de servicio de
    • Archivos de la biblioteca de archivos seguros
    • Crear variables de marcadas secreto

Para omitir esta precaución en las canalizaciones de GitHub, habilite la casilla Hacer que los secretos estén disponibles para 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 las compilaciones de bifurcación. Tiene acceso más limitado a los recursos abiertos que un token de acceso normal. Para conceder a las compilaciones de bifurcación los mismos permisos que las compilaciones normales, habilite las compilaciones de bifurcación de tienen los mismos permisos que las compilaciones normales configuración.

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

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

  • Deshabilitación de la creación de solicitudes de incorporación de cambios de repositorios bifurcadas
  • Compilación segura de solicitudes de incorporación de cambios de repositorios bifurcadas
  • Personalización de reglas para crear solicitudes de incorporación de cambios de repositorios bifurcadas

Captura de pantalla de la configuración de control centralizada para cómo las canalizaciones crean solicitudes de incorporación de cambios a partir de repositorios de GitHub bifurcadas.

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

Al elegir la opción compilar de forma segura las solicitudes de incorporación de cambios de repositorios bifurcadas opción, todas las canalizaciones, organización o en todo el proyecto, no pueden hacer que los secretos estén disponibles para las compilaciones de PR desde repositorios bifurcadas, no 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 la canalización. Por ejemplo, puede asegurarse de que todas las canalizaciones requieren un comentario para crear una solicitud de incorporación de cambios a partir de un repositorio de GitHub bifurcado, cuando la solicitud de incorporación de cambios pertenece a miembros que no son de equipo y no colaboradores. 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 tengan aún más configuraciones restrictivas que las especificadas en el nivel de organización.

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

Consideraciones de seguridad importantes

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:

  • Filtre secretos de la canalización. Para mitigar este riesgo, no habilite el Hacer que los secretos estén disponibles para compilaciones de bifurcaciones casilla si el repositorio es público o no es de confianza los usuarios pueden enviar solicitudes de incorporación de cambios que desencadenan automáticamente compilaciones. Esta opción está deshabilitada de forma predeterminada.

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

    • Use una grupo de agentes hospedados por Microsoft para compilar solicitudes de incorporación de cambios de 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 una 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 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. Estas son algunas razones comunes por las que puede querer hacerlo:

  • Es posible que no quiera compilar automáticamente 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, ejecute la canalización. Esto se usa normalmente como medida de seguridad al compilar código aportado a partir de repositorios bifurcadas.
  • Es posible que quiera 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 solicitudes de incorporación de cambios, habilite Requerir el comentario de un miembro del equipo antes de crear una solicitud de incorporación de cambios.
    • Elija En todas las solicitudes de incorporación de cambios para requerir el comentario de un miembro del equipo antes de crear 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.
    • Elija solo en solicitudes de incorporación de cambios de miembros que no sean del equipo para requerir el comentario de un miembro del equipo solo cuando un miembro 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 del miembro del equipo secundario 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 un miembro del equipo seleccione solo en solicitudes de incorporación de cambios de miembros que no sean del equipo y la solicitud de incorporación de cambios la realice un miembro del equipo. Solo los propietarios y colaboradores del repositorio con el permiso "Escribir" pueden desencadenar la compilación mediante comentarios en la solicitud de incorporación de cambios con /AzurePipelines run o /AzurePipelines run <pipeline-name>.

Los comandos siguientes se pueden emitir a Azure Pipelines en comentarios:

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

Nota

Por motivos de 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 el 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 de repositorio necesarios, pero las canalizaciones no se desencadenan mediante los comentarios, asegúrese de que la pertenencia esté pública en la organización del repositorio o agréguese directamente como colaborador del repositorio. Las canalizaciones no pueden ver a los miembros de la organización privada a menos que sean colaboradores directos o pertenezcan a un equipo que sea un colaborador directo. Puede cambiar la pertenencia de la organización de GitHub de privado a público 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 de 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 desencadenadores internos, por ejemplo, para comprobar si hay cambios en el código e iniciar una ejecución programada o no. La recuperación de código fuente puede producir un error por varias razones, con una limitación frecuente de solicitudes por parte del proveedor del repositorio git. La existencia de una ejecución informativa no significa necesariamente que Azure DevOps ejecutara la canalización.

Una ejecución informativa tiene un aspecto similar al de la captura de pantalla siguiente.

Captura de pantalla de una ejecución de canalización informativa.

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

  • El estado es Canceled
  • La duración es < 1s
  • El nombre de ejecución contiene uno de los textos siguientes:
    • 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 ejecución generalmente contiene el error BitBucket /GitHub que provocó un error en la carga de la canalización de YAML.
  • Sin fases/ trabajos/pasos

Obtenga más información sobre las ejecuciones informativas de .

Caja

Cuando se desencadena una canalización, Azure Pipelines extrae el código fuente del repositorio git de Azure Repos. Puede controlar varios aspectos de cómo sucede esto.

Nota

Al incluir un paso de desprotecció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 desprotección integrada checkout: none y, a continuación, usar una tarea de script para realizar su propia desprotecció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.

Ruta de acceso de desprotec

Si va a desprotegir un único repositorio de forma predeterminada, el código fuente se desprotegirá en un directorio denominado s. Para 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 desprotección es mycustompath y $(Agent.BuildDirectory) es C:\agent\_work\1, el código fuente se desprotegirá en C:\agent\_work\1\mycustompath.

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

Tenga en cuenta que el valor de la ruta de finalización de la compra 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 desprotección válida (es decir, C:\agent\_work\1\anotherpath), pero un valor como ..\invalidpath no (es decir, C:\agent\_work\invalidpath).

Puede configurar la configuración de en el paso de 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

Submódulos

Puede configurar el valor de en el paso de Desprotección de 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 comprobará los submódulos de Git siempre que sean:

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

  • autenticado :

    • Contenido 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 también 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

      • Este se desprotegirí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 también se usan para obtener los orígenes de los submódulos. Esto requiere que el token de acceso del 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 del trabajo acceda al repositorio del segundo proyecto mediante (a) conceder explícitamente acceso a la cuenta de servicio de compilación del proyecto en el segundo proyecto o (b) mediante tokens de acceso con ámbito de colección en lugar de tokens de ámbito de proyecto para toda la organización. Para obtener más información sobre estas opciones y sus implicaciones de seguridad, consulte repositorios, artefactos y otros recursos.

      • Este no se desprotegirí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 puede usar la opción Desproteger 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 submódulos no se almacenan en la misma organización de Azure DevOps o si el token de acceso del trabajo no tiene acceso al repositorio en un proyecto diferente.

Si no puede usar la opción submódulos Desproteger, puede usar un paso de script personalizado para capturar submódulos. En primer lugar, obtenga un token de acceso personal (PAT) y prefijo con pat:. A continuación, codificación 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?A: Almacenar las credenciales de submódulo en un administrador de credenciales de Git instalado en el agente de compilación privado no suele ser eficaz, ya que el administrador de credenciales puede solicitarle que vuelva a escribir las credenciales cada vez que se actualice el submódulo. Esto no es deseable durante las compilaciones automatizadas cuando no es posible la interacción del usuario.

Etiquetas de sincronización

Importante

La característica de etiquetas de sincronización se admite en Git de Azure Repos con Azure DevOps Server 2022.1 y versiones posteriores.

El paso de desprotección usa la opción --tags al capturar el contenido de un repositorio de Git. Esto hace que el servidor capture 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 desprotección sincroniza las etiquetas incluso cuando se habilita la opción de captura superficial, lo que posiblemente derrota su propósito. Para reducir la cantidad de datos capturados o extraídos de un repositorio de Git, Microsoft ha agregado una nueva opción para desproteger para 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 desprotegar un repositorio en YAML estableciendo la propiedad fetchTags y en la interfaz de usuario configurando las etiquetas de Sincronizar configuración.

Puede configurar la configuración de en el paso de 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 esta opción 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, desencadenadores.

    Captura de pantalla del menú más desencadenadores.

  2. Elija YAML , Obtener orígenes.

    Captura de pantalla de Obtención de orígenes.

  3. Configure la configuración etiquetas de sincronización de .

    Captura de pantalla de la configuración de etiquetas de sincronización.

Nota

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

Comportamiento predeterminado

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

Nota

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

Captura superficial

Es posible que quiera limitar el retroceso en el historial que se va a descargar. 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 septiembre de 2022 azure DevOps sprint 209 tienen captura superficial habilitada de forma predeterminada y configurada con una profundidad de 1. Anteriormente, el valor predeterminado no era capturar superficialmente. Para comprobar la canalización, vea la configuración captura superficial en la interfaz de usuario de configuración de canalización, tal como se describe en la sección siguiente.

Puede configurar la configuración de en el paso de 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

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

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

    Captura de pantalla del menú más desencadenadores.

  2. Elija YAML , Obtener orígenes.

    Captura de pantalla de Obtención de orígenes.

  3. Configure la configuración de captura superficial . Desactive captura superficial para deshabilitar la captura superficial, o active la casilla y escriba un de profundidad para habilitar la captura superficial.

    Captura de pantalla de las opciones.

Nota

Si establece explícitamente fetchDepth en el paso de checkout, esa configuración tiene prioridad sobre la configuración configurada en la interfaz de usuario de configuración de canalización. Al establecer captura todo el historial e invalida la configuración de captura superficial .

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 para 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 captura la rama y comprueba la confirmación deseada. Hay una ventana pequeña entre cuando una rama se resuelve en un identificador de confirmación y cuando el agente realiza la desprotección. Si la rama se actualiza rápidamente y establece un valor muy pequeño para la captura superficial, es posible que la confirmación no exista cuando el agente intente desprotegerla. Si esto sucede, aumente la configuración de profundidad de captura superficial.

No sincronizar orígenes

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

  • Git init, config y fetch mediante sus propias opciones personalizadas.

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

Puede configurar la configuración No sincronizar orígenes en el paso Desprotección de de la canalización estableciendo .

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

Nota

Al usar esta opción, el agente también omite la ejecución de comandos de Git que limpian el repositorio.

Limpieza de la compilación

Puede realizar diferentes formas de limpiar el 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 deshabilitando cualquier opción Limpiar de la tarea o herramienta que usa para compilar.

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

Nota

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

Puede configurar la configuración de en el paso de 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 la canalización de compilación realiza una deshacer de los cambios en $(Build.SourcesDirectory). Más concretamente, los siguientes comandos de Git se ejecutan antes de capturar el origen.

git clean -ffdx
git reset --hard HEAD

Para obtener más opciones, puede configurar el valor de 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 limpias.

  • genera: la misma operación que la configuración de limpieza descrita en la tarea de desprotección anterior, además de: Elimina y vuelve a crear $(Build.BinariesDirectory). Tenga en cuenta que los $(Build.ArtifactStagingDirectory) y los $(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 la inicialización de un nuevo repositorio git local para cada compilación.

  • todas las: elimina y vuelve a crear $(Agent.BuildDirectory). Esto da como resultado la inicialización de un nuevo repositorio git local para cada compilación.

Orígenes de etiquetas

Es posible que quiera etiquetar los archivos de código fuente para permitir que el 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 eligiendo desencadenadores en el menú del editor de YAML.

Configurar opciones de Git, YAML.

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

En el editor clásico, elija YAML > Obtener orígenes.

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

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

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

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 es una etiqueta válida. Por ejemplo, las variables como $(Build.RequestedFor) y $(Build.DefinitionName) pueden contener espacios en blanco. Si el valor contiene espacios en blanco, la etiqueta no se crea.

Después de etiquetar los orígenes mediante la canalización de compilación, se agrega automáticamente un artefacto con la referencia de Git refs/tags/{tag} 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 a través de 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 envía a 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 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 confirmaciones del repositorio.

Conexiones pat o OAuth de GitHub

En el caso de las canalizaciones que usan PAT o conexiones de OAuth GitHub, los estados se devuelven a la confirmación o 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 canalización (erróneo, 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 PAT o 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 azure Pipelines aplicación de GitHub, 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, las comprobaciones se vuelven a publicar 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 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 confirmar o volver a ejecutar todas las comprobaciones, independientemente de si se realizaron correctamente inicialmente o no.

comprobaciones de GitHub se vuelven a ejecutar

Al hacer clic en el vínculo "Volver a ejecutar" junto al nombre comprobar la ejecució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 que no se pudieron ejecutar en la ejecución inicial y se volverán a ejecutar los trabajos dependientes de bajada. Al 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 la 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 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. Siempre que haya inserción en un repositorio, Azure Pipelines debe cargar todas las canalizaciones de YAML de ese repositorio para averiguar si alguna de ellas necesita ejecutarse y cargar cada canalización conlleva 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 amplía y incluyen plantillas de 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 desde un repositorio en listas desplegables del Portal de Azure DevOps, por ejemplo, en la ventana seleccionar una rama de rama para la rama predeterminada de para las compilaciones manuales y programadas configuración, o al elegir una rama al ejecutar una canalización manualmente.

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

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

Preguntas más frecuentes

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

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 mucho 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 se configura un repositorio para usar la aplicación de GitHub, los estados de las solicitudes de incorporación de cambios y confirmaciones serán Comprobar ejecuciones. 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 Comprobar ejecuciones 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 comprobación de ejecució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 pestaña yaML y, después, el paso Obtener orígenes. Observará un banner Autorizado mediante 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 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 pat

¿Cómo cambio 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 de 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 mediante 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 una compilación se pone en cola correctamente 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.

Al seleccionar un repositorio durante la creación de la canalización, obtengo un error "El repositorio {repo-name} está en uso con la aplicación 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 realice el comentario /azp where. Esto notifica a 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 de los desencadenadores con errores:

  • ¿Se reemplazan los desencadenadores de CI o PR de YAML invalidados por la configuración de canalización en elde interfaz de usuario? Al editar la canalización, elija ... y, después, Desencadenadores.

    interfaz de usuario de configuración de canalización.

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

    invalidar el desencadenador YAML desde aquí.

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

    • ¿La asignación se configura correctamente entre GitHub y Azure DevOps? Abra una solicitud de incorporación de cambios en el repositorio de GitHub y realice el comentario /azp where. Esto notifica a 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 una organización de Azure DevOps diferente, 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 se pueden desencadenar automáticamente las canalizaciones de la primera organización de Azure DevOps. 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 OAuth y PAT dependen de webhooks para comunicar actualizaciones a Azure Pipelines. En GitHub, vaya a la configuración del repositorio y, a continuación, a Webhooks. Compruebe que los webhooks existen. Normalmente debería ver tres webhooks: inserción, pull_request y issue_comment. Si no lo hace, debe volver a crear la conexión de servicio y actualizar la canalización para usar la nueva conexión de servicio.

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

  • GitHub podría limitar el tráfico de Azure DevOps. Cuando Azure Pipelines recibe una notificación de GitHub, intenta ponerse en contacto con GitHub y obtener más información sobre el repositorio y el archivo YAML. Si 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, vea 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, a continuación, seleccione Configuración para comprobar. Si la canalización está en pausa o deshabilitada, los desencadenadores no funcionan.

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

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

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

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

  • ¿Ha excluido las ramas o rutas de acceso a las que ha insertado los cambios? Pruebe insertando un cambio en una ruta de acceso incluida en una rama incluida. Tenga en cuenta que las rutas de acceso de los desencadenadores distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que los de carpetas reales al especificar las rutas de acceso en desencadenadores.

  • ¿Acabas 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 desencadenadores cuando se crean nuevas ramas".

Mis desencadenadores de CI o PR han funcionado bien. Pero dejaron de trabajar ahora.

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? Para una solicitud de incorporación de cambios que no desencadenó 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 solicitud de incorporación de cambios? Normalmente, puede comprobar un retraso 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 solicitud de incorporación de cambios a cualquiera de los repositorios muestra este síntoma, es posible que experimentemos retrasos en el procesamiento de los eventos de actualización. Estas son algunas de las razones por las que puede producirse un retraso:

    • Estamos experimentando una interrupción del servicio en nuestra página de estado de . Si la página de estado muestra un problema, nuestro equipo debe haber empezado a trabajar en él. Compruebe la página con frecuencia para ver las 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 un rendimiento aceptable, se recomienda un máximo de 100 canalizaciones en un único repositorio. Cuantos más canalizaciones haya, más lento será el procesamiento de una inserción en ese repositorio. Cada vez que hay inserción 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 desencadenadores cuando actualizan el archivo YAML. ¿Cómo puedo hacer esto?

Los usuarios con permisos para contribuir 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 de .
  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 CI especificados en el archivo YAML.

Error de finalización de la compra

Veo el siguiente error en el archivo de registro durante el paso de desprotección. ¿Cómo lo arreglo?

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

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

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

Actualizaciones de estado que faltan

Mi solicitud de incorporación de cambios en GitHub está bloqueada, ya que Azure Pipelines no actualizó 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 protección de GitHub si usa la aplicación de GitHub. O bien, realice una actualización trivial de la solicitud de incorporación de cambios para ver si el problema se puede resolver.