Recursos en canalizaciones YAML

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

En este artículo se describen los recursos de las canalizaciones YAML. Un recurso es cualquier elemento que utiliza una canalización que está fuera de la canalización. Después de definir un recurso, puede consumirlo en cualquier lugar de la canalización.

Los recursos proporcionan la rastreabilidad completa de los servicios que usa la canalización, incluyendo la versión, los artefactos, las confirmaciones asociadas y los elementos de trabajo. Puede automatizar completamente los flujos de trabajo de DevOps mediante la suscripción a los eventos desencadenadores en los recursos.

Esquema de recursos

Los recursos de YAML representan orígenes de canalizaciones, compilaciones, repositorios, contenedores, paquetes y webhooks. Para obtener información completa sobre el esquema, consulte la definición de recursos en Referencia de esquema YAML para Azure Pipelines.

Cuando un recurso desencadena una canalización, se establecen las siguientes variables:

resources.triggeringAlias
resources.triggeringCategory

La variable Build.Reason debe ser ResourceTrigger para que estos valores se establezcan. Los valores están vacíos si el recurso no desencadena la ejecución de canalización.

Definición de recursos de canalizaciones

Si tiene una canalización que genera artefactos, puede consumir los artefactos definiendo un recurso pipelines. Solo Azure Pipelines puede usar el recurso pipelines. Puede establecer desencadenadores para los flujos de trabajo de implementación continua (CD) en un recurso de canalización.

En la definición del recurso, pipeline es un valor único que puede usar para hacer referencia al recurso de canalización más adelante en la canalización. source es el nombre de la canalización que generó el artefacto de canalización. Para obtener información completa sobre el esquema, consulte la definición resources.pipelines.pipeline.

Use la etiqueta definida por pipeline para hacer referencia al recurso de canalización desde otras partes de la canalización, por ejemplo, al usar variables de recursos de canalización o descargar artefactos. Para obtener una manera alternativa de descargar artefactos de canalización, consulte Descarga de artefactos.

Definiciones de recursos de canalización de ejemplo

En el ejemplo siguiente se consumen artefactos de una canalización en el mismo proyecto.

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

Para consumir una canalización de otro proyecto, incluya el nombre del proyecto y el nombre de origen. En el ejemplo siguiente se usa branch para resolver la versión predeterminada cuando la canalización se desencadena de forma manual o programada. La entrada de rama no puede tener caracteres comodín.

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

En el ejemplo siguiente se muestra un recurso de canalización con un desencadenador simple.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    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: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

En el ejemplo siguiente se usan filtros stages para evaluar las condiciones de desencadenador para las canalizaciones de CD. En las fases se usa el operador AND. Al completar correctamente todas las fases proporcionadas, la canalización de CD se desencadena.

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

En el ejemplo siguiente se utilizan filtros tags para la evaluación de la versión predeterminada y para los desencadenadores. En las etiquetas se usa el operador AND.

Las tags se establecen en la canalización de integración continua (CI) o CD. Estas etiquetas son diferentes de las etiquetas establecidas en las ramas del repositorio de Git.

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

Evaluación de la versión del artefacto de canalizaciones

La versión de los artefactos de la canalización de recursos depende de cómo se desencadene la canalización.

Desencadenamiento manual o programado

Si la ejecución de la canalización se desencadena de forma manual o programada, los valores de las propiedades version, branch y tags definen la versión del artefacto. La entrada branch no puede tener caracteres comodín. Las propiedades tags usan el operador AND.

La siguiente definición de recursos pipeline usa las propiedades branch y tags para evaluar la versión predeterminada cuando la canalización se desencadena de forma manual o programada. Al desencadenar manualmente la canalización para que se ejecute, la versión de los artefactos de la canalización MyCIAlias es la de la compilación más reciente realizada en la rama main y que tiene las etiquetas Production y PrepProduction.

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

Desencadenador de finalización de canalización de recursos

Cuando una canalización se desencadena porque se completa una de sus canalizaciones de recursos, la versión de los artefactos es la de la canalización desencadenante. Los valores de las propiedades version, branch y tags se omiten.

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

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

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

Descarga del artefacto de canalización

El paso download descarga artefactos asociados a la ejecución actual o a otro recurso de canalización.

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

Los artefactos de trabajo normales no se descargan automáticamente. Use download explícitamente cuando sea necesario.

Los artefactos del recurso pipeline se descargan en la carpeta $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Para obtener más información, consulte Publicación y descarga de artefactos de canalización.

La propiedad opcional artifact especifica nombres de artefacto. Si no se especifica, se descargan todos los artefactos disponibles. La propiedad opcional patterns define patrones que representan los archivos que se van a incluir. 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'

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)

Definición de recursos de compilación

Si tiene un sistema de compilación de integración continua externo que genera artefactos, puede consumir artefactos con recursos builds. Un recurso build puede proceder de cualquier sistema de integración continua externo, como Jenkins, TeamCity o CircleCI.

La categoría builds es extensible. Puede escribir una extensión para consumir artefactos del servicio de compilación e introducir un nuevo tipo de servicio como parte de builds.

En la definición build, version se establece por defecto con el valor de la compilación correcta más reciente. trigger no está habilitado de forma predeterminada y debe establecerse explícitamente. Para obtener información completa sobre el esquema, consulte la definición resources.builds.build.

En el ejemplo siguiente, Jenkins es el type del recurso.

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

Tarea downloadBuild

Los artefactos de recursos build no se descargan automáticamente en jobs/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.

Esta tarea se resuelve automáticamente en la tarea de descarga correspondiente para el tipo de recurso build que define el tiempo de ejecución. Los artefactos del recurso build se descargan en la carpeta $(PIPELINE.WORKSPACE)/<build-identifier>/.

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, se descargan todos los artefactos asociados al recurso.

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. Por ejemplo, el fragmento de código siguiente solo descarga 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.

Definición de recursos del repositorio

La palabra clave repository le permite especificar un repositorio externo. Puede usar este recurso si la canalización tiene plantillas en otro repositorio o si quiere usar la restauración de varios repositorios con un repositorio que requiera una conexión de servicio. Debe informar al sistema sobre estos repositorios.

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.repositories.repository.

Tipos de recursos de repositorio

Azure Pipelines admite los valores siguientes para el tipo de repositorio: git, github, githubenterprise y 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.

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. Use la palabra clave checkout para capturar un repositorio definido como parte del recurso repository. Para obtener información completa sobre el esquema, consulte la definición steps.checkout.

Para obtener más información, consulte Restauración de repositorios múltiples en la canalización.

Definición de recursos de contenedores

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

Puede consumir un recurso de contenedor genérico como una imagen como parte del trabajo o puede usar el recurso para trabajos de contenedor. Si la canalización requiere el respaldo de uno o varios servicios, necesitará crear contenedores de servicio y conectarse a ellos. Puede usar volúmenes para compartir datos entre servicios.

Si necesita consumir imágenes de un registro de Docker como parte de la canalización, puede definir un recurso de contenedor genérico. No se requiere ninguna palabra clave type. 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 como parte de los trabajos y para habilitar desencadenadores de canalización automáticos.

Para que Azure Container Registry use desencadenadores de canalización automáticos, debe tener permisos de colaborador o de propietario. 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 variable location solo se aplica al tipo de recursos de 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

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

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

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}}

Selector manual de versiones para recursos

Al desencadenar manualmente una canalización YAML de CD, Azure Pipelines evalúa automáticamente las versiones predeterminadas de los recursos definidos en la canalización, en función de las entradas proporcionadas. Sin embargo, Azure Pipelines solo considera que se han completado correctamente las ejecuciones de CI cuando se evalúa la versión predeterminada de los desencadenadores programados o si no elige manualmente una versión.

Puede usar el selector de versiones de recursos para elegir manualmente una versión diferente al crear una ejecución. El selector de versiones de recursos se admite para los recursos de canalización, compilación, repositorio, contenedor y paquete.

En el caso de los recursos de canalización, puede ver todas las ejecuciones disponibles en todas las ramas, buscarlas en función del número de canalización o rama, y elegir una ejecución correcta, con errores o en curso. Esta flexibilidad garantiza que puede ejecutar la canalización de CD si está seguro de que una ejecución generó todos los artefactos que necesita. No es necesario esperar a que la ejecución de CI se complete o vuelva a ejecutarse debido a un error de fase no relacionado.

Para usar el selector de versiones de recursos, en el panel Ejecutar canalización, seleccione Recursos y, a continuació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 las versiones disponibles, como los paquetes de GitHub, el selector de versiones proporciona un campo de texto en el que puede introducir la versión de la ejecución que se va a seleccionar.

Autorización de recursos en canalizaciones YAML

Los recursos deben estar autorizados para poder 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 experiencia de administración de recursos para autorizar a todas las canalizaciones a acceder al recurso. Por ejemplo, los grupos de variables y los archivos seguros se administran en la página Biblioteca, en Canalizaciones, y los grupos de agentes y las conexiones de servicio se administran en Configuración del proyecto. Esta autorización resulta cómoda si no tiene que restringir el acceso a recursos; por ejemplo, para probar los recursos.

• Cuando se crea una canalización, todos los recursos a los que se hace referencia en el archivo YAML se autorizan automáticamente para su uso por la canalización, si tiene el rol de Usuario en esos recursos.

• Si agrega un recurso a un archivo YAML y 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., verá una opción para autorizar los recursos en la compilación con errores.

  Si es miembro del rol Usuario del recurso, puede seleccionar esta opción y autorizar el recurso en la compilación con errores. Una vez autorizado el recurso, puede iniciar una nueva compilación.

• Compruebe que los roles de seguridad del grupo de agentes del proyecto sean correctos.

Comprobaciones de aprobación de recursos

Puede usar las comprobaciones de aprobación y plantillas para controlar manualmente cuándo se ejecuta un recurso. Con la comprobación de aprobación de plantillas necesaria, puede exigir que cualquier canalización que use un recurso o entorno se extienda desde una plantilla YAML específica.

Establecer una aprobación de plantilla necesaria garantiza que el recurso solo se use en condiciones específicas y mejora la seguridad. Para más información sobre cómo mejorar la seguridad de canalización con plantillas, consulte Uso de plantillas para la seguridad.

Rastreabilidad

Azure Pipelines proporciona rastreabilidad completa para cualquier recurso consumido a nivel de canalización o de trabajo de implementación.

Rastreabilidad de canalización

Azure Pipelines muestra la siguiente información para cada ejecución de canalización:

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

Rastreabilidad del entorno

Cada vez que una canalización se implementa en un entorno, puede ver una lista de recursos que se consumen. En la vista se incluyen los recursos consumidos como parte de los trabajos de implementación y sus confirmaciones y elementos de trabajo asociados.

Información de canalizaciones de CD asociadas en canalizaciones de CI

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

Problemas del 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, hay algún error de sintaxis en el desencadenador o este no se ha configurado.
• 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. La opción Problemas del desencadenador solo está disponible para los recursos que no son de repositorio.

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

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 contenedores no está disponible para Docker Hub en canalizaciones YAML, por lo que deberá 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.

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