Tipos de tarefa e uso

Azure DevOps Services | Servidor Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020

Os trabalhos do Azure Pipelines consistem em etapas, que podem ser tarefas ou scripts. Uma tarefa é um script ou procedimento pré-empacotado que executa uma ação ou usa um conjunto de entradas para definir a automação de pipeline. Este artigo descreve as tarefas do pipeline e como utilizá-las. Para obter informações sobre o esquema, consulte a definição steps.task .

O Azure Pipelines inclui muitas tarefas internas que permitem cenários fundamentais de build e implantação. Para obter uma lista das tarefas internas do Azure Pipelines disponíveis, consulte a referência de tarefa do Azure Pipelines. Você também pode instalar tarefas do Visual Studio Marketplace ou criar tarefas personalizadas.

Por padrão, todas as etapas em um trabalho são executadas em sequência no mesmo contexto, seja no host ou em um contêiner de trabalho. Opcionalmente, você pode usar destinos de etapa para controlar o contexto de tarefas individuais. Para executar algumas tarefas em paralelo em vários agentes ou sem usar um agente, consulte Especificar trabalhos em seu pipeline.

Gerenciamento de tarefas

As tarefas estão disponíveis e instaladas no nível da organização do Azure DevOps. Você só pode usar tarefas e versões de tarefa que existem para sua organização.

Você pode desabilitar tarefas internas, tarefas do Marketplace ou ambas nasConfigurações de> de > da Organização sob restrições de tarefa. Se você desabilitar tanto as tarefas internas quanto as do Marketplace, apenas as tarefas que você instalar usando o Node.js CLI para Azure DevOps estarão disponíveis.

Desabilitar tarefas do Marketplace pode ajudar a melhorar a segurança do pipeline. Na maioria das situações, você não deve desabilitar tarefas internas. Para obter mais informações, consulte controlar tarefas disponíveis.

Tarefas personalizadas

O Visual Studio Marketplace oferece muitas extensões que você pode instalar para estender o catálogo de tarefas do Azure Pipelines. Você também pode criar tarefas personalizadas. Para obter mais informações, consulte Adicionar uma extensão de tarefa para pipelines personalizados.

Em pipelines YAML, você se refere a tarefas por nome. Se o nome da tarefa personalizada corresponder a um nome de tarefa integrada, o pipeline utilizará a tarefa integrada. Para evitar essa situação, você pode referenciar sua tarefa personalizada usando o GUID (Identificador Global Único) exclusivo atribuído durante a criação da tarefa. Para obter mais informações, consulte Noções básicas sobre task.json componentes.

Versões da tarefa

As tarefas são executadas em versão e você deve especificar a versão principal das tarefas usadas em seu pipeline. Especificar a versão ajuda a evitar problemas quando novas versões de uma tarefa são lançadas.

Os pipelines são atualizados automaticamente para usar novas versões de tarefas secundárias, como 1.2 a 1.3. As versões menores de tarefas normalmente são compatíveis com versões anteriores, mas em alguns cenários, você pode encontrar erros imprevisíveis quando uma tarefa é atualizada automaticamente.

Se uma nova versão principal de tarefa, como a versão 2.0, for lançada, o pipeline continua a usar a versão principal especificada por você até que você edite o pipeline manualmente para mudar para a nova versão principal. Os logs de build fornecem alertas quando novas versões principais estão disponíveis. Você só pode usar versões de tarefa que existem para sua organização.

YAML

No YAML, especifique a versão principal usando @ o nome da tarefa. Por exemplo, para usar a versão 2 da PublishTestResults tarefa, especifique PublishTestResults@2. Você pode especificar qual versão secundária usar fornecendo o número completo da versão da tarefa após o @, como GoTool@0.3.1.

Clássico

Em pipelines clássicos, cada tarefa tem um seletor de versão para permitir que você escolha a versão desejada. Considere clonar o pipeline e testar o pipeline clonado com novas versões principais da tarefa. Se você selecionar uma versão de visualização, como a Versão Prévia 1.* , a versão ainda estará em desenvolvimento e poderá ter problemas.

Se você alterar a versão e tiver problemas com suas compilações, poderá reverter a alteração do pipeline na guia Histórico. Para pipelines de lançamento, a capacidade de restaurar para uma versão mais antiga não está disponível. Você precisa reverter manualmente as alterações no pipeline de lançamento e salvar o pipeline.

Opções de tarefa

YAML

As propriedades a seguir estão disponíveis para as etapas de pipeline task do YAML. Para obter mais informações, consulte a definição steps.task .

Propriedade	Tipo	Description
task	cadeia	Obrigatório como primeira propriedade. Nome da tarefa a ser executada.
inputs	cadeia	Entradas para a tarefa, utilizando pares de nome/valor.
condition	cadeia	Condições sob as quais a tarefa é executada.
continueOnError	boolean	Se deve continuar a executar mesmo em caso de falha.
displayName	cadeia	Nome compreensível para a tarefa.
enabled	boolean	Se esta tarefa deve ser executada quando o trabalho for realizado.
env	cadeia	Variáveis a serem mapeadas para o ambiente de processo, usando pares de nome/valor.
name	cadeia	ID da etapa.
retryCountOnTaskFailure	cadeia	Número de novas tentativas se a tarefa falhar.
target	cadeia	Ambiente no qual executar essa tarefa.
timeoutInMinutes	cadeia	O tempo máximo que a tarefa pode executar antes de ser cancelada automaticamente.

Condições

Uma tarefa não pode determinar se deve continuar o trabalho de pipeline após sua execução, apenas fornecendo um status final, como succeeded ou failed. Tarefas e trabalhos downstream podem definir um condition com base nesse status para determinar se devem ser executados.

A propriedade conditions especifica as condições sob as quais essa tarefa é executada. Por padrão, uma etapa é executada se nada em seu trabalho falhou ainda e a etapa imediatamente anterior foi concluída.

Você pode substituir ou personalizar esses padrões definindo a etapa a ser executada mesmo que uma dependência anterior falhe ou tenha outro resultado. Você também pode definir condições personalizadas, que são compostas por expressões.

Observação

As condições se aplicam a todas as dependências diretas e indiretas anteriores com o mesmo pool de agentes. Estágios ou trabalhos em pools de agentes diferentes são executados simultaneamente.

As condições com base no status de dependência anterior incluem:

• Bem-sucedido: execute somente se todas as dependências anteriores tiverem êxito. Esse comportamento será o padrão se nenhuma condição for definida no YAML. Para aplicar essa condição, especifique condition: succeeded().
• Sucesso ou falha: Execute mesmo se uma dependência anterior falhar, a menos que a execução seja cancelada. Para aplicar essa condição, especifique condition: succeededOrFailed().
• Sempre: execute mesmo se uma dependência anterior falhar, mesmo que a execução seja cancelada. Para aplicar essa condição, especifique condition: always().
• Falha: execute somente quando uma dependência anterior falhar. Para aplicar essa condição, especifique condition: failed().

No exemplo yaml a seguir, PublishTestResults@2 é executado mesmo que a etapa anterior tenha falhado devido à condição succeededOrFailed .

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

Continuar em caso de erro

A continueOnError propriedade indica à tarefa se deve continuar em execução e reportar o sucesso, independentemente de falhas. Se definido como true, esta propriedade informa à tarefa para ignorar um status failed e continuar em execução. As etapas e os trabalhos downstream tratam o resultado da tarefa como success quando tomam suas decisões de execução.

habilitado

Por padrão, a tarefa é executada sempre que o trabalho é executado. Você pode definir enabled como false para desabilitar a tarefa. Desabilitar temporariamente a tarefa é útil para remover a tarefa do processo para fins de teste ou para implantações específicas.

Contagem de tentativas em caso de falha da tarefa

A retryCountOnTaskFailure propriedade especifica o número de vezes para repetir a tarefa se ela falhar. O padrão é zero tentativas.

• O número máximo de tentativas permitidas é 10.
• O tempo de espera antes da repetição aumenta após cada tentativa com falha, seguindo uma estratégia de retirada exponencial. A primeira repetição acontece após 1 segundo, a segunda repetição após 4 segundos e a décima repetição após 100 segundos.
• Repetir a tarefa não fornece idempotência. Os efeitos colaterais da primeira tentativa, como a criação parcial de um recurso externo, podem fazer com que novas tentativas falhem.
• Nenhuma informação sobre o número de novas tentativas é disponibilizada para a tarefa.
• A falha da tarefa adiciona um aviso aos logs de tarefas indicando que ela falhou antes de repetir a tarefa.
• Todas as tentativas de repetição são mostradas na interface do usuário como parte do mesmo nó de tarefa.

Observação

A retryCountOnTaskFailure propriedade requer a versão do agente 2.194.0 ou posterior. No Azure DevOps Server 2022, não há suporte para novas tentativas para tarefas sem agente. Para obter mais informações, consulte a atualização de serviço do Azure DevOps em 16 de novembro de 2021 – Novas tentativas automáticas para uma tarefa e atualização de serviço do Azure DevOps em 14 de junho de 2025 – Novas tentativas para tarefas de servidor.

Meta

As tarefas são executadas em um contexto de execução, que é o host do agente ou um contêiner. Uma tarefa pode substituir seu contexto especificando um target. As opções disponíveis são host para direcionar o host do agente e todos os contêineres definidos no pipeline. No exemplo a seguir, SampleTask@1 é executado no host e AnotherTask@1 executado em um contêiner.

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

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

Tempo limite

O tempo limite começa a contar quando a tarefa inicia sua execução e não inclui o período em que a tarefa está enfileirada ou aguardando um agente.

Observação

Os pipelines podem especificar um tempo limite no nível do trabalho, além de um tempo limite de nível de tarefa. Se o intervalo de tempo limite do nível do trabalho se esgotar antes da conclusão de uma tarefa, o trabalho em execução será encerrado, mesmo que a tarefa esteja configurada com um intervalo de tempo limite mais longo. Para obter mais informações, confira Tempos limites.

Clássico

Em pipelines clássicos, as tarefas oferecem várias Opções de Controle.

habilitado

Desmarque a caixa de seleção Habilitada para desabilitar uma tarefa. Desabilitar temporariamente a tarefa é útil para remover a tarefa do processo para fins de teste ou para implantações específicas.

Dica

Você também pode clicar com o botão direito do mouse na tarefa no painel esquerdo e selecionar Desabilitar/Habilitar tarefas selecionadas para alternar essa configuração.

Continuar em caso de erro

Selecione essa opção se você quiser que essa tarefa relate o sucesso mesmo que ela falhe, possivelmente permitindo que tarefas dependentes no mesmo trabalho sejam executadas. A compilação ou implantação geral só pode ser parcialmente bem-sucedida. Se as tarefas subsequentes são executadas também depende da configuração Executar esta tarefa .

O número de repetições, caso a tarefa tenha falhado

Especifique o número de novas tentativas se essa tarefa falhar. O padrão é zero.

• O tempo de novas tentativas em tarefas com falha, em segundos. O tempo de espera antes da repetição aumenta após cada tentativa com falha.
• Repetir a tarefa não fornece idempotência. Os efeitos colaterais da primeira tentativa, como a criação parcial de um recurso externo, podem fazer com que novas tentativas falhem.
• Nenhuma informação sobre a contagem de repetições é disponibilizada para a tarefa.
• A falha da tarefa adiciona um aviso aos logs de tarefas indicando que ela falhou antes de repetir a tarefa.
• Todas as tentativas de repetição são mostradas na interface do usuário como parte do mesmo nó de tarefa.

Tempo limite

Insira o tempo máximo em minutos que a tarefa pode ser executada antes de ser cancelada automaticamente. O padrão é 0, ou tempo infinito. Definir um valor diferente de zero substitui a configuração do trabalho de tarefa pai. O tempo limite começa a contar quando a tarefa inicia sua execução e não inclui o período em que a tarefa está enfileirada ou aguardando um agente.

Executar esta tarefa

Selecione uma das seguintes condições para executar esta tarefa:

• Somente quando todas as tarefas anteriores tiverem sido bem-sucedidas. Essa condição é o padrão.
• Mesmo que uma tarefa anterior tenha falhado, a menos que o build tenha sido cancelado
• Mesmo que uma tarefa anterior tenha falhado, mesmo que o build tenha sido cancelado
• Somente quando uma tarefa anterior falhou
• Condições personalizadas e, em seguida, insira uma condição personalizada especificando uma expressão para quando essa tarefa deve ser executada.

Observação

Se você optar por executar tarefas mesmo quando o build for cancelado, especifique tempo suficiente para que essas tarefas sejam executadas nas opções de tempo limite.

Variáveis de ambiente

Você pode usar variáveis de ambiente para mapear informações definidas pelo sistema ou pelo usuário no processo de tarefa.

YAML

Uma tarefa de pipeline yaml pode especificar uma env propriedade, que lista cadeias de caracteres de nome/valor que representam variáveis de ambiente.

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

Você pode definir variáveis de ambiente usando script etapas ou usando scripts em tarefas de linha de comando, Bash ou PowerShell.

O exemplo a seguir executa uma etapa script que atribui um valor à variável de ambiente ENV_VARIABLE_NAME e exibe o valor.

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

O script anterior é funcionalmente o mesmo que executar uma tarefa Bash@3 com uma script entrada. O exemplo a seguir usa a task sintaxe.

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

Clássico

Em pipelines clássicos, você pode adicionar e editar variáveis de ambiente na seção Variáveis de Ambiente do editor de tarefas.

Tarefas do instalador de ferramentas de build

As tarefas do instalador de ferramentas de build permitem que o pipeline de build instale e controle dependências. Você pode usar tarefas do instalador de ferramentas de build para:

• Instale uma ferramenta ou runtime para um build, inclusive em agentes hospedados pela Microsoft.
• Valide seu aplicativo ou biblioteca em relação a várias versões de uma dependência, como Node.js.

Para obter uma lista de tarefas do instalador de ferramentas, consulte as tarefas da Ferramenta.

Exemplo: testar e validar um aplicativo em várias versões do Node.js

O exemplo a seguir configura um pipeline de build para executar e validar um aplicativo em várias versões do Node.js.

YAML

Crie um arquivo azure-pipelines.yml que tenha o seguinte conteúdo no diretório base do projeto.

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'

Salve e execute o pipeline. O trabalho é executado duas vezes, uma para cada versão do Node.js especificada na nodeVersion variável.

O Instalador de Ferramentas do Node.js baixará a versão do Node.js, se ainda não estiver no agente. O script de Linha de Comando grava a versão instalada na linha de comando.

Clássico

1. No trabalho do Agente para o pipeline Clássico, em Plano de execução, configure Paralelismo para Multi-configuração.

2. Em Multiplicadores, insira nodeVersion.

3. Defina o número máximo de agentes como 2.

4. Adicione a tarefa Node.js de instalador de ferramentas ao seu pipeline com as seguintes configurações:

   • Insira $(nodeVersion) em Especificação de Versão.
   • Marque a caixa de seleção para verificar a versão mais recente.

5. Adicione a tarefa Linha de Comando ao pipeline e insira o seguinte código em Script:

   echo Using Node version $(nodeVersion)
node --version

6. Na guia Variáveis, defina a variável nodeVersion com o valor 14.x, 16.x e selecione Definível no momento da fila.

   Observação

   Em um pipeline de liberação, selecione Definível no momento da liberação. Para obter mais informações, consulte Como posso editar variáveis no momento do lançamento?

7. Selecione Salvar e colocar na fila.

8. Na tela Executar pipeline , selecione Salvar e executar.

O trabalho é executado duas vezes, uma para cada versão do Node.js especificada na nodeVersion variável. A tarefa do instalador de ferramentas Node.js baixará a versão do Node.js caso ainda não esteja no agente. A tarefa Linha de Comando registra o local da versão do Node.js no disco.

Conteúdo relacionado

• Trabalhos
• Grupos de tarefas
• Referência de tarefa do Azure Pipelines

Ajuda e suporte

• Explore dicas de solução de problemas.
• Obtenha conselhos sobre o Stack Overflow.
• Publique suas perguntas, pesquise respostas ou sugira um recurso na Comunidade de Desenvolvedores de Azure DevOps.
• Obtenha suporte para o Azure DevOps.