Creación de repositorios de GitHub

Azure Pipelines

Azure Pipelines crear y validar automáticamente cada solicitud de extracción y confirmar en el repositorio GitHub cambios. En este artículo se describe cómo configurar la integración entre GitHub y Azure Pipelines.

Si no está seguro de la integración de Azure Pipelines con GitHub, siga los pasos descritos en Creación de la primera canalización para que la primera canalización funcione con un repositorio de GitHub y, a continuación, vuelva a este artículo para obtener más información sobre cómo configurar y personalizar la integración entre GitHub y Azure Pipelines.

Organizaciones y usuarios

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

Las organizaciones

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

Azure DevOps' consta de organizaciones que contienen proyectos. Consulte Planeación de la estructura organizativa.

Azure DevOps puede reflejar la estructura GitHub con:

• Una Azure DevOps para la cuenta GitHub usuario o la organización
• Azure DevOps projects for your GitHub repositories

Para configurar una estructura idéntica en Azure DevOps:

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

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

Usuarios

Los GitHub usuarios no obtienen acceso automáticamente a Azure Pipelines. Azure Pipelines no es consciente de las GitHub identidades. Por esta razón, 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 la solicitud de registro mediante su identidad de GitHub correo electrónico. Debe crear explícitamente nuevos usuarios en Azure Pipelines para replicar GitHub usuarios. Una vez creados los nuevos usuarios, puede configurar sus permisos en Azure DevOps reflejar sus permisos en GitHub. También puede configurar notificaciones en Azure DevOps mediante su Azure DevOps identidad.

GitHub de organización

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

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

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

GitHub roles de cuenta de usuario

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

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

El GitHub de cuenta de usuario se asigna a Azure DevOps permisos de la organización como se muestra a continuación.

GitHub de repositorio

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

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

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

Si el GitHub de aplicaciones concede permiso a los equipos, puede crear equipos que coincidan en la sección de la configuración Azure DevOps Teams proyecto. 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 Azure DevOps, siga estos pasos:

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

Acceso a GitHub repositorios

Azure Pipelines tener acceso a los repositorios para desencadenar sus compilaciones y capturar su código durante las compilaciones.

Hay 3 tipos de autenticación para conceder Azure Pipelines acceso a los repositorios de GitHub durante la creación de una canalización.

GitHub autenticación de aplicaciones

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

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

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

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

Permisos necesarios en GitHub

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

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

• Si el repositorio está en la cuenta de GitHub personal de otra persona, la otra persona debe instalar la aplicación Azure Pipelines GitHub en su cuenta personal GitHub usuario. 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 GitHub de su propiedad, instale la aplicación Azure Pipelines GitHub en GitHub organización. También 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 GitHub que otra persona posee, un propietario o administrador del repositorio de la organización de GitHub debe instalar la aplicación Azure Pipelines GitHub en la organización. Debe agregarse como colaborador o debe agregarse su 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.

GitHub permisos de aplicación

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

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

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 GitHub aplicación ya está instalada para su organización. Al crear una canalización para un repositorio de la organización, la aplicación GitHub se usará automáticamente para conectarse a GitHub.

Creación de canalizaciones en varias Azure DevOps y proyectos

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

Autenticación de OAuth

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

Para usar OAuth, haga clic en Elegir una conexión diferente debajo de la lista de repositorios al crear una canalización. A continuación, haga clic en Autorizar para iniciar GitHub y autorizar con OAuth. Se guardará una conexión de OAuth en el proyecto de Azure DevOps para su uso posterior, así como en la canalización que se va a crear.

Permisos necesarios en GitHub

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

• Si el repositorio está en su cuenta de GitHub personal, al menos una vez, autentíquense en GitHub con OAuth con sus credenciales de GitHub personal. Esto se puede hacer en la configuración Azure DevOps proyecto en conexiones Pipelines servicio nueva conexión >> de servicio GitHub >> autorizar. Conceda 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 Azure DevOps proyecto en conexiones Pipelines servicio nueva conexión >> de servicio GitHub >> autorizar. La otra persona debe conceder 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 se encuentra en una organización GitHub de su propiedad, al menos una vez, autentíquense en GitHub con OAuth mediante las credenciales de su cuenta de GitHub personal. Esto se puede hacer en la configuración Azure DevOps proyecto en conexiones Pipelines servicio nueva conexión >> de servicio GitHub >> autorizar. Conceda Azure Pipelines acceso a su organización en "Acceso a la organización" aquí. Debe agregarse como colaborador o debe agregarse su equipo en la configuración del repositorio en "Colaboradores y equipos".

• Si el repositorio se encuentra en una organización GitHub que otra persona posee, al menos una vez, el propietario de la organización de GitHub debe autenticarse en GitHub con OAuth con sus credenciales de cuenta de GitHub personales. Esto se puede hacer en la configuración Azure DevOps proyecto en conexiones Pipelines servicio nueva conexión >> de servicio GitHub >> autorizar. El propietario de la organización debe conceder Azure Pipelines acceso a la organización en "Acceso a la organización" aquí. Debe agregarse como colaborador o debe agregarse su 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.

Revocación del acceso de OAuth

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

Autenticación de token de acceso personal (PAT)

Las PAT son efectivamente las mismas que OAuth, pero permiten controlar qué permisos se conceden a Azure Pipelines. Las compilaciones GitHub actualizaciones de estado se realizarán en nombre de su identidad personal GitHub usuario. 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 GitHub usuario. Los permisos necesarios son repo , admin:repo_hook , y read:useruser:email . Estos son los mismos permisos necesarios cuando se usa OAuth anterior. Copie el PAT generado en el Portapapeles y péguelo en una nueva conexión GitHub servicio en la configuración Azure DevOps proyecto. Para futuras recuperaciones, asigne un nombre a la conexión de servicio después GitHub nombre de usuario. 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 GitHub con desencadenadores de integración continua y solicitud de incorporación de incorporación de recursos, debe tener configurados los GitHub necesarios. De lo contrario, el repositorio no aparecerá en la lista de repositorios al crear una canalización. En función del tipo de autenticación y la propiedad del repositorio, asegúrese de que está configurado el acceso siguiente.

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

• Si el repositorio está en la cuenta de GitHub personal de otra persona, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: , , y admin:repo_hookread:useruser: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 GitHub que posee, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: , , y admin:repo_hookread:useruser:email . Debe agregarse como colaborador o debe agregarse su equipo en la configuración del repositorio en "Colaboradores y equipos".

• Si el repositorio está en una organización GitHub que otra persona posee, el PAT debe tener los ámbitos de acceso necesarios en Tokens de acceso personal: , , y admin:repo_hookread:useruser:email . Debe agregarse como colaborador o debe agregarse su 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 Azure Pipelines usar un PAT, para eliminarlo posteriormente y evitar su uso adicional, visite Tokens de acceso personal en la configuración GitHub usuario. También puede eliminarlo de la lista de conexiones GitHub servicio en la configuración Azure DevOps proyecto.

Desencadenadores de CI

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

trigger:
- master
- releases/*

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

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

Omisión de CI para confirmaciones individuales

También puede decir a Azure Pipelines omitir la ejecución de una canalización que normalmente se desencadenaría una confirmación. Solo tiene que incluir en el mensaje de confirmación o la descripción de la confirmación [skip ci] HEAD Azure Pipelines omitirá la ejecución de CI. También puede usar cualquiera de las variaciones siguientes.

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

Uso del tipo de desencadenador en condiciones

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, trabajo o fase para excluirla de las validaciones de solicitudes de solicitud de acceso.

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

Comportamiento de los desencadenadores cuando se crean nuevas ramas

Es habitual configurar varias canalizaciones para el mismo repositorio. Por ejemplo, puede tener una canalización para compilar los documentos de la aplicación y otra para compilar el código fuente. Puede configurar desencadenadores de CI con filtros 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 y otra que se desencadene al insertar una actualización en el docs 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 cambios en la nueva rama.

Caracteres comodín

Al especificar una rama o etiqueta, 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 de YAML, debe encapsular el patrón entre comillas, como "*-releases" .
• En el caso de las ramas, etiquetas y rutas de acceso, puede aparecer un carácter comodín en cualquier parte del patrón.

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

Desencadenadores de PR

Los desencadenadores de solicitud de extracción (PR) hacen que una canalización se ejecute siempre que se abra una solicitud de extracción con una de las ramas de destino especificadas o cuando se realizan actualizaciones en dicha solicitud de extracción.

pr:
- master
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

Ramas protegidas

Puede ejecutar una compilación de validación con cada confirmación o solicitud de extracción que tenga como destino una rama e incluso evitar que las solicitudes de extracción se fusionen hasta que una compilación de validación se realiza correctamente.

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

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

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

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

   

Contribuciones de orígenes externos

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

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

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

Restricciones de acceso

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

• Secretos: De forma predeterminada, los secretos asociados a la canalización no están disponibles para las validaciones de solicitudes de extracción de bifurcaciones. Vea Validate contributions from forks (Validar contribuciones desde bifurcaciones).
• Acceso entre proyectos: Todas las canalizaciones de Azure DevOps proyecto público se ejecutan con un token de acceso restringido al proyecto. Pipelines en un proyecto público puede acceder a recursos como artefactos de compilación o resultados de pruebas solo dentro del proyecto y no en otros proyectos de la Azure DevOps organización.
• Azure Artifacts paquetes: si las canalizaciones necesitan acceder a paquetes de Azure Artifacts, debe conceder explícitamente permiso a la cuenta de servicio de compilación de Project para acceder a las fuentes de paquetes.

Contribuciones de bifurcaciones

Cuando se crea una canalización, se desencadena automáticamente para las solicitudes de extracción desde bifurcaciones del repositorio. Puede cambiar este comportamiento teniendo en cuenta detenidamente cómo afecta a la seguridad. Para habilitar o deshabilitar este comportamiento:

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

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

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

Para omitir esta precaución en GitHub canalizaciones, 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.

Consideraciones importantes de seguridad

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

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

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

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

  • Si debe usar un agente auto-hospedado, 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 extracción.

Desencadenadores de comentario

Los colaboradores del repositorio pueden comentar una solicitud de extracción para ejecutar manualmente una canalización. Estas son algunas de las razones comunes por las que puede que quiera hacer esto:

• Es posible que no quiera compilar automáticamente solicitudes de extracción 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 bifurcados.
• Es posible que desee ejecutar un conjunto de pruebas opcional o una compilación de validación adicional.

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

1. Habilite los desencadenadores de solicitud de extracción para la canalización y asegúrese de que no excluya la rama de destino.
2. En el Azure Pipelines web, edite la canalización y elija Más acciones, Desencadenadores. A continuación, en Validación de solicitudes de extracción,habilite Requerir comentario de un miembro del equipo antes de crear una solicitud de extracción.
   • Elija On all pull requests (Todas las solicitudes de extracción) para requerir el comentario de un miembro del equipo antes de crear una solicitud de extracción. Con este flujo de trabajo, un miembro del equipo revisa la solicitud de extracción y desencadena la compilación con un comentario una vez que la solicitud de extracción se considera segura.
   • Elija Solo en las solicitudes de extracción de miembros que no son de equipo para requerir el comentario de un miembro del equipo solo cuando un miembro que no es de equipo realiza una solicitud de solicitud de cambios. En este flujo de trabajo, un miembro del equipo no necesita la revisión de un miembro del equipo secundario para desencadenar una compilación.

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

Se pueden emitir los siguientes comandos para Azure Pipelines comentarios:

Solución de problemas de desencadenadores de comentarios de solicitud de extracción

Si tiene los permisos de repositorio necesarios, pero los comentarios no desencadenan las canalizaciones, asegúrese de que su pertenencia es pública en la organización del repositorio o agrégase directamente como colaborador del repositorio. Azure Pipelines 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 GitHub organización de privada a pública aquí (reemplace Your-Organization por el nombre de la organización): https://github.com/orgs/Your-Organization/people .

Restauración

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

Versión preferida de Git

El Windows cuenta con 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 verdadera en los agentes que no Windows datos.

Ruta de acceso de finalización de la compra

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

Submódulos

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

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

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

• Autenticado:

  • Contenido en el mismo proyecto que el repositorio Azure Repos Git 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 agrega mediante una dirección URL relativa al repositorio principal. Por ejemplo

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

      En este ejemplo, el submódulo hace referencia a un repositorio (FabrikamFiber) en la misma Azure DevOps organización, 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 en el segundo proyecto si (a) concede 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 Acceso a repositorios, artefactos y otros recursos.

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

Alternativa al uso de la opción Checkout submodules

En algunos casos no se puede usar la opción Checkout submodules (Submódulos de finalización de la compra). Es posible que tenga un escenario en el que se necesite un conjunto diferente de credenciales para acceder a los submódulos. Esto puede ocurrir, por ejemplo, si el repositorio principal y los repositorios de submódulos no están almacenados 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 Checkout submodules (Extraer submódulos), puede usar en su lugar un paso de script personalizado para capturar submódulos. En primer lugar, obtenga un token de acceso personal (PAT) y prefiéndolo con pat: . A continuación, codifica en base64 esta cadena con prefijo para crear un token de autenticación básico. Por último, agregue este script a la canalización:

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

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

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

Captura superficial

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

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

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

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 del control de versiones.

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

Compilación limpia

Puede realizar diferentes formas de limpiar el directorio de trabajo del agente auto hospedado antes de que se ejecute una compilación.

En general, para un rendimiento más rápido de los agentes auto-hospedados, 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 Clean 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 son las siguientes.

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

git clean -ffdx
git reset --hard HEAD

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

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.

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

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

Las cuatro primeras variables están predefinidas. My.Variable puede definirlo usted en la My.Variable.

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

Una vez que la canalización de compilación etiqueta los orígenes, 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 que se creó. La etiqueta se considera un artefacto de compilación, ya que la genera la compilación. Cuando la compilación se elimina manualmente o a través de una directiva de retención, también se elimina la etiqueta .

Variables predefinidas

Al compilar un repositorio GitHub, la mayoría de las variables predefinidas están disponibles para los trabajos. Sin embargo, dado 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 se Azure Pipelines en GitHub: estados básicos y GitHub de comprobación. GitHub checks solo está disponible con GitHub Apps.

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

• En el caso de los PR, se muestran en la pestaña Conversaciones de pr.
• Para 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 de GitHub PAT o OAuth

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

Los estados de PAT o OAuth GitHub las conexiones solo se envían en el nivel de ejecución. En otras palabras, puede tener un estado único 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.

GitHub checks

Para las canalizaciones configuradas mediante Azure Pipelines GitHubaplicación ), el estado se vuelve a publicar en forma de GitHub Checks. GitHub permite enviar información detallada sobre el estado de la canalización, así como pruebas, cobertura de código y errores. La API GitHub Checks se puede encontrar aquí.

Para todas las canalizaciones que usan GitHub app, se publican comprobaciones para la ejecución general, así como para cada trabajo de esa ejecución.

GitHub permite tres opciones cuando se producirá un error en una o varias ejecuciones de comprobación para una pr/confirmación. Puede optar por "volver a ejecutar" la comprobación individual, volver a ejecutar todas las comprobaciones con errores en esa pr/confirmación o volver a ejecutar todas las comprobaciones, tanto si se realizaron correctamente inicialmente como si no.

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

Preguntas más frecuentes

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

• Tipos de conexión: No estoy seguro de qué tipo de conexión estoy usando para conectar mi canalización a GitHub.
• Desencadenadores con errores: Mi canalización no se desencadena cuando se inserta una actualización en el repositorio.
• Error de desprotección: Se está desencadenando mi canalización, pero se produce un error en el paso de desprotección.
• Versión incorrecta: Mi canalización se ejecuta, pero usa una versión inesperada del origen o YAML.
• Actualizaciones de estado que faltan: Mis GitHub se bloquean porque Azure Pipelines no notifró una actualización de estado.

Tipos de conexión

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

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

• Desde GitHub: si un repositorio está configurado para usar la aplicación GitHub, los estados de las respuestas y confirmaciones serán Comprobar ejecuciones. Si el repositorio se Azure Pipelines con conexiones OAuth o PAT, los estados serán el estilo de estado "antiguo". Una manera rápida de determinar si los estados son Check Runs (Comprobar ejecuciones) o simple statuses (Estados simples) es consultar la pestaña "conversation" (conversación) en una GitHub PR.

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

• Desde Azure Pipelines: también puede determinar el tipo de conexión inspeccionando la canalización en Azure Pipelines interfaz de usuario. Abra el editor de la canalización. Seleccione Desencadenadores para abrir el editor clásico de la canalización. A continuación, seleccione la pestaña YAML y, a continuación, el paso Obtener orígenes. 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 está utilizando:

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

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

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

1. Vaya aquí e instale la aplicación en la GitHub organización del repositorio.
2. Durante la instalación, se le redirigirá a Azure DevOps elegir una organización Azure DevOps proyecto. 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 GitHub app a su Azure DevOps organización. Si elige incorrectamente, puede visitar esta página para desinstalar la aplicación GitHub de su organización GitHub e iniciar de nuevo.
3. En la página siguiente que aparece, no es necesario continuar con la creación de una nueva canalización.
4. Para editar la canalización, visite la Pipelines (por ejemplo, , seleccione la canalización y https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build) haga 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 "Authorized using connection" (Autorizado mediante conexión), haga clic en "Cambiar" y seleccione la conexión GitHub App 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". Haga clic en el vínculo a la ejecución de canalización que se ha en cola para asegurarse de que se realiza correctamente.
9. Cree (o cierre y vuelva a abrir) una solicitud de extracción 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 GitHub repositorio para elegir en Azure Pipelines?

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

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

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

Esto significa que el repositorio ya está asociado a una canalización de una organización diferente. 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 extracción en GitHub repositorio y haga el comentario /azp where . Esto informa a Azure DevOps organización a la que está asignado el repositorio.

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

Desencadenadores con errores

Just created a new YAML pipeline with CI/PR triggers, but the pipeline is not being triggered.

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

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

  

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

  

• ¿Usa la conexión GitHub aplicación 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 GitHub aplicación, siga estos pasos:

  • ¿La asignación está configurada correctamente entre GitHub y Azure DevOps? Abra una solicitud de extracción en GitHub repositorio y haga el comentario /azp where . Esto informa a Azure DevOps organización 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 Azure DevOps organización 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 un único DevOps organización. Solo las canalizaciones del primer Azure DevOps organización se pueden desencadenar automáticamente. Para cambiar la asignación, desinstale la aplicación GitHub organización y vuelva a instalarla. Cuando vuelva a instalarlo, 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 GitHub, siga estos pasos:

  1. Las conexiones OAuth y PAT se basan en webhooks para comunicar las 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 de 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.

• El tráfico de Azure DevOps podría limitarse por GitHub. 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 extracción, esta llamada puede producir un error debido a dicha limitación. En este caso, vea si puede reducir la frecuencia de 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 comprobarlo. Si la canalización está en pausa o deshabilitada, los desencadenadores no funcionan.

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

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

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

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

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

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

Mis desencadenadores de CI o PR han funcionado bien. Pero ahora han dejado de funcionar.

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

• ¿Tiene conflictos de combinación en la PR? Para una solicitud de solicitud de cambios que no desencadene una canalización, ábrala y compruebe si tiene un conflicto de combinación. Resuelva el conflicto de combinación.

• ¿Experimenta un retraso en el procesamiento de eventos de inserción o de solicitudes de inserción? Normalmente, puede comprobarlo si el problema es específico de una sola canalización o es común a todas las canalizaciones o repositorios del proyecto. Si una inserción o una actualización de solicitudes de inserción en cualquiera de los repositorios presenta este síntoma, es posible que experimentemos retrasos en el procesamiento de los eventos de actualización. Compruebe si se está experimentando una interrupción del servicio en nuestra página de estado. Si la página de estado muestra un problema, nuestro equipo debe haber empezado a trabajar en él. Compruebe la página con frecuencia para ver si hay actualizaciones sobre el problema.

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

Los usuarios con permisos para contribuir con 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 Azure Pipelines usuario.
2. Vaya al menú Desencadenadores.
3. Seleccione Invalidar el desencadenador de integración continua de YAML desde aquí.
4. Especifique las ramas que se incluirán o excluirán para el desencadenador.

Al seguir estos pasos, se omiten los desencadenadores de CI especificados en el archivo YAML.

Error de desprotección

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

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

Esto podría deberse a una interrupción del 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. ¿A qué se debe?

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

Actualizaciones de estado que faltan

Mi PR en GitHub está bloqueada porque Azure Pipelines actualizo el estado.

Esto podría ser un error transitorio que provocó Azure DevOps no poder comunicarse con GitHub. Vuelva a intentar la comprobación GitHub si usa la GitHub aplicación. O bien, realice una actualización trivial de la PR para ver si se puede resolver el problema.

Artículos relacionados

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