Partilhar via

Tipos de tarefas e uso

  • Artigo

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

Uma tarefa executa uma ação em um pipeline e é um script ou procedimento empacotado que é abstraído com um conjunto de entradas. As 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, consulte 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, consulte trabalhos.

Para saber mais sobre os atributos gerais suportados pelas tarefas, consulte a Referência do YAML para steps.task.

Tarefas personalizadas

O Azure DevOps inclui tarefas internas 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 aos Pipelines do Azure.

Em pipelines YAML, você se refere a tarefas pelo nome. Se um nome corresponder a uma tarefa da caixa de entrada e a uma tarefa personalizada, a tarefa da caixa de entrada 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 Executar uma tarefa no mercado. 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 liberação e selecionando Exibir YAML ao editar a tarefa.

Versões de tarefas

As tarefas são versionadas e você deve 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 é lançada (por exemplo, 1.2 a 1.3), seu pipeline usa 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 especificada até que você edite o pipeline e altere 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 será usada especificando o número da versão completa de uma tarefa após o @ sinal (exemplo: GoTool@0.3.1). Você só pode usar versões de tarefas que existem para sua organização.

No YAML, você especifica a versão principal usando @ o nome da tarefa. Por exemplo, para fixar na versão 2 da PublishTestResults tarefa:

steps:
- task: PublishTestResults@2

Os pipelines YAML não estão disponíveis no TFS.

Opções de controlo de tarefas

Cada tarefa oferece-lhe algumas Opções de Controlo.

As opções de controle estão disponíveis como teclas na task seção.

- 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 teclas na task seção.

- 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 teclas na task seção.

- 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

Uma determinada tarefa ou trabalho não pode decidir unilateralmente se o trabalho/estágio continua. O que ele pode fazer é oferecer um status de bem-sucedido ou falhado, e tarefas/trabalhos a jusante cada um tem um cálculo de condição que lhes permite decidir se devem ser executados ou não. A condição padrão que é efetivamente "executar se estivermos em um estado bem-sucedido".

Continuar no erro altera isso de uma forma sutil. Ele efetivamente "engana" todas as etapas/trabalhos a jusante para tratar qualquer resultado como "sucesso" para fins de tomada dessa decisão. Ou, dito de outra forma, diz "não considere o fracasso desta tarefa quando estiver a tomar uma decisão sobre a condição da estrutura de contenção".

O período de tempo limite começa quando a tarefa começa a ser executada. Ele não inclui o tempo que a tarefa está na fila ou aguardando por um agente.

Nota

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 do 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, consulte 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 forem bem-sucedidas. Se você tiver pools de agentes diferentes, esses estágios ou trabalhos serão executados simultaneamente. Esta condição é o padrão se nenhuma condição estiver definida no YAML.

  • Mesmo que uma dependência anterior falhe, a menos que a execução seja cancelada. Use succeededOrFailed() no YAML para esta condição.

  • Mesmo que uma dependência anterior falhe e mesmo que a execução seja cancelada. Use always() no YAML para esta condição.

  • Apenas quando uma dependência anterior falha. Use failed() no YAML para esta condição.

Alvo 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 targetarquivo . As opções disponíveis são a palavra host para direcionar o host do agente mais quaisquer 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.

Número de repetições se a tarefa falhou

Use retryCountOnTaskFailure para especificar o número de novas tentativas 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>
   ...

Nota

  • Requer a versão 2.194.0 ou posterior do agente. 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 16 de novembro de 2021 - Repetições automáticas para uma tarefa e Atualização do serviço Azure DevOps 14 de junho de 2025 - Repetições para tarefas do servidor.
  • O tempo de espera entre cada nova tentativa aumenta após cada tentativa falhada. A primeira tentativa acontece em segundos.
  • Não há presunção sobre a idempotência da tarefa. Se a tarefa tiver efeitos colaterais (por exemplo, se criou um recurso externo parcialmente), ela poderá falhar na segunda vez em que for executada.
  • Não há informações sobre a contagem de tentativas disponibilizada para a tarefa.
  • Um aviso é adicionado aos logs de tarefas indicando que ele falhou antes de ser repetido.
  • 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 env propriedade que é uma lista de pares de cadeia de caracteres que representam variáveis de ambiente mapeadas no 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 script etapa, que é um atalho para a tarefa de linha de comando, seguida pela sintaxe da tarefa equivalente. Este exemplo atribui um valor à variável de ambiente, que é usada para autenticar com a AZURE_DEVOPS_EXT_PAT 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 script etapa, 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 compilação (Azure Pipelines)

Os instaladores de ferramentas permitem que seu pipeline de compilação instale e controle suas dependências. Mais concretamente, pode:

  • Instale uma ferramenta ou tempo de execução em tempo real (mesmo em agentes hospedados pela Microsoft) bem a tempo para sua compilação 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 compilação para executar e validar seu aplicativo para várias versões do Node.js.

Exemplo: Teste e valide seu aplicativo em várias versões do Node.js

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

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 novo pipeline de compilação e execute-o. Observe como a compilação é executada. O Node.js Tool Installer baixa a versão Node.js se ela ainda não estiver no agente. O script de linha de comando registra o local da versão Node.js no disco.

Os pipelines YAML não estão disponíveis no TFS.

Tarefas do instalador da ferramenta

Para obter uma lista de nossas tarefas do instalador de ferramentas, consulte Tarefas do instalador de ferramentas.

Desativando tarefas da caixa de entrada e do Marketplace

Na página de configurações da organização, você pode desabilitar tarefas do Marketplace, tarefas da caixa de entrada ou ambas. Desativar as tarefas do Marketplace pode ajudar a aumentar a segurança de seus pipelines. Se você desabilitar as tarefas da caixa de entrada e do Marketplace, somente as tarefas que você instalar usando tfx estarão disponíveis.

Ajuda e suporte