Tipos de tarefas e uso
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Uma tarefa realiza uma ação em um pipeline e é um script ou procedimento empacotado que foi abstraído com um conjunto de entradas. Tarefas são os blocos de construção para definir a automação em um pipeline.
Quando você executa um trabalho, todas as tarefas são executadas em sequência, uma após a outra. Para executar o mesmo conjunto de tarefas em paralelo em vários agentes ou executar algumas tarefas sem usar um agente, confira trabalhos.
Por padrão, todas as tarefas são executadas 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 uma tarefa individual.
Saiba mais sobre como especificar propriedades para uma tarefa com as tarefas internas.
Quando você executa um trabalho, todas as tarefas são executadas em sequência, uma após a outra, em um agente. Para executar o mesmo conjunto de tarefas em paralelo em vários agentes ou executar algumas tarefas sem usar um agente, confira trabalhos.
Para saber mais sobre os atributos gerais suportados pelas tarefas, consulte a Referência YAML para steps.task.
Tarefas personalizadas
O Azure DevOps inclui tarefas integradas para habilitar cenários fundamentais de compilação e implantação. Você também pode criar sua própria tarefa personalizada.
Além disso, o Visual Studio Marketplace oferece muitas extensões; cada uma das quais, quando instalada em sua assinatura ou coleção, estende o catálogo de tarefas com uma ou mais tarefas. Você também pode escrever suas próprias extensões personalizadas para adicionar tarefas ao Azure Pipelines.
Em pipelines YAML, você se refere a tarefas por nome. Se um nome corresponder a uma tarefa in-box e a uma tarefa personalizada, a tarefa in-box terá precedência. Você pode usar o GUID da tarefa ou um nome totalmente qualificado para a tarefa personalizada para evitar esse risco:
steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example
Para localizar myPublisherId
e myExtensionId
, selecione Obter em uma tarefa no marketplace. Os valores após o itemName
na cadeia de caracteres de URL são myPublisherId
e myExtensionId
. Você também pode encontrar o nome totalmente qualificado adicionando a tarefa a um pipeline de lançamento e selecionando Exibir YAML ao editar a tarefa.
Versões da tarefa
As tarefas têm controle de versão, e você precisa especificar a versão principal da tarefa usada em seu pipeline. Isso pode ajudar a evitar problemas quando novas versões de uma tarefa são lançadas. Normalmente, as tarefas são compatíveis com versões anteriores, mas em alguns cenários você pode encontrar erros imprevisíveis quando uma tarefa é atualizada automaticamente.
Quando uma nova versão secundária for lançada (por exemplo, 1.2 para 1.3), seu pipeline usará automaticamente a nova versão. No entanto, se uma nova versão principal for lançada (por exemplo, 2.0), seu pipeline continuará a usar a versão principal que você especificou, até você editar o pipeline e alterar manualmente para a nova versão principal. O log incluirá um alerta de que uma nova versão principal está disponível.
Você pode definir qual versão secundária é usada especificando o número completo de versão de uma tarefa após o sinal @
(exemplo: GoTool@0.3.1
). Você só pode usar versões de tarefa que existem para sua organização.
No YAML, você especifica a versão principal usando @
no nome da tarefa.
Por exemplo, para fixar na versão 2 da tarefa PublishTestResults
:
steps:
- task: PublishTestResults@2
Os pipelines YAML não estão disponíveis no TFS.
Opções de controle da tarefa
Cada tarefa oferece algumas Opções de Controle.
As opções de controle estão disponíveis como chaves na seção 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.
As opções de controle estão disponíveis como chaves na seção 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.
As opções de controle estão disponíveis como chaves na seção 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.
Observação
Uma determinada tarefa ou trabalho não pode decidir unilateralmente se o trabalho/fase continua. O que ele pode fazer é oferecer um status de êxito ou falha, e tarefas/trabalhos downstream têm, cada um, uma computação de condição que permite que eles decidam se devem ou não ser executados. A condição padrão, que é efetivamente "executar se estivermos em um estado bem-sucedido".
Continuar em caso de erro altera isso de maneira sutil. Essa opção efetivamente "engana" todas as etapas/trabalhos downstream, fazendo-os tratar qualquer resultado como "êxito" para fins de tomar essa decisão. Ou, para dizer de outra forma, ele diz "não considere a falha desta tarefa quando você estiver tomando uma decisão sobre a condição da estrutura que a contém".
O período de tempo limite começa quando a tarefa começa a ser executada. Ele não inclui a hora em que a tarefa é enfileirada ou está aguardando um agente.
Observação
Os pipelines podem ter um tempo limite de nível de trabalho especificado, além de um tempo limite de nível de tarefa. Se o intervalo de tempo limite no nível do trabalho decorrer antes da conclusão da etapa, o trabalho em execução será encerrado, mesmo que a etapa esteja configurada com um intervalo de tempo limite maior. Para obter mais informações, confira Tempos limites.
Neste YAML, PublishTestResults@2
é executado mesmo se a etapa anterior falhar devido à condição succeededOrFailed().
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.x'
architecture: 'x64'
- task: PublishTestResults@2
inputs:
testResultsFiles: "**/TEST-*.xml"
condition: succeededOrFailed()
Condições
Somente quando todas as dependências diretas e indiretas anteriores com o mesmo pool de agentes tiverem sido bem-sucedidas. Se houver pools de agentes diferentes, esses fases ou trabalhos serão executados simultaneamente. Esta condição é o padrão se nenhuma condição for definida no YAML.
Mesmo que uma dependência anterior tenha falhado, a menos que a execução tenha sido cancelada. Use
succeededOrFailed()
no YAML para essa condição.Mesmo que uma dependência anterior tenha falhado, mesmo que a execução tenha sido cancelada. Use
always()
no YAML para essa condição.Somente quando uma dependência anterior tiver falhado. Use
failed()
no YAML para essa condição.
- Condições personalizadas, que são compostas por expressões
Destino da etapa
As tarefas são executadas em um contexto de execução, que é o host do agente ou um contêiner.
Uma etapa individual pode substituir seu contexto especificando um target
.
As opções disponíveis são a palavra host
, para direcionar o host do agente mais todos os contêineres definidos no pipeline.
Por exemplo:
resources:
containers:
- container: pycontainer
image: python:3.11
steps:
- task: SampleTask@1
target: host
- task: AnotherTask@1
target: pycontainer
Aqui, o SampleTask
é executado no host e AnotherTask
é executado em um contêiner.
O número de repetições, caso a tarefa tenha falhado
Use retryCountOnTaskFailure
para especificar o número de repetições se a tarefa falhar. O padrão é zero tentativas. Para obter mais informações sobre as propriedades da tarefa, consulte steps.task no esquema YAML.
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
Observação
- 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 Atualização do serviço Azure DevOps em 16 de novembro de 2021, repetições automáticas para uma tarefa e Atualização do serviço Azure DevOps em 14 de junho de 2025, repetições para tarefas do servidor.
- O número máximo de tentativas permitidas é 10.
- O tempo de espera entre cada repetição aumenta após cada tentativa com falha, seguindo uma estratégia de retirada exponencial. A primeira repetição ocorre após 1 segundo, a segunda repetição após 4 segundos e a 10ª repetição após 100 segundos.
- Não há nenhuma suposição sobre a idempotência da tarefa. Se a tarefa tiver efeitos colaterais (por exemplo, se tiver criado um recurso externo parcialmente), ela poderá falhar na segunda vez em que for executada.
- Não há informações sobre a contagem de repetições disponibilizada para a tarefa.
- Um aviso é adicionado aos logs de tarefas indicando que ela falhou antes de ser repetida.
- Todas as tentativas de repetir uma tarefa são mostradas na interface do usuário como parte do mesmo nó de tarefa.
Os pipelines YAML não estão disponíveis no TFS.
Variáveis de ambiente
Cada tarefa tem uma propriedade env
, que é uma lista de pares de cadeias de caracteres que representam variáveis de ambiente mapeadas para o processo de tarefa.
- task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
ENV_VARIABLE_NAME: value
ENV_VARIABLE_NAME2: value
...
O exemplo a seguir executa a etapa script
, que é um atalho para a Tarefa de linha de comando, seguida pela sintaxe de tarefa equivalente. Este exemplo atribui um valor à variável de ambiente AZURE_DEVOPS_EXT_PAT
, que é usada para autenticação com a CLI do 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
...
O exemplo a seguir executa a etapa script
, que é um atalho para a Bash@3, seguida pela sintaxe de tarefa equivalente. Este exemplo atribui um valor à ENV_VARIABLE_NAME
variável de ambiente e ecoa o 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 ferramentas de build (Azure Pipelines)
Os instaladores de ferramentas permitem que o pipeline de build instale e controle suas dependências. Especificamente, você pode:
Instale uma ferramenta ou runtime durante a operação (mesmo em agentes hospedados pela Microsoft), na hora certa para o seu build de CI.
Valide seu aplicativo ou biblioteca em relação a várias versões de uma dependência, como Node.js.
Por exemplo, você pode configurar seu pipeline de build para executar e validar seu aplicativo para várias versões do Node.js.
Exemplo: testar e validar seu aplicativo em várias versões do Node.js
Crie um arquivo azure-pipelines.yml no diretório base do projeto com o conteúdo a seguir.
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
Crie um pipeline de build e execute-o. Observe como o build é executado. 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 registra o local da versão do Node.js no disco.
Os pipelines YAML não estão disponíveis no TFS.
Tarefas do instalador de ferramentas
Para obter uma lista das tarefas do instalador de ferramentas, confira Tarefas do instalador de ferramentas.
Desabilitando tarefas internas e do Marketplace
Na página de configurações da organização, você pode desabilitar tarefas do Marketplace, tarefas internas ou ambas.
Desabilitar tarefas do Marketplace pode ajudar a aumentar a segurança de seus pipelines.
Se você desabilitar as tarefas in-box e do Marketplace, somente as tarefas que você instalar usando tfx
estarão disponíveis.
Artigos relacionados
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.