Uso de tipos de & tareas

  • Artículo
  • 13 minutos para leer

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

Nota

En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.

Una tarea es el bloque de creación para definir la automatización en una canalización. Una tarea es simplemente un script o procedimiento empaquetado que se ha abstraido con un conjunto de entradas.

Al agregar una tarea a la canalización, también puede agregar un conjunto de demandas a la canalización. Las demandas definen los requisitos previos que se deben instalar en el agente para que se ejecute la tarea. Al ejecutar la compilación o implementación, se elegirá un agente que cumpla estas demandas.

Cuando se ejecuta 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, vea 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 usar 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 el esquema YAML.

Cuando se ejecuta un trabajo, todas las tareas se ejecutan en secuencia, una tras 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, vea trabajos.

Tareas personalizadas

Proporcionamos algunas tareas integradas para habilitar escenarios fundamentales de compilación e implementación. También hemos proporcionado instrucciones para crear su propia tarea personalizada.

Además, Visual Studio Marketplace ofrece una serie de 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. Además, puede escribir sus propias extensiones personalizadas para agregar tareas a Azure Pipelines o TFS.

En las canalizaciones de YAML, se hace referencia a las tareas por nombre. Si un nombre coincide con una tarea en cuadro y una tarea personalizada, la tarea en cuadro tendrá prioridad. Puede usar el GUID de la tarea o un nombre completo para la tarea personalizada para 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 , seleccione myExtensionIdmyPublisherId una tarea en Marketplace. Los valores después de en itemName la cadena de dirección URL son y myPublisherIdmyExtensionId . 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 tarea que se usa en la canalización. Esto puede ayudar a evitar problemas cuando se liberan nuevas versiones de una tarea. Las tareas suelen ser compatibles con versiones anteriores, pero en algunos escenarios puede encontrar errores impredecibles cuando una tarea se actualiza automáticamente.

Cuando se publica una nueva versión secundaria (por ejemplo, de 1.2 a 1.3), la compilación o versión usará automáticamente la nueva versión. Sin embargo, si se publica una nueva versión principal (por ejemplo, 2.0), la compilación o versión seguirá usando la versión principal que especificó hasta que edite la canalización y cambie manualmente a la nueva versión principal. El registro de compilación o versión 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 existan para su organización.

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

steps:
- task: PublishTestResults@2

Las canalizaciones yaml no están disponibles en TFS.

Opciones de control de tareas

Cada tarea ofrece algunas opciones de control.

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

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

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  retryCountOnTaskFailure: number # Max number of retries; default is zero
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Nota

Una tarea o un trabajo determinados no puede decidir si el trabajo o la fase continúa. Lo que puede hacer es ofrecer un estado de correcta o con errores, y cada una de las tareas o trabajos de nivel inferior tiene un cálculo de condición que les permite decidir si se ejecutan o no. La condición predeterminada que es efectivamente "ejecutar si estamos en un estado correcto".

Continuar en caso de error lo modifica de una manera sutil. De hecho, "hace trucos" 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 considere el error de esta tarea cuando tome una decisión sobre la condición de la estructura que lo contiene".

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

En este YAML, se ejecutará incluso si se produce un error en el paso anterior debido a la condición PublishTestResults@2PublishTestResults@2

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

Nota

Para obtener el esquema completo, vea Esquema YAML para .

Condiciones

  • Solo cuando todas las dependencias anteriores con el mismo grupo de agentes se han hecho correctamente. Si tiene grupos de agentes diferentes, esas fases o trabajos se ejecutarán simultáneamente. Este es el valor predeterminado si no hay una condición establecida en EL 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 del paso

Las tareas se ejecutan en un contexto de ejecución, que es el host del agente o un contenedor. Un paso individual puede invalidar su contexto especificando 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.8

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

En este caso, SampleTask se ejecuta en el host y en un AnotherTask contenedor.

Número de reintentos si la tarea no se pudo ejecutar

Use retryCountOnTaskFailure para especificar el número de reintentos si se produce un error en la tarea. El valor predeterminado es cero.

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

Nota

  • La tarea con errores se reinteta inmediatamente.
  • 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), puede producir un error la segunda vez que se ejecute.
  • No hay información sobre el número de reintentos puesto a disposición de la tarea.
  • Se agrega una advertencia a los registros de tareas que indica que se ha generado un error antes de reinterio.
  • 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

Las canalizaciones YAML se admiten Azure DevOps Server 2019 y versiones posteriores.

Cada tarea tiene una propiedad que es una lista de pares de cadenas que representan variables de env 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 ejemplo siguiente se ejecuta el paso , que es un acceso directo para la tarea Línea de scriptscript, seguido de la sintaxis de tarea equivalente. En este ejemplo se asigna un valor a la variable de entorno , que se usa para AZURE_DEVOPS_EXT_PAT la autenticación con Azure DevOps CLI.

# 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'

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 tiempo de ejecución sobre la marcha (incluso en agentes hospedadospor Microsoft) justo a tiempo para la compilación de CI.

  • Valide la aplicación o biblioteca con 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 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.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 ejecutarla. Observe cómo se ejecuta la compilación. El Node.js de herramientas de Node.js descarga la versión de Node.js si aún no está en el agente. El script de línea de comandos registra la ubicación de la 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, vea Tareas del instalador de herramientas.

Deshabilitación de tareas de Marketplace y de cuadro de texto

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

Ayuda y soporte técnico