Definición de recursos en YAML
Azure Pipelines
Los recursos de YAML representan orígenes de canalizaciones, compilaciones, repositorios, contenedores, paquetes y webhooks. Los recursos también proporcionan la rastreabilidad completa de los servicios usados en la canalización, incluidos la versión, los artefactos, las confirmaciones asociadas y los elementos de trabajo. Al definir un recurso, se puede consumir en cualquier lugar de la canalización. Además, puede automatizar completamente el flujo de DevOps de trabajo mediante la suscripción para desencadenar eventos en los recursos.
Para más información, consulte Acerca de los recursos.
Schema
resources:
pipelines: [ pipeline ]
builds: [ build ]
repositories: [ repository ]
containers: [ container ]
packages: [ package ]
webhooks: [ webhook ]
Variables
Cuando un recurso desencadena una canalización, se establecen las siguientes variables:
resources.triggeringAlias
resources.triggeringCategory
Estos valores están vacíos si un recurso no desencadena una ejecución de canalización. La variable Build.Reason debe ser para que estos valores se ResourceTrigger establezcan.
Definición de un pipelines recurso
Si tiene una canalización que genera artefactos, puede consumir los artefactos definiendo un pipelines recurso. pipelineses un recurso dedicado solo para Azure Pipelines. También puede establecer desencadenadores en un recurso de canalización para los flujos de trabajo de CD.
En la definición de recursos, es un valor único que puede usar para hacer pipeline referencia al recurso de canalización más adelante. source es el nombre de la canalización que genera un artefacto.
Para obtener una manera alternativa de descargar canalizaciones, consulte las tareas de Pipeline Artifacts.
resources: # types: pipelines | builds | repositories | containers | packages
pipelines:
- pipeline: string # identifier for the resource used in pipeline resource variables
project: string # project for the source; optional for current project
source: string # name of the pipeline that produces an artifact
version: string # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
branch: string # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
trigger: # triggers aren't enabled by default unless you add trigger section to the resource
branches: # branch conditions to filter the events, optional; Defaults to all branches.
include: [ string ] # branches to consider the trigger events, optional; Defaults to all branches.
exclude: [ string ] # branches to discard the trigger events, optional; Defaults to none.
tags: [ string ] # list of tags to evaluate for trigger event, optional
stages: [ string ] # list of stages to evaluate for trigger event, optional
Importante
Al definir un desencadenador de recursos, si su recurso de canalización es del mismo repositorio (por ejemplo, uno mismo) que la canalización actual, el desencadenador sigue la misma rama y confirma en la que se genera el evento. Sin embargo, si el recurso de canalización es de un repositorio diferente, la canalización actual se desencadena en la rama predeterminada del repositorio propio.
Evaluación de la versión del artefacto
La versión de canalización, la ejecución de compilación de CI, que se elige en la ejecución de la canalización, se controla mediante la forma en que se desencadena la ejecución de la canalización.
En caso de que cree que la ejecución de la canalización se crea manualmente o mediante un desencadenador programado, la versión predeterminada, la rama y las etiquetas se usan para evaluar la versión de la canalización de CI.
| Información proporcionada | Resultado |
|---|---|
| Versión de compilación # | Esa versión se ejecuta. |
| Rama | Se ejecuta la versión más reciente de la rama dada. |
| Lista de etiquetas | La ejecución más reciente que tiene todas las etiquetas correspondientes se ejecuta. |
| Rama y lista de etiquetas | La última ejecución de la rama proporcionada y que tiene las etiquetas correspondientes se ejecuta. |
| Nada | Se ejecuta la versión más reciente en todas las ramas. |
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
tags: ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
- Production ### Tags are AND'ed
- PreProduction
Si la canalización se desencadena automáticamente, se selecciona la versión de la canalización de CI, en función del evento de desencadenador. La información de versión predeterminada proporcionada es irrelevante.
| Información proporcionada | Resultado |
|---|---|
| Ramas | Se desencadena una nueva canalización cada vez que se completa correctamente una ejecución de CI que coincide con las ramas incluidas. |
| Etiquetas | Se desencadena una nueva canalización cada vez que se completa correctamente una ejecución de CI que coincide con todas las etiquetas mencionadas. |
| Fases | Una nueva canalización se desencadena siempre que una ejecución de CI tiene todas las fases mencionadas se completan correctamente. |
| Ramas, etiquetas y fases | Una nueva ejecución de canalización se desencadena cada vez que una ejecución de CI coincide con todas las condiciones. |
Solamente trigger: true |
Una nueva ejecución de canalización se desencadena cada vez que se completa correctamente una ejecución de CI. |
| Nada | No se desencadena ninguna ejecución de canalización. Los desencadenadores están deshabilitados de forma predeterminada a menos que los habilite específicamente. |
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
include:
- releases/*
- main
exclude:
- topic/*
tags:
- Verified
- Signed
stages:
- Production
- PreProduction
download para canalizaciones
Todos los artefactos de la canalización actual y de todos los recursos se descargan automáticamente y están disponibles pipeline al principio de cada deployment trabajo. Puede invalidar este comportamiento. Para obtener más información, vea Pipeline Artifacts. Los artefactos normales de "trabajo" no se descargan automáticamente. Use download explícitamente cuando sea necesario.
steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
patterns: string # patterns representing files to include; optional
Artifacts del recurso pipeline se descargan en la $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> carpeta .
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 en forma de variables predefinidas. es <Alias> el identificador que agregó para el recurso de canalización. Las variables de recursos de canalización solo están disponibles en tiempo de ejecución.
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Definición de un builds recurso
Si tiene un sistema de compilación de CI externo que genera artefactos, puede consumir artefactos con un builds recurso. Un builds recurso puede ser cualquier sistema de CI externo como Jenkins, TeamCity, CircleCI, entre otros.
resources: # types: pipelines | builds | repositories | containers | packages
builds:
- build: string # identifier for the build resource
type: string # the type of your build service like Jenkins, circleCI etc.
connection: string # service connection for your build service.
source: string # source definition of the build
version: string # the build number to pick the artifact, defaults to Latest successful build
trigger: boolean # Triggers aren't enabled by default and should be explicitly set
builds es una categoría extensible. Puede escribir una extensión para consumir artefactos del servicio de compilaciones e introducir un nuevo tipo de servicio como parte de builds . Jenkins es un tipo de recurso en builds .
Importante
Los desencadenadores solo se admiten para Jenkins hospedado Azure DevOps línea de visión con el servidor Jenkins.
downloadBuild tarea para compilaciones
Puede consumir artefactos del recurso build como parte de los trabajos mediante la tarea downloadBuild . En función del tipo de recurso definido, esta tarea se resuelve automáticamente en la tarea de descarga correspondiente para el servicio build durante el tiempo de ejecución.
Artifacts del recurso build se descargan en la $(PIPELINE.WORKSPACE)/<build-identifier>/ carpeta .
Importante
build Los artefactos de recursos no se descargan automáticamente en los trabajos o deploy-jobs. Debe agregar explícitamente la downloadBuild tarea para consumir los artefactos.
- downloadBuild: string # identifier for the resource from which to download artifacts
artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded
Definición de un repositories recurso
Si la canalización tiene plantillas en otro repositorio osi desea usar la desprotección de varios repositorios con un repositorio que requiere una conexión de servicio, debe hacer que el sistema sepa sobre ese repositorio.
La repository palabra clave le permite especificar un repositorio externo.
resources:
repositories:
- repository: string # identifier (A-Z, a-z, 0-9, and underscore)
type: enum # see the following "Type" topic
name: string # repository name (format depends on `type`)
ref: string # ref name to use; defaults to 'refs/heads/main'
endpoint: string # name of the service connection to use (for types that aren't Azure Repos)
trigger: # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
branches:
include: [ string ] # branch names which trigger a build
exclude: [ string ] # branch names which won't
tags:
include: [ string ] # tag names which trigger a build
exclude: [ string ] # tag names which won't
paths:
include: [ string ] # file paths which must match to trigger a build
exclude: [ string ] # file paths which won't trigger a build
Tipo
Pipelines admite los siguientes valores para el tipo de repositorio: git , github , y githubenterprisebitbucket .
El git tipo hace referencia a Azure Repos repositorios de Git.
| Tipo especificado | Resultado | Ejemplo |
|---|---|---|
type: git |
El name valor hace referencia a otro repositorio del mismo proyecto. |
name: otherRepo Para hacer referencia a un repositorio de otro proyecto dentro de la misma organización, antefise el nombre con el nombre de ese proyecto. Un ejemplo es name: OtherProject/otherRepo. |
type: github |
El name valor es el nombre completo del repositorio GitHub e incluye el usuario u organización. |
name: Microsoft/vscode |
type: githubenterprise |
el name valor es el nombre completo del repositorio GitHub Enterprise e incluye el usuario u organización. |
name: Microsoft/vscode |
type: bitbucket |
El name valor es el nombre completo del repositorio de Bitbucket Cloud e incluye el usuario u organización. |
name: MyBitbucket/vscode |
GitHub Enterprise repositorios requieren una conexión GitHub Enterprise servicio de autenticación para la autorización.
Los repositorios en la nube de Bitbucket requieren una conexión de servicio en la nube de Bitbucket para la autorización.
Usar checkout para consumir el repositorio
Use checkout la palabra clave para consumir los repositorios definidos como parte del repository recurso.
Schema
steps:
- checkout: string # identifier for your repository resource
clean: boolean # if true, execute `execute git clean -ffdx && git reset --hard HEAD` before fetching
fetchDepth: number # the depth of commits to ask Git to fetch; defaults to no limit
lfs: boolean # whether to download Git-LFS files; defaults to false
submodules: true | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
persistCredentials: boolean # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false
Repos del recurso repository no se sincronizan automáticamente en los trabajos. Use checkout para capturar los repositorios como parte de los trabajos.
Para obtener más información, consulte Des check out multiple repositories in your pipeline (Des consultar varios repositorios en la canalización).
Definición de un containers recurso
Si necesita consumir una imagen de contenedor como parte de la canalización de integración continua/entrega continua (CI/CD), puede lograrlo mediante containers . Un recurso de contenedor puede ser un registro de Docker público o privado, o Azure Container Registry.
Si necesita consumir imágenes del registro de Docker como parte de la canalización, puede definir un recurso de contenedor genérico (no se type requiere palabra clave).
resources:
containers:
- container: string # identifier (A-Z, a-z, 0-9, and underscore)
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # reference to a service connection for the private registry
env: { string: string } # list of environment variables to add
ports: [ string ] # ports to expose on the container
volumes: [ string ] # volumes to mount on the container
mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
mountReadOnly: # volumes to mount read-only - all default to false
externals: boolean # components required to talk to the agent
tasks: boolean # tasks required by the job
tools: boolean # installable tools like Python and Ruby
work: boolean # the work directory
Puede usar un recurso de contenedor genérico como una imagen consumida como parte del trabajo, o también se puede usar para trabajos de contenedor. Si la canalización requiere la compatibilidad de uno o varios servicios, querrá crear y conectarse a contenedores de servicios. Puede usar volúmenes para compartir datos entre servicios.
Puede usar un tipo de recurso de contenedor de primera clase Azure Container Registry (ACR) para consumir las imágenes de ACR. Este tipo de recursos se puede usar como parte de los trabajos y también para habilitar desencadenadores de canalización automáticos.
resources: # types: pipelines | repositories | containers | builds | packages
containers:
- container: string # identifier for the container resource
type: string # type of the registry like ACR, GCR etc.
azureSubscription: string # Azure subscription (ARM service connection) for container registry;
resourceGroup: string # resource group for your ACR
registry: string # registry for container images
repository: string # name of the container image repository in ACR
trigger: # Triggers aren't enabled by default and need to be set explicitly
enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
tags:
include: [ string ] # image tags to consider the trigger events, optional; defaults to any new tag
exclude: [ string ] # image tags on discard the trigger events, optional; defaults to none
Nota
La sintaxis que se usa para habilitar desencadenadores de contenedor para todas las etiquetas de imagen ( ) es diferente de la sintaxis que se enabled: 'true' usa para otros desencadenadores de recursos. Preste mucha atención para usar la sintaxis correcta para un recurso específico.
Variables de recursos de contenedor
Una vez que se define un contenedor como un recurso, los metadatos de la imagen de contenedor se pasan a la canalización en forma de variables. Se puede acceder a información como la imagen, el registro y los detalles de conexión en todos los trabajos que se van a usar en las tareas de implementación del contenedor.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
La variable de ubicación solo es aplicable al ACR tipo de recursos de contenedor.
Definición de un packages recurso
Puede consumir paquetes NuGet y npm GitHub como un recurso en canalizaciones de YAML.
Al especificar recursos, establezca el paquete como package NuGet o npm. También puede habilitar desencadenadores de canalización automatizados cuando se libera una nueva versión del paquete.
Para usar GitHub, use la autenticación basada en token de acceso personal (PAT) y cree una conexión de servicio de GitHub que use LOS PAT.
De forma predeterminada, los paquetes no se descargan automáticamente en los trabajos. Para descargarlo, use getPackage .
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConnectionName # Github service connection with the PAT type
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.1 # Version of the packge to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers
Definición de un webhooks recurso
Con otros recursos (como canalizaciones, contenedores, compilación y paquetes), puede consumir artefactos y habilitar desencadenadores automatizados. Sin embargo, no puede automatizar el proceso de implementación en función de otros eventos o servicios externos. El webhooks recurso le permite integrar la canalización con cualquier servicio externo y automatizar el flujo de trabajo. Puede suscribirse a cualquier evento externo a través de sus webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, entre otros) y desencadenar las canalizaciones.
Siga estos pasos para configurar los desencadenadores de webhook.
Configure un webhook en el servicio externo. Al crear el webhook, debe proporcionar la siguiente información:
- Dirección URL de solicitud:
https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview - Secreto: opcional. Si necesita proteger la carga de JSON, proporcione el valor secreto.
- Dirección URL de solicitud:
Cree una nueva conexión de servicio "Webhook entrante". Esta conexión es un tipo de conexión de servicio recién introducido que permite definir la siguiente información importante:
- Nombre del webhook:el nombre del webhook debe coincidir con el webhook creado en el servicio externo.
- Encabezado HTTP: el nombre del encabezado HTTP de la solicitud que contiene el valor hash HMAC-SHA1 de la carga para la comprobación de la solicitud. Por ejemplo, para GitHub, el encabezado de solicitud es"X-Hub-Signature".
- Secreto: el secreto se usa para comprobar el hash HMAC-SHA1 de la carga que se usa para la comprobación de la solicitud entrante (opcional). Si usó un secreto al crear el webhook, debe proporcionar la misma clave secreta.
En las canalizaciones de YAML se introduce un nuevo tipo
webhooksde recurso denominado . Para suscribirse a un evento de webhook, defina un recurso de webhook en la canalización y apunte a la conexión del servicio de webhook entrante. También puede definir más filtros en el recurso de webhook, en función de los datos de carga de JSON, para personalizar los desencadenadores de cada canalización. Consumir los datos de carga en forma de variables en los trabajos.Cada vez que la conexión del 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 con el formato
${{ parameters.<WebhookAlias>.<JSONPath>}}
resources:
webhooks:
- webhook: MyWebhookTriggerAlias ### Webhook alias
connection: IncomingWebhookConnection ### Incoming webhook service connection
filters: ### List of JSON parameters to filter; Parameters are AND'ed
- path: JSONParameterPath ### JSON path in the payload
value: JSONParameterExpectedValue ### Expected value in the path provided
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. Recursos como canalizaciones, compilaciones, contenedores y paquetes. Además, para los servicios locales en los que Azure DevOps no tiene visibilidad sobre el proceso, puede configurar webhooks en el servicio y desencadenar las canalizaciones automáticamente.
Selector de versión manual para recursos en el cuadro de diálogo crear ejecución
Cuando se desencadena manualmente una canalización de YAML de CD, se evalúa automáticamente la versión predeterminada de los recursos definidos en la canalización, en función de las entradas proporcionadas. Sin embargo, puede elegir una versión diferente del selector de versión del recurso al crear una ejecución.
En el panel Crear ejecución, seleccione Recursos. Verá una lista de los recursos consumidos en esta canalización.
Seleccione un recurso y elija una versión específica de la lista de versiones disponibles. El selector de versión de recursos es compatible con los recursos de canalización, compilación, repositorio, contenedor y paquete.
Para los recursos de canalización, puede ver todas las ejecuciones disponibles en todas las ramas. Buscarlos en función del número de canalización o la rama. Y, elija 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 ha generado todos los artefactos que necesita. No es necesario esperar a que la ejecución de CI se complete o se vuelva a ejecutar debido a un error de fase no relacionado en la ejecución de CI. Sin embargo, solo se tienen en cuenta las ejecuciones de CI completadas correctamente cuando se evalúa la versión predeterminada para los desencadenadores programados o si no se usa el selector de versiones manual.
En el caso de los recursos en los que no se pueden capturar las versiones disponibles, como los paquetes de GitHub, se muestra un cuadro de texto como parte del selector de versiones para que pueda proporcionar la versión para que la ejecución la seleccione.
Autorización de una canalización de YAML
Los recursos deben estar autorizados para poder usarse. Un propietario del recurso controla los usuarios y canalizaciones que pueden acceder a ese recurso. La canalización debe estar autorizada para usar el recurso. Consulte las siguientes formas de autorizar una canalización de YAML.
Vaya a la experiencia de administración del recurso. Por ejemplo, los grupos de variables y los archivos seguros se administran en la página Biblioteca en Pipelines. Los grupos de agentes y las conexiones de servicio se administran Project configuración . Aquí puede autorizar a todas las canalizaciones a acceder a ese recurso. Esta autorización es conveniente si no tiene necesidad de restringir el acceso a un recurso, por ejemplo, los recursos de prueba.
Cuando se crea una canalización por primera vez, 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 es miembro del rol Usuario para ese recurso. Por lo tanto, los recursos a los que se hace referencia en el archivo YAML al crear una canalización se autorizan automáticamente.
Al realizar cambios en el archivo YAML y agregar recursos, se produce un error similar al siguiente en la compilación:
Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.En este caso, 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. Una vez autorizados los recursos, puede iniciar una nueva compilación.
Compruebe que los roles de seguridad del grupo de agentes para el proyecto son correctos.
Establecer comprobaciones de aprobación para los recursos
Puede controlar manualmente cuándo se ejecuta un recurso con plantillas y comprobaciones de aprobación. Con la comprobación de aprobación deplantilla necesaria, puede requerir que cualquier canalización que use un recurso o entorno también se extienda desde una plantilla YAML específica. Establecer una aprobación de plantilla necesaria mejora la seguridad. Asegúrese de que el recurso solo se usa en condiciones específicas con una plantilla. Obtenga más información sobre cómo mejorar la seguridad de las canalizaciones con plantillas y recursos.
Rastreabilidad
Proporcionamos una rastreabilidad completa para cualquier recurso consumido en un nivel de trabajo de canalización o implementación.
Rastreabilidad de la canalización
Para cada ejecución de canalización, se muestra la siguiente información.
Recurso que ha desencadenado la canalización, si lo desencadena un recurso.
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 los recursos que se consumen. En la vista siguiente se incluyen los recursos consumidos como parte de los trabajos de implementación y sus confirmaciones y elementos de trabajo asociados.
Mostrar información de canalizaciones de CD asociadas 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 de entrega. Puede ver la lista de ejecuciones de canalizaciones DE YAML de CD en las que se consume una ejecución de canalización de CI a través del pipeline recurso. Si otras canalizaciones consumen la canalización de CI, verá una pestaña "Canalizaciones asociadas" en la vista de ejecución. Aquí puede encontrar todas las ejecuciones de canalización que consumen la canalización y los artefactos de ella.
Compatibilidad y rastreabilidad de problemas de desencadenamiento de recursos YAML
Puede resultar confuso cuando los desencadenadores de canalización no se ejecutan. Hemos agregado un nuevo elemento de menú en la página de definición de canalización denominado Trigger Issues(Desencadenar problemas), donde puede obtener información sobre por qué los desencadenadores no se ejecutan. Para acceder a esta página, abra el historial de canalizaciones. Los problemas de desencadenador solo están disponibles para recursos que no son de repositorio.
Los desencadenadores de recursos pueden no ejecutarse por los siguientes motivos.
Si el origen de la conexión de servicio proporcionada no es válido o si hay errores de sintaxis en el desencadenador, el desencadenador no está configurado, lo que produce un error.
Si no se cumplen las condiciones del desencadenador, el desencadenador no se ejecutará. Aparece una advertencia para que pueda entender por qué no se coincidieron las condiciones.
Pasos siguientes
Preguntas más frecuentes
¿Por qué debo usar canalizaciones resources en lugar del acceso download directo?
El uso pipelines de un recurso es una manera de consumir artefactos de una canalización de CI y también configurar desencadenadores automatizados. Un recurso proporciona visibilidad completa del 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 optar por descargar los artefactos en los trabajos de compilación o invalidar el comportamiento de descarga en los trabajos de implementación con download . La download tarea usa internamente la tarea Descargar canalización download.
¿Por qué debo usar resources en lugar de la tarea Descargar Artifacts canalización?
Cuando se usa la tarea Descargar Artifacts canalización directamente, se pierde la rastreabilidad y los desencadenadores. A veces tiene sentido usar la tarea Descargar canalización Artifacts tarea directamente. Por ejemplo, podría tener una tarea de script almacenada en una plantilla diferente y la tarea de script requiere que se descarguen los artefactos de una compilación. O bien, es posible que no sepa si alguien que usa una plantilla quiere agregar un recurso de canalización. Para evitar dependencias, puede usar la tarea Descargar canalización Artifacts para pasar toda la información de compilación a una tarea.