|

PR-Agent en Azure DevOps: por qué tu pipeline no arranca

En pocas palabras: PR-Agent se usa en Azure DevOps con una policy de Build Validation marcada Required en la rama destino, porque Azure Repos Git ignora el bloque pr: del YAML. Para responder comandos como /review hace falta un service hook con API v2.0, porque los pipelines no arrancan desde comentarios.

Para usar PR-Agent en Azure DevOps hay que olvidarse del bloque pr: del YAML: Azure Repos Git valida pull requests con una policy de Build Validation en la rama destino. Los comandos por comentario, como /review, exigen un service hook, porque Azure Pipelines no arranca desde comentarios.

PR-Agent es un agente de revisión de pull requests que, según la documentación de Qodo Merge, corre en Azure DevOps y tiene comandos como describe, review, improve y ask. Se ejecuta como imagen Docker dentro de un pipeline o como servidor de webhooks, y se autentica con un PAT o con DefaultAzureCredential. Sirve a equipos que revisan código en Azure Repos y quieren resúmenes y sugerencias automáticas sobre cada PR.

En este artículo:

En 30 segundos

  • Trigger: la validación va en Project Settings > Repositories > Branches, con el pipeline de PR-Agent como Build Validation marcada Required.
  • Permisos y límites: hay que ser project administrator del proyecto dueño del repo, y los PR en draft no disparan el pipeline aunque exista la policy.
  • Comentarios: /review escrito en un hilo solo funciona con un service hook; el evento de comentarios exige API v2.0 y un endpoint HTTPS.
  • Identidad: con PAT, las llamadas corren como la persona que lo creó; con DefaultAzureCredential, el agente tiene su propia identidad vía Microsoft Entra ID.
  • Sin dato: la documentación no informa el costo por PR del modo pipeline ni si el webhook anda en Azure DevOps Server con air gap.

¿Por qué el bloque pr: del YAML no dispara pipelines en Azure Repos Git?

Porque Azure Repos Git implementa la validación de pull requests con branch policies y no con una sección pr: en el YAML. Si copiaste el workflow de GitHub, el pipeline no corre hasta que alguien agregue una policy de Build Validation en la rama destino. Eso dice el artículo de dev.to que resume la página de PR-Agent y la documentación de Microsoft.

De esa diferencia salen tres cosas: cómo se dispara el agente, con qué identidad se autentica y si puede contestar un comentario. Lo vemos en orden.

Un dato de la documentación de Microsoft sobre Azure Repos Git ayuda a ubicarse: los triggers del YAML (trigger:) son de CI, o sea, de push. Para excluir pasos de una validación de PR, la página propone la condición ne(variables['Build.Reason'], 'PullRequest'), lo que confirma que las validaciones de PR existen como un tipo de ejecución aparte.

¿Cómo instalar PR-Agent en Azure DevOps paso a paso con Build Validation?

Creás un pipeline que corre la imagen pragent/pr-agent:latest, lo agregás como Build Validation Required en la rama destino y borrás el bloque pr: de azure-pipelines.yml. Necesitás ser project administrator del proyecto dueño del repo, y el pipeline requiere permiso explícito sobre el variable group donde están el PAT y la clave del modelo.

  1. Armá el pipeline. Corre la imagen como contenedor con el entrypoint vacío, arma la URL del PR con System.CollectionUri, System.TeamProject, Build.Repository.Name y System.PullRequest.PullRequestId, define config__git_provider=azure y llama al CLI tres veces: describe, review e improve.
  2. Cargá los secretos. El PAT y la clave del modelo van en un variable group, y el pipeline necesita permiso explícito para leerlo. Si no, el job falla por un secreto vacío.
  3. Agregá la policy. En Project Settings > Repositories > Branches, elegí la rama destino, abrí Branch Policies y sumá el pipeline como Build Validation marcada Required.
  4. Borrá el bloque pr:. Azure Repos Git lo ignora, así que solo confunde al próximo que lea el archivo.

Ejemplo hipotético para que se entienda la URL: con la organización “miorg”, el proyecto “Plataforma” y el repo “api”, el PR 42 tendría la forma https://dev.azure.com/miorg/Plataforma/_git/api/pullrequest/42. Tu pipeline arma ese texto con las cuatro variables. Ya lo cubrimos antes en automatizar tus pipelines con un servidor MCP.

Ahora los límites que según la fuente conviene tener presentes:

  • Los PR en draft no disparan nada. Un equipo que abre todo como draft no va a ver ninguna revisión hasta marcar el PR como listo.
  • La validación corre sobre el merge commit de la rama de origen y la destino.
  • [skip ci] no la frena. Según dev.to, un commit con [skip ci] suprime los pipelines disparados por esa rama, pero la Build Validation igual corre. Microsoft documenta [skip ci] para pushes de CI, así que no sirve para controlar el gasto de esta revisión.

Propuesta editorial para verificar la instalación (no viene de la fuente ni la probamos): abrí un PR de prueba, ya fuera de draft, contra una rama con la policy y chequeá que el check aparezca en el PR y que PR-Agent publique describe, review e improve. Después repetí con un PR en draft; si ahí no pasa nada, el comportamiento coincide con lo documentado.

¿Puede PR-Agent responder comentarios como /review en Azure DevOps?

Sí, pero no desde el pipeline. Azure Pipelines no puede dispararse desde un comentario de PR (la documentación de PR-Agent lo dice sin vueltas, según dev.to), así que el modo pipeline solo revisa PR nuevos. Para comandos por comentario necesitás un servidor de webhooks de PR-Agent y un service hook manual en Project Settings > Service hooks.

El hook se crea con el trigger “Pull request created” para una revisión, o “Pull request commented on” para un comando soportado. El evento de comentarios exige API v2.0.

El hook manda basic auth con un usuario y una contraseña que configurás de los dos lados, y por eso el endpoint tiene que ser HTTPS. Eso implica un servidor en algún lado, con certificado, monitoreo y alguien que se acuerde de él (un VPS de donweb.com es una opción, pero la decisión de infraestructura depende de tu política interna).

CriterioModo pipelineModo webhook
TriggerBuild Validation en la rama destinoService hook: PR creado o PR comentado
Comandos por comentarioNoSí, con API v2.0
Servicio que mantenerNinguno (imagen en el pipeline)Servidor propio con HTTPS
Seguridad del entranteNo aplicaBasic auth, usuario y contraseña en ambos lados
pr-agent azure devops diagrama explicativo

La regla práctica: pipeline si querés describe, review e improve automáticos sin un servicio más que cuidar; webhook si tu equipo revisa escribiendo comandos en los hilos. Sobre eso hablamos en desplegar Fabric desde Azure DevOps con service principal.

Otro detalle: PR-Agent reconoce sus propios comentarios leyendo los anteriores, y un saludo genérico como “hi agent” no dispara respuesta. Si esperabas charla libre con el bot, te vas a decepcionar.

¿PAT o DefaultAzureCredential para autenticar PR-Agent en Azure DevOps?

Para algo más que una prueba, conviene DefaultAzureCredential. El PAT es rápido de crear y vence, pero las llamadas a la API corren bajo la identidad de quien lo creó; DefaultAzureCredential usa una managed identity o un service principal y crea una identidad separada para el agente vía Microsoft Entra ID.

En los dos casos, el valor org va en .secrets.toml bajo [azure_devops]. El PAT, si lo usás, va en el mismo archivo. Con DefaultAzureCredential das AZURE_CLIENT_SECRET, o usás la managed identity y, en local, Azure CLI.

[azure_devops]
org = "https://dev.azure.com/miorg/"
# PAT o credenciales Azure: ver la página de instalación de Qodo Merge

Ponele que el PAT lo creó Lucía y un día se va de la empresa: el token vence o se revoca y el “revisor automático” deja de comentar sin avisar a nadie. Con service principal, esa dependencia con una persona desaparece. Lo explicamos a fondo en la comparativa entre Microsoft y GitHub.

Ojo con la sección [azure_devops_server]. Ahí se configuran la identidad estable del agente (un GUID o un nombre único; acepta una lista durante transiciones) y las credenciales del webhook. Se usa para el provider sea cual sea tu edición, así que en el servicio hosteado vas a editar igual una sección con nombre de Server.

¿Qué funciones de PR-Agent Azure DevOps están soportadas y qué no está documentado?

Según la matriz de plataformas que cita dev.to, Describe, Review, Improve, Ask, Add Docs y Help están soportadas en Azure DevOps. Hay tres funciones que no funcionan en esa plataforma y dos que se comportan distinto.

FunciónEstado en Azure DevOps
Describe, Review, Improve, Ask, Add Docs, HelpSoportadas
Generate LabelsSe aplica (el provider puede poner labels)
Update CHANGELOGSe publica como comentario, porque el provider no puede hacer push de archivos
Ask sobre líneas de código, Similar Issues, tagging botNo soportadas

PR-Agent no es la única opción en Azure Repos. Kodus también se conecta por PAT, con una lista fija de scopes; sin Code Write la conexión parece sana y no aparece ningún comentario en el PR. En self-hosted, su webhook de Azure Repos necesita un parámetro token firmado y devuelve 403 si falta.

Otra advertencia: Azure DevOps Services y Azure DevOps Server no son el mismo destino. Las guías con PAT y service hook contra dev.azure.com describen el servicio hosteado, y si estás en Server vas a perseguir permisos que no existen igual. Te puede servir nuestra cobertura de el ataque de malware que afectó repos de GitHub.

Qué está confirmado y qué no

Confirmado por las fuentes:

  • Build Validation en lugar de pr: lo afirma dev.to, que dice apoyarse en la página de PR-Agent y en Microsoft. El extracto de la página de Microsoft con el que trabajamos llega cortado y no incluye ese pasaje, así que esa parte la tomamos del resumen.
  • Modo pipeline sin comentarios y webhook con API v2.0: descritos por la misma fuente secundaria.
  • [skip ci] en pushes de CI: documentado en la página de Microsoft.

Sin establecer en la documentación (octubre de 2026):

  • Costo por PR del modo pipeline: la página de Azure DevOps no da cifra. Si lo necesitás para presupuestar, medilo vos con un período de prueba.
  • Webhook contra Azure DevOps Server con air gap: tampoco hay respuesta; la fuente remite a la referencia general de configuración y al issue tracker.

Errores comunes al configurar PR-Agent en Azure DevOps

  • Dejar el bloque pr: y esperar que corra. Se ignora. Corrección: policy de Build Validation en la rama destino.
  • Probar con un PR en draft. No dispara el pipeline. Corrección: marcalo como listo antes de concluir que algo está roto.
  • Usar [skip ci] para ahorrar minutos de agente. La Build Validation corre igual sobre el merge commit. Corrección: controlá el costo con otro mecanismo.
  • No darle permiso al variable group. El job falla por un secreto vacío. Corrección: autorizá explícitamente el grupo al pipeline.
  • Tocar la sección equivocada. La identidad del agente y las credenciales del webhook van en [azure_devops_server], aun en el servicio hosteado.

Preguntas Frecuentes

¿Por qué mi pipeline no se ejecuta en un pull request de Azure Repos?

Porque Azure Repos Git ignora el bloque pr: del YAML y valida PR con branch policies. Revisá que exista una Build Validation Required en la rama destino, que el PR no esté en draft y que tengas permisos de project administrator para configurarla.

¿Cómo configurar una política de Build Validation en Azure DevOps?

Entrá a Project Settings > Repositories > Branches, elegí la rama destino, abrí Branch Policies y agregá el pipeline como Build Validation marcada Required. Hace falta ser project administrator del proyecto dueño del repositorio.

¿Se puede usar PR-Agent en Azure DevOps?

Sí. La documentación de Qodo Merge tiene una guía de instalación para Azure, y según dev.to están soportadas Describe, Review, Improve, Ask, Add Docs y Help. Ask sobre líneas de código, Similar Issues y el tagging bot no están soportadas.

¿Cómo hacer que PR-Agent responda a /review en un comentario de Azure DevOps?

Necesitás un service hook manual con el trigger “Pull request commented on”, API v2.0 y un endpoint HTTPS de PR-Agent con basic auth configurado en ambos lados. El modo pipeline no puede responder comentarios.

¿Qué diferencia hay entre usar un PAT y DefaultAzureCredential en Azure DevOps?

El PAT vence y hace que las llamadas corran bajo la identidad de quien lo creó. DefaultAzureCredential usa managed identity o service principal y le da al agente una identidad propia vía Microsoft Entra ID.

Conclusión

Lo que cambia respecto de GitHub es el punto de entrada: en Azure Repos, el trigger es una policy de Build Validation y no un bloque del YAML. Si tu equipo quiere revisiones automáticas, alcanza con el pipeline; si quiere conversar con el bot en los hilos, vas a tener que mantener un webhook con HTTPS.

Mi recomendación: arrancá con el pipeline, usá una identidad que no dependa de una persona apenas pases de la prueba, y no prometas a nadie costos por PR ni soporte en Server con air gap, porque la documentación no los establece.

Fuentes

Te puede interesar...