Definición de recursos en YAML

  • Artículo

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

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, incluyendo 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 trabajo de DevOps mediante la suscripción a eventos desencadenadores en los recursos.

Para obtener más información, vea Acerca de los recursos y Definición de esquema YAML de 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 el recurso no desencadena una ejecución de canalización. La variable Build.Reason debe ser ResourceTrigger para que estos valores se establezcan.

Definición de un recurso pipelines

Si tiene una canalización que genera artefactos, puede consumir los artefactos definiendo un recurso pipelines. pipelines es un recurso dedicado solo para Azure Pipelines. También puede establecer desencadenadores en un recurso de canalización para los flujos de trabajo de implementación continua.

En la definición del recurso, pipeline es un valor único que puede usar para hacer referencia al recurso de canalización más adelante. source es el nombre de la canalización que genera un artefacto. Use la etiqueta definida por pipeline para hacer referencia al recurso de canalización desde otras partes de la canalización, por ejemplo, al usar variables de recursos de canalización o descargar artefactos.

Para ver una manera alternativa de descargar canalizaciones, consulte las tareas de Artefactos de canalización.

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. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    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 procede del mismo repositorio (por ejemplo, self) que la canalización actual, el desencadenamiento sigue la misma rama y confirmación en las que se genera el evento. Sin embargo, si el recurso de canalización procede de otro repositorio, la canalización actual se desencadena en la rama predeterminada del repositorio self.

Evaluación de la versión del artefacto

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

Si la canalización se ejecuta porque la desencadenó manualmente o debido a una ejecución programada, la versión de los artefactos se define mediante los valores de las propiedades version, branch y tags.

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

Veamos un ejemplo. Supongamos que la canalización contiene la siguiente definición de recurso.

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

Al desencadenar manualmente la canalización para que se ejecute, la versión de los artefactos de la canalización MyCIAlias es la de la compilación más reciente realizada en la rama main y que tiene las etiquetas Production y PrepProduction.

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

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

Veamos un ejemplo. Supongamos que la canalización contiene la siguiente definición de recurso.

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

La canalización se ejecutará siempre que las ejecuciones de canalización SmartHotel-CI en una de las ramas releases o en la rama main se etiqueten con Verified y Signed, y se completen las fases Production y PreProduction.

download para canalizaciones

Todos los artefactos de la canalización actual y de todos los recursos pipeline se descargan automáticamente y están disponibles al principio de cada trabajo deployment. Puede invalidar este comportamiento. Para más información, consulte Artefactos de canalización. Los artefactos de "trabajo" normales 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

Los artefactos del recurso pipeline se descargan en la carpeta $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>.

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. <Alias> es el identificador que proporcionó para el recurso de canalización. Las variables de recursos de canalización solo están disponibles en tiempo de ejecución.

Para obtener más información sobre la sintaxis de variables, consulte Definición de variables.

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

Para más información, consulte Metadatos de recursos de canalización como variables predefinidas.

Definición de un recurso builds

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

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

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

Tarea downloadBuild para compilaciones

Puede consumir artefactos del recurso build como parte de los trabajos que usan la tarea downloadBuild. En función del tipo de recurso build definido, esta tarea se resuelve automáticamente en la tarea de descarga correspondiente para el servicio durante el tiempo de ejecución.

Los artefactos del recurso build se descargan en la carpeta $(PIPELINE.WORKSPACE)/<build-identifier>/.

Importante

Los artefactos de recursos build no se descargan automáticamente en los trabajos o trabajos de implementación. Debe agregar explícitamente la tarea downloadBuild 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 recurso repositories

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

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

Tipo

Las canalizaciones admiten los valores siguientes para el tipo de repositorio: git, github, githubenterprise y bitbucket. El tipo git hace referencia a los repositorios de Git de Azure Repos.

Tipo especificado Resultado Ejemplo
type: git El valor name 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, anteponga al nombre el nombre de ese proyecto. Un ejemplo es name: OtherProject/otherRepo.
type: github El valor name es el nombre completo del repositorio de GitHub e incluye el usuario u organización. name: Microsoft/vscode
type: githubenterprise El valor name es el nombre completo del repositorio de GitHub Enterprise e incluye el usuario u organización. name: Microsoft/vscode
type: bitbucket El valor name es el nombre completo del repositorio de Bitbucket Cloud e incluye al usuario u organización. name: MyBitbucket/vscode

Los repositorios de GitHub Enterprise requieren una conexión de servicio de GitHub Enterprise para la autorización.

Los repositorios de Bitbucket Cloud requieren una conexión de servicio de Bitbucket Cloud para la autorización.

Variables

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

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

Variables

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

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

Uso de checkout para consumir el repositorio

Use la palabra clave checkout para consumir los repositorios definidos como parte del recurso repository.

Schema

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Los repositorios del recurso repository no se sincronizan automáticamente en los trabajos. Use checkout para capturar los repositorios como parte de los trabajos.

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

Definición de un recurso containers

Si necesita consumir una imagen de contenedor como parte de la canalización de integración continua o entrega continua (CI/CD), puede hacerlo con 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 requiere la palabra clave type).

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 los trabajos de contenedor. Si la canalización requiere el respaldo de uno o varios servicios, le interesará crear contenedores de servicio y conectarse a ellos. Puede usar volúmenes para compartir datos entre servicios.

Puede usar un tipo de recurso de contenedor de primera clase para 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. Para que ACR use desencadenadores de canalización automáticos, debe tener permisos de colaborador o de propietario. Para obtener más información, vea Roles y permisos de Azure Container Registry.

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 los desencadenadores de contenedor para todas las etiquetas de imagen (enabled: 'true') es diferente de la que se usa con otros desencadenadores de recursos. Preste mucha atención al uso de la sintaxis correcta para un recurso específico.

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

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.

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 tipo ACR de recursos de contenedor.

Definición de un recurso packages

Puede consumir paquetes de GitHub de NuGet y npm como recurso en las canalizaciones YAML.

Al especificar recursos package, establezca el paquete como NuGet o npm. También puede habilitar desencadenadores de canalización automatizados cuando se publique una nueva versión del paquete.

Para usar paquetes de GitHub, use la autenticación basada en tokens de acceso personal (PAT) y cree una conexión de servicio de GitHub que use PAT.

De forma predeterminada, los paquetes no se descargan automáticamente en los trabajos. Para ello, 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 package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Definición de un recurso webhooks

Nota:

Los webhooks se publicaron en Azure DevOps Server 2020.1.

Con otros recursos (como canalizaciones, contenedores, compilaciones 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 recurso webhooks le permite integrar la canalización con cualquier servicio externo y automatizar el flujo de trabajo. Puede suscribirse a cualquier evento externo mediante sus webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) y desencadenar las canalizaciones.

Siga estos pasos para configurar los desencadenadores de webhook.

  1. Configure un webhook en el servicio externo. Al crear el proyecto del flujo de trabajo, 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 JSON, proporcione el valor de Secreto.

  2. Cree una nueva conexión de servicio de "Webhook entrante". Esta conexión es un tipo de conexión de servicio recién introducido que le 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 en 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 de secreto.

    Conexión de servicio de webhook entrante

  3. En las canalizaciones YAML, se introduce un nuevo tipo de recurso denominado webhooks. Para suscribirse a un evento de webhook, defina un recurso de webhook en la canalización y haga que apunte a la 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. Consuma los datos de carga en forma de variables en los trabajos.

  4. Cada vez que la conexión de servicio de webhook entrante recibe un evento de webhook, se desencadena una nueva ejecución para todas las canalizaciones suscritas a dicho evento. Puede consumir los datos de carga JSON de los trabajos 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, como canalizaciones, compilaciones, contenedores y paquetes. Además, en el caso de los servicios locales en los que Azure DevOps no tiene visibilidad sobre el proceso, puede configurar webhooks en el servicio y desencadenar automáticamente las canalizaciones.

Selector manual de versiones de recursos en el cuadro de diálogo "Crear ejecución"

Al desencadenar manualmente una canalización YAML de implementación continua, 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 con el selector de versiones de recursos al crear una ejecución.

  1. En el panel Crear ejecución, seleccione Recursos. Verá una lista de los recursos consumidos en esta canalización.

  2. Seleccione un recurso y elija una versión específica de la lista de versiones disponibles. El selector de versiones de recursos se admite para los recursos de canalización, compilación, repositorio, contenedor y paquete.

    Selector de versiones de canalización

Para los recursos de canalización, puede ver todas las ejecuciones disponibles en todas las ramas. Búsquelos 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 implementación continua si está seguro de que generó todos los artefactos que necesita. No es necesario esperar a que la ejecución de la integración continua se complete o vuelva a ejecutarse debido a un error de fase no relacionado en dicha ejecución. Sin embargo, solo se considera que se han completado correctamente las ejecuciones de integración continua cuando se evalúa la versión predeterminada de los desencadenadores programados o si no se usa el selector manual de versiones.

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 de la ejecución que se va a seleccionar.

Autorización de una canalización YAML

Los recursos deben estar autorizados para poder usarse. Un propietario de recursos 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 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 Canalizaciones. Los grupos de agentes y las conexiones de servicio se administran en Configuración del proyecto. Aquí puede autorizar a todas las canalizaciones el acceso a ese recurso. Esta autorización es conveniente si no tiene que restringir el acceso a un recurso; por ejemplo, probar los recursos.

  • 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 se es miembro del rol Usuario en 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, la compilación produce un error similar al siguiente: 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 del proyecto sean correctos.

Establecimiento de comprobaciones de aprobación de recursos

Puede controlar manualmente cuándo se ejecuta un recurso con comprobaciones de aprobación y plantillas. Con la comprobación de aprobación de plantillas necesaria, puede exigir 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. Más información sobre cómo mejorar la seguridad de la canalización con plantillas y recursos.

Rastreabilidad

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

Rastreabilidad de canalización

Para cada ejecución de canalización, se muestra la siguiente información.

  • Recurso que ha desencadenado la canalización, si la desencadena un recurso.

    Desencadenador de recursos en una canalización

  • Versión del recurso y los artefactos consumidos.

    Artefactos consumidos en la ejecución de canalización

  • Confirmaciones asociadas a cada recurso.

    Confirmaciones en la ejecución de canalización

  • Elementos de trabajo asociados a cada recurso.

Rastreabilidad del entorno

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

Confirmaciones en variables de entorno

Presentación de información de canalizaciones de implementación continua asociadas en canalizaciones de integración continua

Para proporcionar rastreabilidad completa, puede realizar un seguimiento de las canalizaciones de implementación continua que consumen una canalización de integración continua determinada. Puede ver la lista de canalizaciones YAML de implementación continua en las que se consume una ejecución de canalización de integración continua mediante el recurso pipeline. Si otras canalizaciones consumen la canalización de integración continua, 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 esta.

Información de canalizaciones de implementación continua en canalizaciones de integración continua

Soporte técnico y trazabilidad de los problemas de desencadenadores 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 llamado Problemas del desencadenador, donde puede descubrir por qué los desencadenadores no se ejecutan. Para acceder a esta página, abra el historial de canalizaciones. La opción Problemas del desencadenador solo está disponible para los recursos que no son de repositorio.

Selección de

Los desencadenadores de recursos podrían no ejecutarse por los siguientes motivos.

  • Si el origen de la conexión de servicio que se proporciona no es válido, o si hay algún error de sintaxis en el desencadenador, este no se configura, lo que provoca un error.

  • Si no coinciden las condiciones del desencadenador, el desencadenador no se ejecuta. Aparece una advertencia para que pueda saber por qué las condiciones no coincidieron.

    Soporte técnico de los problemas del desencadenador

Pasos siguientes

Adición y uso de grupos de variables

Preguntas más frecuentes

¿Por qué debo usar canalizaciones resources en lugar del acceso directo download?

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 optar por descargar los artefactos en trabajos de compilación o invalidar el comportamiento de descarga en los trabajos de implementación con download. Para obtener más información, consulte steps.download.

¿Por qué debo usar resources en lugar de la tarea Descargar artefactos de canalización?

Al usar la tarea Descargar artefactos de canalización directamente, se pierde la rastreabilidad y los desencadenadores. A veces tiene sentido usar la tarea Descargar artefactos de canalización directamente. Por ejemplo, podría tener una tarea de script almacenada en una plantilla diferente que requiera que se descarguen artefactos de una compilación. O bien, es posible que no sepa si alguien que usa una plantilla quiere agregar un recurso de canalización. 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?

Deberá configurar una canalización de versión clásica, ya que el desencadenador de recursos de contenedores no está disponible para Docker Hub en canalizaciones YAML.

  1. Cree una nueva conexión de servicio de Docker Hub.

  2. Cree una canalización de versión clásica y agregue un artefacto de Docker Hub. Establezca la conexión de servicio. Seleccione el espacio de nombres, el repositorio, la versión y el alias de origen.

    Adición de un artefacto de Docker Hub.

  3. Seleccione el desencadenador y establezca el desencadenador de implementación continua en Habilitar. Creará una versión cada vez que se produzca una inserción de Docker en el repositorio seleccionado.

  4. Cree una fase y un trabajo nuevos. Agregue dos tareas: el inicio de sesión de Docker y Bash:

  • La tarea Docker tiene la acción login y le registra en Docker Hub.

  • La tarea Bash ejecuta docker pull <hub-user>/<repo-name>[:<tag>]. Reemplace hub-user, repo-name y tag por sus valores.

    Adición de las tareas de Inicio de sesión de Docker y Bash.

¿Cómo puedo validar y solucionar problemas de webhooks?

  1. Cree una conexión de servicio.

  2. Haga referencia a la conexión de servicio y asigne un nombre al webhook en la sección webhooks.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Ejecutar la canalización. Al ejecutar la canalización, el webhook se creará en Azure como una tarea distribuida para su organización.

  4. Realice una llamada API POST con JSON válido en el cuerpo a https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Si recibe una respuesta de código de estado 200, el webhook está listo para su consumo por la canalización. Si recibe una respuesta de código de estado 500 con el error Cannot find webhook for the given webHookId ..., el código puede estar en una rama que no sea la predeterminada.

    1. Abra la canalización.
    2. Seleccione Editar.
    3. Seleccione el menú "Más acciones". Selección del menú .
    4. Seleccione Desencadenadores>YAML>Obtener orígenes.
    5. Vaya a Rama predeterminada para compilaciones manuales y programadas para actualizar la rama de características.
    6. Seleccione Guardar y poner en cola.
    7. 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.