Compartir a través de

Tipos de tareas y uso

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

Los trabajos de Azure Pipelines constan de pasos, que pueden ser tareas o scripts. Una tarea es un script o procedimiento empaquetado previamente que realiza una acción o usa un conjunto de entradas para definir la automatización de canalizaciones. En este artículo se describen las tareas de canalización y cómo usarlas. Para obtener información sobre el esquema, consulte la definición steps.task .

Azure Pipelines incluye muchas tareas integradas que permiten escenarios fundamentales de compilación e implementación. Para obtener una lista de las tareas integradas disponibles de Azure Pipelines, consulte la referencia de tareas de Azure Pipelines. También puede instalar tareas desde Visual Studio Marketplace o crear tareas personalizadas.

De forma predeterminada, todos los pasos de un trabajo se ejecutan en secuencia en el mismo contexto, ya sea en el host o en un contenedor de trabajos. Opcionalmente, puede usar objetivos de etapa para controlar el contexto de las tareas individuales. Para ejecutar algunas tareas en paralelo en varios agentes o sin usar un agente, consulte Especificación de trabajos en la canalización.

Administración de tareas

Las tareas están disponibles e instaladas en el nivel de organización de Azure DevOps. Solo puede usar las tareas y las versiones de tareas que existen para su organización.

Puede deshabilitar tareas integradas, tareas del Marketplace o ambas en Configuraciones de la organización>Pipelines>Configuración en Restricciones de tareas. Si deshabilita las tareas integradas y de Marketplace, solo están disponibles las tareas que instale mediante la CLI de Node para Azure DevOps .

Deshabilitar las tareas de Marketplace puede ayudar a mejorar la seguridad de la canalización. En la mayoría de las circunstancias, no debe deshabilitar las tareas integradas. Para obtener más información, consulte Control de las tareas disponibles.

Tareas personalizadas

Visual Studio Marketplace ofrece muchas extensiones que puede instalar para ampliar el catálogo de tareas de Azure Pipelines. También puede crear tareas personalizadas. Para obtener más información, consulte Agregar una extensión de tarea para canalizaciones personalizadas.

En las canalizaciones de YAML, se hace referencia a las tareas por nombre. Si el nombre de la tarea personalizada coincide con un nombre de tarea integrado, la canalización usa la tarea integrada. Para evitar esta situación, puede hacer referencia a su tarea personalizada usando el GUID único de la tarea que asignó al crear la tarea. Para obtener más información, consulte Descripción de los componentes de task.json.

Versiones de tareas

Las tareas tienen versiones y debe especificar la versión mayor de las tareas que utiliza en su canalización. Especificar la versión ayuda a evitar problemas cuando se publican nuevas versiones de una tarea.

Las canalizaciones se actualizan automáticamente para usar nuevas versiones de tareas secundarias, como 1.2 a 1.3. Las versiones menores de tareas suelen ser compatibles con versiones anteriores, pero en algunos escenarios podrían producirse errores imprevisibles cuando una tarea se actualiza automáticamente.

Si se lanza una nueva versión importante de tarea, como la versión 2.0, su canalización seguirá utilizando la versión principal especificada hasta que edite la canalización para cambiar manualmente a la nueva versión importante. Los registros de compilación proporcionan alertas cuando hay nuevas versiones principales disponibles. Solo puede usar versiones de tareas que existen para su organización.

En YAML, especifique la versión principal mediante @ en el nombre de la tarea. Por ejemplo, para usar la versión 2 de la PublishTestResults tarea, especifique PublishTestResults@2. Puede especificar qué versión secundaria se va a usar proporcionando el número de versión de tarea completa después de @, como GoTool@0.3.1.

Opciones de tareas

Las siguientes propiedades están disponibles para los pasos de canalización task de YAML. Para obtener más información, consulte la definición steps.task .

Propiedad Tipo Description
task cuerda / cadena Obligatorio como primera propiedad. Nombre de la tarea que se va a ejecutar.
inputs cuerda / cadena Datos de entrada para la tarea, mediante pares nombre-valor.
condition cuerda / cadena Condiciones en las que se ejecuta la tarea.
continueOnError boolean Si desea seguir ejecutándose incluso en caso de error.
displayName cuerda / cadena Nombre legible para humanos para la tarea.
enabled boolean Si se va a ejecutar esta tarea cuando se ejecute el trabajo.
env cuerda / cadena Variables que se van a asignar al entorno de proceso mediante pares nombre-valor.
name cuerda / cadena ID del paso.
retryCountOnTaskFailure cuerda / cadena Número de reintentos si se produce un error en la tarea.
target cuerda / cadena Entorno en el que ejecutar esta tarea.
timeoutInMinutes cuerda / cadena Tiempo máximo que la tarea puede ejecutarse antes de cancelarse automáticamente.

Condiciones

Una tarea no puede determinar si se va a continuar el trabajo de canalización una vez finalizada la tarea, solo se proporciona un estado final como succeeded o failed. A continuación, las tareas y los trabajos posteriores pueden establecer un valor condition basado en ese estado para determinar si deben ejecutarse.

La propiedad conditions especifica las condiciones en las que se ejecuta esta tarea. De forma predeterminada, un paso se ejecuta si aún no ha fallado nada en su trabajo y el paso anterior inmediato se ha completado.

Puede invalidar o personalizar estos valores predeterminados estableciendo el paso que se va a ejecutar incluso si se produce un error en una dependencia anterior o si se produce otro resultado. También puede definir condiciones personalizadas, que se componen de expresiones.

Nota:

Las condiciones se aplican a todas las dependencias directas e indirectas anteriores con el mismo grupo de agentes. Las fases o los trabajos de diferentes grupos de agentes se ejecutan simultáneamente.

Entre las condiciones basadas en el estado de dependencia anterior se incluyen:

  • Exitoso: Ejecutar solo si todas las dependencias anteriores tienen éxito. Este comportamiento es el valor predeterminado si no hay ninguna condición establecida en YAML. Para aplicar esta condición, especifique condition: succeeded().
  • Exitoso o fallido: Ejecuta incluso si falla una dependencia anterior, a menos que se cancele la ejecución. Para aplicar esta condición, especifique condition: succeededOrFailed().
  • Siempre: ejecute incluso si se produce un error en una dependencia anterior, incluso si se cancela la ejecución. Para aplicar esta condición, especifique condition: always().
  • Error: solo se ejecuta cuando se produce un error en una dependencia anterior. Para aplicar esta condición, especifique condition: failed().

En el siguiente ejemplo de YAML, PublishTestResults@2 se ejecuta incluso si se produjo un error en el paso anterior, debido a su condición succeededOrFailed .

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

Continuar ante un error

La continueOnError propiedad indica a la tarea si se va a seguir ejecutando y notificar el éxito independientemente de los errores. Si se establece en true, esta propiedad indica a la tarea que omita un failed estado y continúe ejecutándose. Los pasos y trabajos de nivel inferior tratan el resultado de la tarea como success cuando toman sus decisiones de ejecución.

habilitado

De forma predeterminada, la tarea se ejecuta cada vez que se ejecuta el trabajo. Puede establecer enabled en false para deshabilitar la tarea. Deshabilitar temporalmente la tarea es útil para quitar la tarea del proceso con fines de prueba o para implementaciones específicas.

Recuento de reintentos en caso de error de tarea

La retryCountOnTaskFailure propiedad especifica el número de veces que se reintenta la tarea si se produce un error. El valor predeterminado es de cero reintentos.

  • Es número máximo de reintentos permitidos es 10.
  • El tiempo de espera antes de reintentar aumenta después de cada intento con error, 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 décimo reintento después de 100 segundos.
  • Reintentar la tarea no proporciona idempotencia. Los efectos secundarios del primer intento, como la creación parcial de un recurso externo, podrían provocar errores en los reintentos.
  • No hay información sobre el número de reintentos disponibles para la tarea.
  • Error de tarea agrega una advertencia a los registros de tareas que indican que se produjo un error antes de volver a intentar la tarea.
  • Todos los reintentos se muestran en la interfaz de usuario como parte del mismo nodo de tarea.

Nota:

La retryCountOnTaskFailure propiedad 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 más información, consulte Actualización del servicio Azure DevOps el 16 de noviembre de 2021: reintentos automáticos para una tarea y la actualización del servicio Azure DevOps el 14 de junio de 2025: reintentos para las tareas del servidor.

Objetivo

Las tareas se ejecutan en un contexto de ejecución, que es el host del agente o un contenedor. Una tarea puede invalidar su contexto especificando un target. Las opciones disponibles son host para dirigir al host del agente, y los contenedores definidos en la canalización. En el ejemplo siguiente, SampleTask@1 se ejecuta en el host y AnotherTask@1 se ejecuta en un contenedor.

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

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

Tiempo de espera

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

Nota:

Las canalizaciones pueden especificar un tiempo de espera de nivel de trabajo además de un tiempo de espera de nivel de tarea. Si el intervalo de tiempo de espera de nivel de trabajo transcurre antes de que se complete una tarea, el trabajo en ejecución finaliza, incluso si la tarea está configurada con un intervalo de tiempo de espera más largo. Para más información, consulte Tiempos de expiración.

Variables de entorno

Puede usar variables de entorno para asignar información definida por el sistema o el usuario al proceso de tarea.

Una tarea de canalización YAML puede especificar una env propiedad, que enumera las cadenas de nombre y valor que representan variables de entorno.

- task: AzureCLI@2
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

Puede establecer variables de entorno mediante script pasos o mediante scripts en tareas de línea de comandos, Bash o PowerShell.

En el ejemplo siguiente se ejecuta un script paso que asigna un valor a la ENV_VARIABLE_NAME variable de entorno y devuelve el valor.

- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

El script anterior es funcionalmente el mismo que ejecutar una tarea de Bash@3 con una script entrada. En el ejemplo siguiente se usa la task sintaxis .

- task: Bash@3
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

Tareas de instalación de herramientas de construcción

Las tareas del instalador de herramientas de compilación permiten que la canalización de compilación instale y controle las dependencias. Puede usar las tareas del instalador de herramientas de compilación para:

  • Instale una herramienta o un entorno de ejecución para una compilación, incluido en agentes hospedados por Microsoft.
  • Valide la aplicación o biblioteca en varias versiones de una dependencia, como Node.js.

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

Ejemplo: Probar y validar una aplicación en varias versiones de Node.js

En el ejemplo siguiente se configura una canalización de compilación para ejecutar y validar una aplicación en varias versiones de Node.js.

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

pool:
  vmImage: 'windows-latest'

jobs:
- job: NodeJS
  strategy:
    matrix:
      node14:
        nodeVersion: '14.x'
      node16:
        nodeVersion: '16.x'
    maxParallel: 2
  steps:
    - task: NodeTool@0
      displayName: 'Install Node.js $(nodeVersion)'
      inputs:
        versionSpec: '$(nodeVersion)'
        checkLatest: true

    - script: |
        echo Using Node version $(nodeVersion)
        node --version
      displayName: 'Verify Node Installation'

Guarde y ejecute el pipeline. El trabajo se ejecuta dos veces, una por cada versión de Node.js que especificaste en la variable nodeVersion.

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 escribe la versión instalada en la línea de comandos.

Contenido relacionado

Ayuda y soporte técnico

  • Last updated on