Recursos en canalizaciones de 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 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 oself
, 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 version
propiedades , branch
y 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 lamain
rama - Se etiqueta con y
Verified
Signed
- Completa las
Production
fases yPreProduction
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 download
none
en 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
, 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 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)"
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
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 acr
de 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 azureSubscription
valores , resourceGroup
y 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 true
en .
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
.
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.
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.
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.
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.
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>]
.
- La tarea docker tiene la
¿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 ahttps://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 ahttps://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
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta:Enviar y ver comentarios de