Recursos en canalizaciones de 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 todo lo que usa una canalización que existe fuera de la canalización. Después de definir un recurso, puede consumirlo en cualquier lugar de la canalización.

Los recursos proporcionan una rastreabilidad completa para los servicios que usa la canalización, incluida 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 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 la 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 un recurso no ha desencadenado la ejecución de la 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 pipelines recurso. Puede establecer desencadenadores para los flujos de trabajo de implementación continua (CD) en un recurso de canalización.

En la definición de recursos, 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 de otras partes de la canalización, como 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 pipeline recurso procede del mismo repositorio que la canalización actual o self, el desencadenador sigue la misma rama y confirmación en la que se genera el evento.
Si el recurso de canalización procede de un repositorio diferente, la canalización actual se desencadena en la rama predeterminada del pipeline repositorio de recursos.

Definiciones de recursos de canalización de ejemplo

En el ejemplo siguiente se consumen artefactos de una canalización dentro del 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 desde 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 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 trigger de canalización con condiciones de rama.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    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. Las fases usan el AND operador . 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 usan tags filtros para la evaluación de versión predeterminada y para desencadenadores. Las etiquetas usan el AND operador .

tags se establecen en la canalización de integración continua (CI) o CD. Estas etiquetas difieren 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 del artefacto de la canalización de recursos depende de cómo se desencadena la canalización.

Desencadenador manual o programado

Si la ejecución de la canalización se desencadena o programa manualmente, los valores de las versionpropiedades , branchy tags definen la versión del artefacto. La branch entrada no puede tener caracteres comodín. Las tags propiedades usan el AND operador .

Propiedades especificadas	Versión del artefacto
`version`	Artefactos de la compilación que tienen el número de ejecución especificado
`branch`	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`	Artefactos de la compilación más reciente realizada en la rama especificada que tiene todas las etiquetas especificadas
None	Los artefactos de la compilación más reciente en todas las ramas.

La siguiente pipeline definición de recursos usa las branch propiedades y tags para evaluar la versión predeterminada cuando la canalización se desencadena manual o programada. Al desencadenar manualmente la canalización para ejecutarse, la MyCIAlias versión de artefactos de canalización es la compilación más reciente realizada en la main rama que tiene las Production etiquetas 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 se desencadena una canalización debido a que se completa una de sus canalizaciones de recursos, la versión de artefactos es la versión de la canalización de desencadenamiento. Los valores de las propiedades version, branch y tags se omiten.

Desencadenadores especificados	Resultado
`branches`	Una nueva ejecución de canalización se desencadena cada vez que la canalización de recursos completa correctamente una ejecución en una de las `include` ramas.
`tags`	Una nueva ejecución de canalización se desencadena cada vez que la canalización de recursos completa correctamente una ejecución etiquetada con todas las etiquetas especificadas.
`stages`	Una nueva ejecución de canalización se desencadena cada vez que la canalización de recursos ejecuta correctamente el especificado `stages`.
`branches`, `tags` y `stages`	Una nueva ejecución de canalización desencadena cada vez que la ejecución de la canalización de recursos satisface todas las condiciones de rama, etiquetas y fases.
`trigger: true`	Una nueva ejecución de canalización se desencadena cada vez que la canalización de recursos completa correctamente una ejecución.
Nothing	No se desencadena ninguna nueva ejecución de canalización cuando la canalización de recursos completa correctamente una ejecución.

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

Se ejecuta en una de las releases ramas o en la main rama
Se etiqueta con y VerifiedSigned
Completa las Production fases 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 de artefactos de canalización

El download paso descarga artefactos asociados a la ejecución actual o a otro recurso de canalizació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 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 pipeline recurso se descargan en $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Para 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)

Crea la definición de recursos

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

La builds categoría 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 build definición, version el valor predeterminado es la compilación correcta más reciente. No trigger 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 recurso type.

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

Importante

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

Tarea downloadBuild

Los build artefactos de recursos no se descargan automáticamente en los trabajos o deploy-jobs. Para consumir artefactos del build recurso como parte de los trabajos, debe agregar explícitamente la downloadBuild tarea. 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 que define el tiempo de build ejecución. Los artefactos del build recurso se descargan en $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

En la downloadBuild definición, 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 quiere usar la desprotecció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.repository.repository.

Tipos de recursos de repositorio

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

Tipo	Valor de nombre	Ejemplo
`type: git`	Otro repositorio en el mismo proyecto o en la misma organización.	Mismo proyecto: `name: otherRepo` Otro proyecto de 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 metadatos siguientes para un recurso de repositorio están disponibles para todos los trabajos en forma de variables en tiempo de ejecución. <Alias> es el identificador que proporciona al recurso del repositorio.

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 checkout palabra clave para capturar un repositorio definido como parte del repository recurso. 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 containers recursos. Un container recurso 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 del trabajo o usar el recurso para los trabajos de contenedor. Si la canalización requiere la compatibilidad de uno o varios servicios, 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 como parte de la canalización, puede definir un recurso de contenedor genérico. No type se requiere ninguna 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.

Nota:

La enabled: 'true' sintaxis para habilitar desencadenadores de contenedor para todas las etiquetas de imagen es diferente de la sintaxis de 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 acrde recurso de contenedor de primera clase . Puede usar este tipo de recurso como parte de los trabajos y habilitar desencadenadores de canalización automática.

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

Para usar el acr tipo de recurso, debe especificar los azureSubscriptionvalores , resourceGroupy repository para el registro de contenedor de Azure. Por ejemplo:

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

Nota:

Las conexiones de servicio que usan la federación de identidades de carga de trabajo no se admiten en azureSubscription.

Variables de recursos de contenedor

Una vez definido un contenedor como un recurso, los metadatos de la imagen de contenedor 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 usados 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 acr tipo de recursos de contenedor.

En el ejemplo siguiente se tiene una conexión de servicio de Azure Resource Manager denominada 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 canalizaciones YAML. Para habilitar los desencadenadores de canalización automatizada cuando se libera una nueva versión del paquete, establezca la trigger propiedad trueen .

Al definir package recursos, especifique el repositorio>< o el nombre> del paquete <en la name propiedad y establezca el paquete type como NuGet o npm. Para usar paquetes de GitHub, use la autenticación basada en token de acceso personal (PAT) y cree una conexión de servicio de GitHub que use el 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 descargarlo, use getPackage.

En el ejemplo siguiente se tiene una conexión de servicio de GitHub denominada pat-contoso a un paquete de 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 canalización, contenedor, compilación y paquete. Sin embargo, no puede usar estos recursos para automatizar las implementaciones basadas en eventos o servicios externos.

El webhooks recurso 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 recursos de primera clase, como canalizaciones, compilaciones, contenedores o paquetes. Además, para los servicios locales en los que Azure DevOps no tiene visibilidad del 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 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 al evento de webhook. Puede consumir los datos de carga JSON en los trabajos como variables mediante 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:

Direcció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, creará 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 para comprobar la solicitud entrante. Si usó un secreto al crear el webhook, debe proporcionar el mismo secreto.
Encabezado HTTP: encabezado HTTP de 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 de servicio de webhook entrante.

Para desencadenar la canalización mediante un webhook, realice una POST solicitud 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 necesita autorización. La solicitud debe tener un cuerpo como el ejemplo siguiente:

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

Nota:

El acceso a datos desde el cuerpo de la solicitud del webhook puede dar lugar a UNML incorrecto. Por ejemplo, el paso - script: echo ${{ parameters.WebHook.resource.message }} de 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 se convirtió en no 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 de versiones manual 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 considera que solo se han completado correctamente las ejecuciones de CI al evaluar la versión predeterminada para 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 es compatible con 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 produjo todos los artefactos que necesita. No es necesario esperar a que se complete una ejecución de CI ni volver a ejecutarla 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 versiones disponibles, como los paquetes de GitHub, el selector de versiones proporciona un campo de texto para que pueda escribir la versión de la ejecución que se va a seleccionar.

Autorización de recursos en canalizaciones de YAML

Los recursos deben estar autorizados para poder usarlos 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 de 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 la configuración del proyecto. Esta autorización es conveniente si no es necesario restringir el acceso a los recursos, como para los recursos de prueba.
Al crear una canalización, todos los recursos a los que se hace referencia en el archivo YAML se autorizan automáticamente para su uso por parte de la canalización si tiene el rol Usuario para 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 para el 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 las plantillas para controlar manualmente cuando se ejecuta un recurso. Con la comprobación de aprobación de plantilla necesaria, puede requerir 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 mejore 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 una rastreabilidad completa para cualquier recurso consumido en un nivel de trabajo de canalización o 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. La vista incluye recursos consumidos como parte de los trabajos de implementación y sus confirmaciones asociadas y elementos de trabajo.

Captura de pantalla que muestra las confirmaciones en un entorno.

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

Para proporcionar rastreabilidad 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 pipelines recurso. Si otras canalizaciones consumen 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 los artefactos de ella.

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 errores de sintaxis en el desencadenador o el desencadenador no está 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. Los problemas de desencadenador solo están disponibles para los recursos no repositorios.

En la página Problemas del desencadenador , los mensajes de error y advertencia 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 download acceso directo para descargar los artefactos en trabajos de compilación o para 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, es posible que tenga 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.

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 inserción de Docker que se produce en el repositorio seleccionado crea una versión.
Cree una fase y un trabajo nuevos. Agregue dos tareas, inicio de sesión de Docker y Bash.
- La tarea docker tiene la login acción e 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 podría estar en una rama que no sea la rama predeterminada. Para solucionar este problema:

Seleccione Editar en la página de canalización.
En el menú Más acciones , seleccione Desencadenadores.
Seleccione la pestaña YAML y, a continuación, 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 a través de

Recursos en canalizaciones de 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

Desencadenador manual o programado

Desencadenador de finalización de canalización de recursos

Descarga de artefactos de canalización

Variables de recursos de canalización

Crea la definición de recursos

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 de versiones manual para recursos

Autorización de recursos en canalizaciones de YAML

Comprobaciones de aprobación de recursos

Rastreabilidad

Rastreabilidad de canalización

Rastreabilidad del entorno

Información de canalizaciones de CD asociada 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

Comentarios

Recursos adicionales

Compartir a través de

Recursos en canalizaciones de 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

Desencadenador manual o programado

Desencadenador de finalización de canalización de recursos

Descarga de artefactos de canalización

Variables de recursos de canalización

Crea la definición de recursos

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 de versiones manual para recursos

Autorización de recursos en canalizaciones de YAML

Comprobaciones de aprobación de recursos

Rastreabilidad

Rastreabilidad de canalización

Rastreabilidad del entorno

Información de canalizaciones de CD asociada 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

Comentarios

Recursos adicionales