Compartilhar via

Tipos de tarefas e uso

  • Artigo

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.

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

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.

Ajuda e suporte