Recursos en canalizaciones YAML

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

En este artículo se describen los recursos de las canalizaciones YAML. Un recurso es cualquier cosa que use una canalización que exista fuera de esa canalización. Los recursos de las canalizaciones YAML pueden ser otras canalizaciones, compilaciones, contenedores, paquetes, repositorios o webhooks.

Después de definir un recurso, puede consumirlo en cualquier lugar de la canalización. Para obtener más información y ejemplos, consulte Definiciones de recursos.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Puede usar el estado del recurso para desencadenar automáticamente las canalizaciones estableciendo la trigger propiedad en la definición de recursos. A continuación, la canalización resources.triggeringAlias y resources.triggeringCategory las variables se establecen en el nombre y la categoría del recurso. Estas variables están vacías a menos que la Build.Reason variable esté establecida ResourceTriggeren .

Los recursos permiten una rastreabilidad completa para los servicios que usa una canalización , incluida la versión, los artefactos, las confirmaciones asociadas y los elementos de trabajo. Si se suscribe para desencadenar eventos en los recursos, puede automatizar completamente los flujos de trabajo de DevOps.

Autorización de recursos

Los recursos deben estar autorizados para usarse en canalizaciones. Los propietarios de recursos controlan los usuarios y canalizaciones que pueden acceder a sus recursos. Hay varias maneras de autorizar una canalización YAML para usar recursos.

• Use la configuración de administración del recurso para conceder permisos de acceso a todas las canalizaciones. Por ejemplo, puede administrar archivos seguros y grupos de variables en la páginaBiblioteca> y grupos de agentes y conexiones de servicio enCanalizaciones de > del proyecto. Esta autorización es conveniente para los recursos que no es necesario restringir, como los recursos de prueba.

• Asegúrese de que tiene al menos rol de usuario en los roles de seguridad del grupo de agentes para el proyecto. Las canalizaciones de YAML que cree están autorizadas automáticamente para usar los recursos en los que tiene el rol usuario .

• Si agrega una definición de recurso a una canalización YAML, pero la compilación produce un error como Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use, asegúrese de que tiene al menos un rol de usuario en el recurso. A continuación, puede elegir la opción para autorizar los recursos en la compilación con errores. Una vez autorizado el recurso, puede iniciar una nueva compilación.

Comprobaciones de aprobación de recursos

Puede usar comprobaciones de aprobación y plantillas para controlar manualmente el uso de recursos. Mediante la comprobación de aprobación de plantilla necesaria, puede requerir cualquier canalización que use un determinado recurso o entorno para ampliar desde una plantilla YAML específica.

La configuración de una aprobación de plantilla necesaria mejora la seguridad asegurándose de que el recurso solo se usa en condiciones específicas. Para obtener más información, consulte Uso de plantillas para la seguridad.

Selector manual de versiones de recursos

Azure Pipelines evalúa las versiones predeterminadas de los recursos en función de sus definiciones de recursos. Para ejecuciones programadas o ejecuciones manuales si no elige manualmente una ejecución, Azure Pipelines considera que solo se ha completado correctamente la integración continua (CI) para evaluar las versiones de recursos predeterminadas.

Puede usar el selector manual de versiones de recursos para elegir diferentes versiones de recursos al desencadenar manualmente una canalización de implementación continua (CD) de YAML. El selector de versiones de recursos se admite para los recursos de canalización, compilación, repositorio, contenedor y paquete.

En pipeline el caso de los recursos, el selector de versiones manual le permite ver todas las ejecuciones disponibles en todas las ramas, buscar las ejecuciones en función del número o la rama de canalización y elegir una ejecución correcta, con errores o en curso.

No es necesario esperar a que se complete una ejecución de CI o volver a ejecutarla debido a un error no relacionado, antes de poder ejecutar la canalización de CD. Tiene la flexibilidad de elegir cualquier ejecución que sepa que ha generado los artefactos que necesita.

Para usar el selector de versión del recurso, seleccione Recursos en el panel Ejecutar canalización , seleccione un recurso y elija una versión específica de la lista de versiones disponibles. En el caso de los recursos en los que no se pueden capturar versiones disponibles, como los paquetes de GitHub, puede escribir la versión deseada en el campo de texto.

Definiciones de recursos

Los recursos de canalización de YAML pueden ser:

• Otras canalizaciones
• compilaciones de software
• Recipientes
• Paquetes
• Repositorios o
• Webhooks.

En las secciones siguientes se proporcionan definiciones y ejemplos de las categorías de recursos de canalización de YAML. Para obtener información completa sobre el esquema, consulte la definición de recursos en la referencia de esquema YAML para Azure Pipelines.

Recurso de canalizaciones

Puede usar recursos de CI pipeline como desencadenadores para los flujos de trabajo de CD. También puede hacer referencia a pipeline recursos de la canalización para descargar artefactos o usar variables de recursos de canalización. Solo Azure Pipelines puede usar el recurso pipelines.

En la definición del pipelines recurso:

• pipeline es un nombre único que se usa para hacer referencia a los recursos de canalización.
• source es el nombre de la canalización que generó los artefactos de canalización.

Para obtener información completa sobre el esquema, consulte la definición resources.pipelines.pipeline .

Definiciones de recursos de canalización de ejemplo

La siguiente definición de recurso de ejemplo consume artefactos de una canalización dentro del mismo proyecto de Azure DevOps.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Para especificar una canalización desde otro proyecto, incluya el project nombre en la definición de recursos. En el ejemplo siguiente también se usa branch para resolver la versión predeterminada cuando la canalización se desencadena manualmente o mediante programación. La entrada de rama no puede tener caracteres comodín.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Evaluación de la versión del recurso

Azure Pipelines evalúa las versiones predeterminadas de los recursos en función de sus definiciones de recursos. Las versiones predeterminadas del artefacto de recursos de una canalización dependen de si la canalización se ejecuta manualmente o según la programación, o desencadenadores en función del resultado de la ejecución del recurso.

Para una ejecución de canalización manual o programada, los valores de las versionpropiedades , branchy tags de la pipeline definición de recursos definen las versiones del artefacto. La branch entrada no puede tener caracteres comodín y las tags propiedades usan el AND operador .

En el caso de ejecuciones programadas o ejecuciones manuales si no usa el selector de versiones, Azure Pipelines solo considera que la integración continua (CI) se ejecuta correctamente al evaluar las versiones de recursos predeterminadas. En el caso de las ejecuciones manuales, puede invalidar las versiones definidas mediante el selector de versiones manual.

En la tabla siguiente se enumeran pipeline las propiedades de definición de recursos y las versiones de artefacto que especifican.

La siguiente pipeline definición de recursos usa las branch propiedades y tags para evaluar la versión predeterminada cuando la canalización se programa o se desencadena manualmente. La myCIAlias versión de artefactos es la compilación más reciente que se ejecuta en la main rama que tiene las Production etiquetas y PreProduction .

resources:
  pipelines:
  - pipeline: myCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Desencadenadores de recursos de canalización

En el caso de las ejecuciones de canalización que se desencadenan en el resultado de una ejecución de recursos, la configuración de la trigger propiedad en la definición de recursos determina las versiones predeterminadas del artefacto de recursos. Para usar un pipeline recurso como desencadenador para ejecutar la canalización actual, debe establecer la trigger propiedad . Si no incluye una trigger propiedad, las ejecuciones de recursos no desencadenan ejecuciones de canalización actuales.

Cuando una canalización se desencadena en función de un trigger valor en una pipeline definición de recursos, se omiten los valores de la definición versiongeneral de recursos , branchy tags . Las trigger propiedades determinan las versiones del artefacto.

En la tabla siguiente se describe cómo afectan las propiedades al trigger comportamiento del desencadenador.

En el ejemplo siguiente se muestra una definición de recursos de canalizaciones con un sencillo trigger.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger: true

En el ejemplo siguiente se muestra un recurso de canalización trigger con condiciones de rama.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

En el ejemplo siguiente se usan stages filtros para evaluar las condiciones de desencadenador para las canalizaciones de CD. El desencadenador stages usa el AND operador . La canalización de CD se desencadena tras completar correctamente todas las fases enumeradas.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Fabrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

En el ejemplo siguiente se usan tags filtros para la evaluación de versión predeterminada y para el desencadenador. Las trigger etiquetas usan el AND operador . El tags conjunto de pipeline definiciones de recursos es diferente de las etiquetas establecidas en las ramas del repositorio de Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

La canalización siguiente se ejecuta cada vez que la canalización de recursos SmartHotel-CI:

• Se ejecuta en una de las releases ramas o en la main rama.
• Se etiqueta con Verified y Signed.
• Completa las Production fases y PreProduction .

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Descarga del artefacto de canalización

Puede usar el download paso de una canalización YAML para descargar artefactos asociados a la ejecución actual o con otro pipeline recurso.

Los artefactos solo se descargan automáticamente en trabajos de implementación. Todos los artefactos de la canalización actual y todos sus pipeline recursos se descargan automáticamente y están disponibles al principio de cada trabajo de implementación. Puede invalidar este comportamiento estableciendo downloadnoneen o especificando otro pipeline identificador de recurso.

En un trabajo de compilación normal, los artefactos no se descargan automáticamente. Use download explícitamente cuando sea necesario.

En el download paso, la propiedad opcional artifact especifica nombres de artefacto. Si no se especifica, todos los artefactos disponibles se descargan.

La propiedad opcional patterns define patrones que representan los archivos que se van a descargar. Para obtener información completa sobre el esquema, consulte la definición steps.download .

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Artefactos de la descarga de pipeline recursos en $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Para obtener más información, consulte Publicación y descarga de artefactos de canalización. Para obtener una manera alternativa de descargar artefactos de canalización, consulte Descarga de artefactos.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Recurso de compilaciones

Si tiene un sistema de compilación de CI que genera artefactos, puede consumir los artefactos con builds recursos.

La categoría builds es extensible. Un recurso build puede proceder de cualquier sistema de integración continua externo, como Jenkins, TeamCity o CircleCI. Puede usar builds para escribir una extensión para consumir artefactos del servicio de compilación o introducir un nuevo tipo de servicio.

En la definición build, version se establece por defecto con el valor de la compilación correcta más reciente. Debe establecer trigger explícitamente si lo desea. Para obtener información completa sobre el esquema, consulte la definición resources.builds.build .

En el ejemplo siguiente, Jenkins es el tipo de recurso.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Tarea downloadBuild

Los build artefactos de recursos no se descargan automáticamente en trabajos o deploy-jobs. Para consumir artefactos del recurso build como parte de los trabajos, debe agregar explícitamente la tarea downloadBuild. Puede personalizar el comportamiento de descarga de cada implementación o trabajo.

La downloadBuild tarea se resuelve automáticamente en la tarea de descarga correspondiente para el tipo de recurso que define el tiempo de build ejecución. Artefactos de la descarga de build recursos en $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

En la definición downloadBuild, especifique el recurso desde el que se van a descargar artefactos. La propiedad opcional artifact especifica los artefactos que se van a descargar. Si no se especifica, todos los artefactos asociados a la descarga de recursos.

La propiedad opcional patterns define una ruta de acceso de minimatch o una lista de rutas de acceso de minimatch que se van a descargar. Si está en blanco, se descarga todo el artefacto. En el ejemplo siguiente solo se descargan los archivos *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Para obtener información completa sobre el esquema, consulte la definición steps.downloadBuild .

Recurso repositorios

Use la repository palabra clave para informar al sistema sobre los repositorios externos si:

• La canalización tiene plantillas en otro repositorio.
• Quiere usar la desprotección de varios repositorios con un repositorio que requiera una conexión de servicio.

Por ejemplo:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Para obtener información completa sobre el esquema, consulte la definición resources.repository.repository .

Tipos de recursos de repositorio

Azure Pipelines admite los tipos de gitrepositorio , github, githubenterprisey bitbucket .

• El tipo git hace referencia al repositorio de Azure Repos de Git.
• Los repositorios de GitHub Enterprise requieren una conexión de servicio de GitHub Enterprise para la autorización.
• Los repositorios de Bitbucket Cloud requieren una conexión de servicio de Bitbucket Cloud para la autorización.

En la tabla siguiente se describen los repository tipos de recursos:

Variables de recursos del repositorio

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url
resources.repositories.<alias>.version

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Palabra clave Checkout para repositorios

Los repositorios del recurso repository no se sincronizan automáticamente en los trabajos. Puede usar la checkout palabra clave para capturar un repositorio definido en un repository recurso. Para obtener más información, consulte Restauración de repositorios múltiples en la canalización. Para obtener información completa sobre el esquema, consulte la definición steps.checkout .

Recurso de contenedores

Puede usar containers recursos para consumir imágenes de contenedor en las canalizaciones de CI/CD. Un recurso container puede ser un registro de Docker público o privado o una instancia de Azure Container Registry.

Puede consumir una imagen de recurso de contenedor genérica como parte de los trabajos o usarla en trabajos de contenedor. Si la canalización requiere la compatibilidad de uno o varios servicios, también debe crear y conectarse a contenedores de servicio. Puede usar volúmenes para compartir datos entre servicios.

Si necesita consumir imágenes de un registro de Docker, puede definir un recurso de contenedor genérico sin usar una type palabra clave . Por ejemplo:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp 

Para obtener información de esquema completa, consulte la definición resources.containers.container .

Tipo de recurso de Azure Container Registry

Para consumir las imágenes de Azure Container Registry, puede usar el tipo de recurso de contenedor de primera clase acr. Puede usar este tipo de recurso en los trabajos y habilitar desencadenadores de canalización automática.

Necesita permisos de colaborador o propietario de Azure Container Registry para usar desencadenadores de canalización automáticas. Para obtener más información, vea Roles y permisos de Azure Container Registry.

Para usar el tipo de recurso acr, debe especificar los valores azureSubscription, resourceGroup y repository para Azure Container Registry. Por ejemplo:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production* 

Variables de recursos de contenedor

Una vez definido un contenedor como recurso, los metadatos de la imagen de contenedor se pasan a la canalización como variables. Se puede acceder a información, como la imagen, el registro y los detalles de conexión, en todos los trabajos que se utilizan en las tareas de implementación del contenedor.

Las variables de recursos de contenedor funcionan con Docker y Azure Container Registry. No se pueden usar variables de recursos de contenedor para contenedores de imágenes locales. La location variable solo se aplica al tipo de recurso contenedor acr .

En el siguiente ejemplo hay una conexión de servicio de Azure Resource Manager llamada arm-connection. Para más información, consulte Registros, repositorios e imágenes de contenedor de Azure.

resources:
  containers:
  - container: mycontainer
    type: acr
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

steps:  
- script: echo ${{ parameters.myWebHookResource.resource.message.title }}

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Rastreabilidad

Azure Pipelines proporciona rastreabilidad completa para cualquier recurso consumido a nivel de canalización o de trabajo de implementación. Azure Pipelines muestra la siguiente información para cada ejecución de canalización que usa recursos:

• Si un recurso desencadenó la canalización, el recurso que desencadenó la canalización.
• Las versiones de recursos y los artefactos consumidos.
• Confirmaciones asociadas a cada recurso.
• Elementos de trabajo asociados a cada recurso.

Información de canalización de CD asociada para canalizaciones de CI

Para proporcionar rastreabilidad de un extremo a otro, puede realizar un seguimiento de las canalizaciones de CD que consumieron una canalización de CI específica a través del pipelines recurso. Si otras canalizaciones consumieron la canalización de CI, verá una pestaña Canalizaciones asociadas en la vista Ejecutar . La vista muestra todas las ejecuciones de canalización de YAML de CD que consumieron la canalización de CI y sus artefactos.

Rastreabilidad del entorno

Después de implementar una canalización en un entorno, puede ver una lista de los recursos que consumió y sus confirmaciones y elementos de trabajo asociados.

Preguntas más frecuentes

¿Cuándo debo usar recursos de canalizaciones, el acceso directo de descarga o la tarea Descargar artefactos de canalización?

El uso de un recurso pipelines es una manera de consumir artefactos de una canalización de integración continua y también de configurar desencadenadores automatizados. Un recurso proporciona visibilidad completa sobre el proceso al mostrar la versión consumida, los artefactos, las confirmaciones y los elementos de trabajo. Al definir un recurso de canalización, los artefactos asociados se descargan automáticamente en los trabajos de implementación.

Puede usar el acceso directo download para descargar los artefactos en trabajos de compilación o invalidar el comportamiento de descarga en los trabajos de implementación. Para obtener más información, consulte la definición steps.download .

La tarea Descargar artefactos de canalización no proporciona seguimiento ni desencadenadores, pero a veces tiene sentido usar esta tarea directamente. Por ejemplo, podría tener una tarea de script almacenada en una plantilla diferente que requiera que se descarguen artefactos de una compilación. O bien, es posible que no quiera agregar un recurso de canalización a una plantilla. Para evitar dependencias, puede usar la tarea Descargar artefactos de canalización para pasar toda la información de compilación a una tarea.

¿Cómo puedo desencadenar una ejecución de canalización cuando se actualiza la imagen de Docker Hub?

El desencadenador de recursos de contenedor no está disponible para las canalizaciones de Docker Hub para YAML, por lo que debe configurar una canalización de versión clásica.

1. Cree una nueva conexión de servicio de Docker Hub.
2. Cree una canalización de versión clásica y agregue un artefacto de Docker Hub. Establezca la conexión de servicio y seleccione el espacio de nombres, el repositorio, la versión y el alias de origen.
3. Seleccione el desencadenador y establezca el desencadenador de implementación continua en Habilitar. Cada vez que se produzca una inserción de Docker en el repositorio seleccionado se creará una versión.
4. Cree una fase y un trabajo nuevos. Agregue dos tareas: el inicio de sesión de Docker y Bash.
   • La tarea Docker tiene la acción login y le inicia sesión en Docker Hub.
   • La tarea Bash ejecuta docker pull <hub-user>/<repo-name>[:<tag>].

¿Cómo puedo validar y solucionar problemas de mi webhook?

1. Cree una conexión de servicio.

2. Haga referencia a la conexión de servicio y asigne un nombre al webhook en la sección webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Ejecutar la canalización. El webhook se crea en Azure como una tarea distribuida para su organización.

4. Realice una llamada API POST con JSON válido en el cuerpo a https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Si recibe una respuesta de código de estado 200, el webhook está listo para su consumo por la canalización.

Si recibe una respuesta de código de estado 500 con el error Cannot find webhook for the given webHookId ..., el código puede estar en una rama que no sea la predeterminada. Para solucionar este problema:

1. Seleccione Editar en la página de la canalización.
2. En el menú Más acciones, seleccione Desencadenadores.
3. Seleccione la pestaña YAML y luego seleccione Obtener orígenes.
4. En Rama predeterminada para compilaciones manuales y programadas, actualice la rama de características.
5. Seleccione Guardar y poner en cola.
6. Después de que esta canalización se ejecute correctamente, realice una llamada API POST con JSON válido en el cuerpo a https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Ahora debería recibir una respuesta de código de estado 200.

¿Por qué no funcionó el desencadenador de recursos?

Los desencadenadores de recursos no se pueden ejecutar porque:

• El origen de la conexión de servicio proporcionada no es válido.
• El desencadenador no está configurado o hay errores de sintaxis en el desencadenador.
• Las condiciones del desencadenador no coinciden.

Para ver por qué los desencadenadores de canalización no se pudieron ejecutar, seleccione el elemento de menú Problemas de desencadenador en la página de definición de canalización. Los problemas del desencadenador no están disponibles para los recursos del repositorio.

En la página Problemas del desencadenador , los mensajes de error y advertencias describen por qué se produjo un error en el desencadenador.

Contenido relacionado

• Acerca de los recursos de Azure Pipelines
• Definición de variables
• Adición y uso de grupos de variables
• Creación y establecimiento como destino de un entorno
• Uso del editor de canalizaciones YAML
• Referencia de esquema de YAML