Compartir vía

Tipos de tareas y uso

  • Artículo

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

Una tarea realiza una acción en una canalización y es un script o procedimiento empaquetado que se abstrae con un conjunto de entradas. Las tareas son bloques de compilación para definir la automatización en una canalización.

Al ejecutar un trabajo, todas las tareas se ejecutan en secuencia, una después de la otra. Para ejecutar el mismo conjunto de tareas en paralelo en varios agentes o para ejecutar algunas tareas sin usar un agente, consulte trabajos.

De forma predeterminada, todas las tareas se ejecutan en el mismo contexto, ya sea en el host o en un contenedor de trabajos.

Opcionalmente, puede utilizar destinos de paso para controlar el contexto de una tarea individual.

Obtenga más información sobre cómo especificar propiedades para una tarea con las tareas integradas.

Al ejecutar un trabajo, todas las tareas se ejecutan en secuencia, una después de la otra, en un agente. Para ejecutar el mismo conjunto de tareas en paralelo en varios agentes o para ejecutar algunas tareas sin usar un agente, consulte trabajos.

Para obtener más información sobre los atributos generales admitidos por las tareas, consulte la referencia de YAML para steps.task.

Tareas personalizadas

Azure DevOps incluye tareas integradas para habilitar escenarios fundamentales de compilación e implementación. También puede crear tokens propios personalizados.

Además, Visual Studio Marketplace ofrece muchas extensiones; cada una de las cuales, cuando se instala en su suscripción o colección, amplía el catálogo de tareas con una o varias tareas. También puede escribir sus propias extensiones personalizadas para agregar tareas a Azure Pipelines.

En las canalizaciones de YAML, se hace referencia a las tareas por nombre. Si un nombre corresponde a la vez a una tarea predefinida y a una tarea personalizada, la primera tiene prioridad. Puede usar el GUID de tarea o un nombre completo para la tarea personalizada y evitar este riesgo:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Para buscar myPublisherId y myExtensionId, seleccione Obtener en una tarea en Marketplace. Los valores después de itemName en la cadena de dirección URL son myPublisherId y myExtensionId. También puede encontrar el nombre completo agregando la tarea a una canalización de versión y seleccionando Ver YAML al editar la tarea.

Versiones de tareas

Las tareas tienen versiones y debe especificar la versión principal de la que se usa en la canalización. Esto puede ayudar a evitar problemas cuando se publican nuevas versiones de una tarea. Normalmente, las tareas son compatibles con versiones anteriores, pero en algunos escenarios es posible que encuentre errores imprevisibles cuando se actualiza automáticamente una tarea.

Cuando se publica una nueva versión secundaria (por ejemplo, de 1.2 a 1.3), la canalización utilizará automáticamente la nueva versión. Sin embargo, si se publica una nueva versión principal (por ejemplo, 2.0), la canalización seguirá usando la versión principal especificada hasta que edite la canalización y cambie manualmente a la nueva versión principal. El registro incluirá una alerta de que hay disponible una nueva versión principal.

Puede establecer qué versión secundaria se usa especificando el número de versión completo de una tarea después del signo @ (ejemplo: GoTool@0.3.1). Solo puede usar versiones de tareas que existen para su organización.

En YAML, especifique la versión principal con @ en el nombre de la tarea. Por ejemplo, para anclar a la versión 2 de la tarea PublishTestResults:

steps:
- task: PublishTestResults@2

Las canalizaciones YAML no están disponibles en TFS.

Opciones de control de tareas

Cada tarea le ofrece algunas opciones de control.

Las opciones de control están disponibles como claves en la sección task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  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.
  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.

Las opciones de control están disponibles como claves en la sección task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  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.

Las opciones de control están disponibles como claves en la sección task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  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.

Nota:

Una tarea o trabajo determinado no puede decidir unilateralmente si el trabajo o la fase continúa. Lo que puede hacer es ofrecer un estado de correcto o erróneo, y las tareas o trabajos de bajada tienen cada uno un cálculo de condición que les permite decidir si se deben ejecutar o no. La condición predeterminada que es efectivamente "ejecutar si estamos en un estado correcto".

Continuar con el error lo altera de una forma sutil. En efecto, "engaña" a todos los pasos o trabajos de bajada para tratar cualquier resultado como "correcto" con el fin de tomar esa decisión. O dicho de otro modo, dice "no tenga en cuenta el error de esta tarea cuando tome una decisión sobre la condición de la estructura contenedora".

El período de tiempo de espera comienza cuando la tarea comienza a ejecutarse. No incluye el tiempo en que la tarea está en cola o está esperando un agente.

Nota:

Las canalizaciones pueden tener un tiempo de expiración de nivel de trabajo especificado además de un tiempo de expiración de nivel de tarea. Si el intervalo de tiempo de expiración del nivel de trabajo transcurre antes de que se complete el paso, se finaliza el trabajo en ejecución, incluso si el paso está configurado con un intervalo de tiempo de expiración más largo. Para más información, consulte Tiempos de expiración.

En este YAML, PublishTestResults@2 se ejecuta incluso si se produce un error en el paso anterior debido a la condición succeededOrFailed().

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Condiciones

  • Solo cuando todas las dependencias directas e indirectas anteriores que tienen el mismo grupo de agentes se hayan realizado correctamente. Si tiene grupos de agentes diferentes, esas fases o trabajos se ejecutarán simultáneamente. Esta es la condición predeterminada si no hay ninguna condición establecida en YAML.

  • Incluso si se ha producido un error en una dependencia anterior, a menos que se haya cancelado la ejecución. Use succeededOrFailed() en YAML para esta condición.

  • Incluso si se ha producido un error en una dependencia anterior, incluso si se ha cancelado la ejecución. Use always() en YAML para esta condición.

  • Solo cuando se ha producido un error en una dependencia anterior. Use failed() en YAML para esta condición.

Destino de paso

Las tareas se ejecutan en un contexto de ejecución, que es el host del agente o un contenedor. Un paso individual puede anular su contexto especificando un target. Las opciones disponibles son la palabra host para dirigirse al host del agente más los contenedores definidos en la canalización. Por ejemplo:

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Aquí, SampleTask se ejecuta en el host y AnotherTask se ejecuta en un contenedor.

Número de reintentos si se produjo un error en la tarea

Use retryCountOnTaskFailure para especificar el número de reintentos si se produce un error en la tarea. El valor predeterminado es de cero reintentos. Para obtener más información sobre las propiedades de la tarea, consulte steps.task en el esquema YAML.

- task: <name of task>
  retryCountOnTaskFailure: <max number of retries>
   ...

Nota:

  • Requiere la versión del agente 2.194.0 o posterior. En Azure DevOps Server 2022, no se admiten reintentos para tareas sin agente. Para obtener más información, consulte Actualización del servicio Azure DevOps el 16 de noviembre de 2021: reintentos automáticos para una tarea y Actualización del servicio Azure DevOps el 14 de junio de 2025: reintentos para las tareas del servidor.
  • El número máximo de reintentos permitidos es 10.
  • El tiempo de espera entre cada reintento aumenta después de cada intento erróneo, siguiendo una estrategia de retroceso exponencial. El primer reintento se produce después de 1 segundo, el segundo reintento después de 4 segundos y el 10 después de 100 segundos.
  • No hay ninguna suposición sobre la idempotencia de la tarea. Si la tarea tiene efectos secundarios (por ejemplo, si creó un recurso externo parcialmente), es posible que se produzca un error la segunda vez que se ejecute.
  • No hay información sobre el recuento de reintentos que está disponible para la tarea.
  • Se agrega una advertencia a los registros de tareas que indican que se ha producido un error antes de que se vuelva a intentar.
  • Todos los intentos de reintentar una tarea se muestran en la interfaz de usuario como parte del mismo nodo de tarea.

Las canalizaciones YAML no están disponibles en TFS.

Variables de entorno

Cada tarea tiene una propiedad env que es una lista de pares de cadenas que representan variables de entorno asignadas al proceso de tarea.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs: # Specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

En el siguiente ejemplo se ejecuta el paso script, que es un acceso directo para la tarea línea de comandos, seguido de la sintaxis de tarea equivalente. En este ejemplo se asigna un valor a la variable de entorno AZURE_DEVOPS_EXT_PAT, que se usa para autenticarse con la CLI de Azure DevOps.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'


- task: Bash@3
  inputs:
     targetType: # specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

En el siguiente ejemplo se ejecuta el paso script, que es un acceso directo para Bash@3, seguido de la sintaxis de tarea equivalente. En este ejemplo se asigna un valor a la variable de entorno ENV_VARIABLE_NAME y se devuelve el valor.

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

Instaladores de herramientas de compilación (Azure Pipelines)

Los instaladores de herramientas permiten que la canalización de compilación instale y controle las dependencias. En concreto, puede:

  • Instale una herramienta o un entorno de ejecución sobre la marcha (incluso en agentes hospedados por Microsoft) justo a tiempo para la compilación de CI.

  • Valide la aplicación o biblioteca en varias versiones de una dependencia, como Node.js.

Por ejemplo, puede configurar la canalización de compilación para ejecutar y validar la aplicación para varias versiones de Node.js.

Ejemplo: Prueba y validación de la aplicación en varias versiones de Node.js

Cree un archivo azure-pipelines.yml en el directorio base del proyecto con el siguiente contenido.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Cree una nueva canalización de compilación y ejecútelo. Observe cómo se ejecuta la compilación. El Instalador de la herramienta Node.js descarga la versión Node.js si aún no está en el agente. El script de línea de comandos registra la ubicación de la versión Node.js en el disco.

Las canalizaciones YAML no están disponibles en TFS.

Tareas del instalador de herramientas

Para obtener una lista de las tareas del instalador de herramientas, consulte Tareas del instalador de herramientas.

Deshabilitación de tareas integradas y de Marketplace

En la página de configuración de la organización, puede deshabilitar las tareas de Marketplace, las tareas integradas o ambas. Deshabilitar las tareas de Marketplace puede ayudar a aumentar la seguridad de las canalizaciones. Si deshabilita tanto las tareas predefinidas como de Marketplace, solo las tareas que instale con tfx estarán disponibles.

Ayuda y soporte técnico