Recursos en canalizaciones YAML

Artículo
07/02/2024

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.

Importante

Al definir un desencadenador de recursos de canalización:

Si el recurso pipeline procede del mismo repositorio que la canalización actual, o self, el desencadenamiento sigue a la misma rama y confirmación en la que se genera el evento.
Si el recurso de canalización procede de otro repositorio, la canalización actual se desencadena en la rama predeterminada del repositorio de recursos pipeline.

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.

Propiedades especificadas	Versión del artefacto
`version`	Los artefactos de la compilación que tienen el número de ejecución especificado.
`branch`	Los artefactos de la compilación más reciente realizada en la rama especificada.
Lista de `tags`	Los artefactos de la compilación más reciente que tiene todas las etiquetas especificadas.
`branch` y lista de `tags`	Los artefactos de la última compilación realizada en la rama especificada que tiene todas las etiquetas especificadas
Ninguno	Los artefactos de la compilación más reciente en todas las ramas.

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.

Desencadenadores especificados	Resultado
`branches`	Cada vez que la canalización de recursos completa correctamente una ejecución en las ramas `include`, se desencadena una nueva ejecución de la canalización.
`tags`	Cada vez que la canalización de recursos completa correctamente una ejecución etiquetada con todas etiquetas especificadas, se desencadena una nueva ejecución de la canalización.
`stages`	Cada vez que la canalización de recursos ejecuta correctamente `stages`, se desencadena una nueva ejecución de la canalización.
`branches`, `tags` y `stages`	Cada vez que la ejecución de la canalización de recursos satisface todas las condiciones de rama, etiquetas y fases, se desencadena una nueva ejecución de la canalización.
`trigger: true`	Cada vez que la canalización de recursos completa correctamente una ejecución, se desencadena una nueva ejecución de la canalización.
Nada	Cada vez que la canalización de recursos completa correctamente una ejecución, no se desencadena una nueva ejecución de la canalización.

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'

Variables de recursos de canalización

En cada ejecución, los metadatos de un recurso de canalización están disponibles para todos los trabajos como variables predefinidas. Estas variables solo están disponibles para la canalización en tiempo de ejecución y, por tanto, no se pueden usar en expresiones de plantilla, que se evalúan en tiempo de compilación de canalización.

Para más información, consulte Metadatos de recursos de canalización como variables predefinidas. Para obtener más información sobre la sintaxis de variables, consulte Definición de variables.

En el ejemplo siguiente se devuelven los valores de variable predefinidos para el recurso de canalización myresourcevars.

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

Importante

Solo se admiten desencadenadores para Jenkins hospedado, donde Azure DevOps tiene línea de visión con el servidor Jenkins.

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.

Tipo	Valor del nombre	Ejemplo
`type: git`	Otro repositorio en el mismo proyecto o en la misma organización.	Mismo proyecto: `name: otherRepo` Otro proyecto en la misma organización: `name: otherProject/otherRepo`.
`type: github`	Nombre completo del repositorio de GitHub, incluido el usuario o la organización.	`name: Microsoft/vscode`
`type: githubenterprise`	Nombre completo del repositorio de GitHub Enterprise, incluido el usuario o la organización.	`name: Microsoft/vscode`
`type: bitbucket`	Nombre completo del repositorio de Bitbucket Cloud, incluido el usuario o la organización.	`name: MyBitbucket/vscode`

Variables de recursos del repositorio

En cada ejecución, los siguientes metadatos de un recurso de canalización están disponibles para todos los trabajos en forma de variables de tiempo de ejecución. <Alias> es el identificador que proporcionó para el repositorio de canalización.

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

En el ejemplo siguiente se tiene un recurso de repositorio con un alias de common, por lo que se accede a las variables de recursos del repositorio mediante resources.repositories.common.*.

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

En el ejemplo siguiente se tiene un recurso de repositorio con un alias de common, por lo que se accede a las variables de recursos del repositorio mediante resources.repositories.common.*.

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.

Nota:

La sintaxis enabled: 'true' que se usa para habilitar los desencadenadores de contenedor para todas las etiquetas de imagen es diferente de la que se usa con otros desencadenadores de recursos. Asegúrese de usar la sintaxis correcta para recursos específicos.

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*

Nota:

La evaluación del desencadenador solo se produce en la rama predeterminada. Asegúrese de establecer la rama predeterminada correcta o combinar el archivo YAML en la rama predeterminada actual. Para obtener más información sobre cómo cambiar la rama predeterminada de canalización, consulte La rama predeterminada de canalización.

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)

Definición de recursos de paquetes

Puede consumir paquetes de GitHub de NuGet y npm como recursos en las canalizaciones YAML. Para habilitar los desencadenadores de canalización automáticos cuando se publica una nueva versión del paquete, establezca la propiedad trigger en true.

Al definir recursos package, especifique el <Repositorio>/<Nombre> del paquete en la propiedad name y establezca el type de paquete como NuGet o npm. Para usar paquetes de GitHub, use la autenticación basada en tokens de acceso personal (PAT) y cree una conexión de servicio de GitHub que use PAT.

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

De forma predeterminada, los paquetes no se descargan automáticamente en los trabajos. Para descargarlos, use getPackage.

En el siguiente ejemplo hay una conexión de servicio de GitHub denominada pat-contoso a un paquete npm de GitHub denominado contoso. Para más información, consulte Paquetes de GitHub.

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

Definición de recursos de webhooks

Nota:

Los webhooks se publicaron en Azure DevOps Server 2020.1.

Puede consumir artefactos y habilitar desencadenadores automatizados con recursos de canalizaciones, contenedores, compilaciones y paquetes. Sin embargo, no puede usar estos recursos para automatizar las implementaciones en función de otros eventos o servicios externos.

El recurso webhooks de las canalizaciones YAML permite integrar las canalizaciones con servicios externos como GitHub, GitHub Enterprise, Nexus y Artifactory para automatizar flujos de trabajo. Puede suscribirse a cualquier evento externo a través de webhooks y usar los eventos para desencadenar las canalizaciones.

Los webhooks automatizan el flujo de trabajo en función de cualquier evento de webhook externo que no sea compatible con los recursos de primera clase, como canalizaciones, compilaciones, contenedores o paquetes. Además, en el caso de los servicios locales en los que Azure DevOps no tiene visibilidad sobre el proceso, puede configurar webhooks en el servicio y desencadenar automáticamente las canalizaciones.

Para suscribirse a un evento de webhook, defina un recurso de webhook en la canalización y haga que apunte a una conexión de servicio de webhook entrante. También puede definir más filtros en el recurso de webhook, en función de los datos de carga JSON, para personalizar los desencadenadores de cada canalización.

Cada vez que la conexión de servicio de webhook entrante recibe un evento de webhook, se desencadena una nueva ejecución para todas las canalizaciones suscritas a dicho evento. Puede consumir los datos de carga JSON de los trabajos como variables con el formato ${{ parameters.<WebhookAlias>.<JSONPath>}}.

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

En el ejemplo siguiente se define un recurso de webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Desencadenadores de webhook

Para configurar desencadenadores de webhook, primero debe configurar un webhook en el servicio externo, proporcionando la siguiente información:

URL de solicitud: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
Secreto (Opcional): si necesita proteger la carga JSON, proporcione un valor secreto.

A continuación, cree una nueva conexión de servicio de webhook entrante. Para este tipo de conexión de servicio, defina la siguiente información:

Nombre del webhook: igual que el webhook creado en el servicio externo.
Secreto (opcional): se usa para comprobar el hash HMAC-SHA1 de la carga que se usa para la comprobación de la solicitud entrante. Si usó un secreto al crear el webhook, debe proporcionar el mismo secreto.
Encabezado HTTP: el encabezado HMAC en la solicitud que contiene el valor hash HMAC-SHA1 de la carga para la comprobación de la solicitud. Por ejemplo, el encabezado de solicitud de GitHub es X-Hub-Signature.

Captura de pantalla que muestra la conexión entrante del servicio de webhook.

Para desencadenar la canalización mediante un webhook, debe realizar una solicitud POST a https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Este punto de conexión está disponible públicamente y no se necesita autorización. La solicitud debe tener un cuerpo parecido al siguiente ejemplo:

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

Nota:

El acceso a los datos desde el cuerpo de la solicitud del webhook puede provocar un YAML incorrecto. Por ejemplo, el paso - script: echo ${{ parameters.WebHook.resource.message }} de la canalización extrae todo el mensaje JSON, que genera YAML no válido. Cualquier canalización desencadenada a través de este webhook no se ejecuta, ya que el YAML generado no es válido.

En el fragmento de código siguiente se muestra otro ejemplo que usa filtros de webhook.

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.

Captura de pantalla que muestra el selector de la versión del recurso del repositorio.

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.

Captura de pantalla que muestras confirmaciones en un entorno

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.

Captura de pantalla que muestra la información de canalizaciones de CD en una canalización de CI.

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.

Captura de pantalla que muestra la compatibilidad de los problemas de 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.

Cree una nueva conexión de servicio de Docker Hub.
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.
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.
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?

Cree una conexión de servicio.

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

Ejecutar la canalización. El webhook se crea en Azure como una tarea distribuida para su organización.
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:

Seleccione Editar en la página de la canalización.
En el menú Más acciones, seleccione Desencadenadores.
Seleccione la pestaña YAML y luego seleccione Obtener orígenes.
En Rama predeterminada para compilaciones manuales y programadas, actualice la rama de características.
Seleccione Guardar y poner en cola.
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.

Compartir vía

Recursos en canalizaciones YAML

Esquema de recursos

Definición de recursos de canalizaciones

Definiciones de recursos de canalización de ejemplo

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

Desencadenamiento manual o programado

Desencadenador de finalización de canalización de recursos

Descarga del artefacto de canalización

Variables de recursos de canalización

Definición de recursos de compilación

Tarea downloadBuild

Definición de recursos del repositorio

Tipos de recursos de repositorio

Variables de recursos del repositorio

Palabra clave Checkout para repositorios

Definición de recursos de contenedores

Tipo de recurso de Azure Container Registry

Variables de recursos de contenedor

Definición de recursos de paquetes

Definición de recursos de webhooks

Desencadenadores de webhook

Selector manual de versiones para recursos

Autorización de recursos en canalizaciones YAML

Comprobaciones de aprobación de recursos

Rastreabilidad

Rastreabilidad de canalización

Rastreabilidad del entorno

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

Problemas del desencadenador de recursos

Preguntas más frecuentes

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

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

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

Comentarios

Recursos adicionales

Compartir vía

Recursos en canalizaciones YAML

Esquema de recursos

Definición de recursos de canalizaciones

Definiciones de recursos de canalización de ejemplo

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

Desencadenamiento manual o programado

Desencadenador de finalización de canalización de recursos

Descarga del artefacto de canalización

Variables de recursos de canalización

Definición de recursos de compilación

Tarea downloadBuild

Definición de recursos del repositorio

Tipos de recursos de repositorio

Variables de recursos del repositorio

Palabra clave Checkout para repositorios

Definición de recursos de contenedores

Tipo de recurso de Azure Container Registry

Variables de recursos de contenedor

Definición de recursos de paquetes

Definición de recursos de webhooks

Desencadenadores de webhook

Selector manual de versiones para recursos

Autorización de recursos en canalizaciones YAML

Comprobaciones de aprobación de recursos

Rastreabilidad

Rastreabilidad de canalización

Rastreabilidad del entorno

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

Problemas del desencadenador de recursos

Preguntas más frecuentes

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

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

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

Contenido relacionado

Comentarios

Recursos adicionales