Tipos de tarefa uso

Azure DevOps Services | | Azure DevOps Server 2022 Azure DevOps Server 2020 | Azure DevOps Server | 2019 TFS 2018

Observação

Em Microsoft Team Foundation Server (TFS) 2018 e versões anteriores, pipelines de build e lançamento são chamados de definições, execuções são chamadas de builds, conexões de serviço são chamadas de pontos de extremidade de serviço, estágios são chamados de ambientes e trabalhos são chamados de fases.

Uma tarefa é o bloco de construção para definir a automação em um pipeline. Uma tarefa é simplesmente um script ou procedimento empacotado que foi abstraído com um conjunto de entradas.

Quando você adiciona uma tarefa ao pipeline, ela também pode adicionar um conjunto de demandas ao pipeline. As demandas definem os pré-requisitos que devem ser instalados no agente para que a tarefa seja executada. Quando você executar o build ou a implantação, um agente que atenda a essas demandas será escolhido.

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 para 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 para executar algumas tarefas sem usar um agente, consulte trabalhos.

Tarefas personalizadas

Fornecemos algumas tarefas internas para habilitar cenários fundamentais de build e implantação. Também fornecemos diretrizes para criar sua própria tarefa personalizada.

Além disso, o Visual Studio Marketplace oferece várias 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. Além disso, você pode escrever suas próprias extensões personalizadas para adicionar tarefas ao Azure Pipelines ou TFS.

Em pipelines YAML, você se refere a tarefas por nome. Se um nome corresponder a uma tarefa na caixa 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 myExtensionIdselecionar Obter uma tarefa no marketplace. Os valores após a itemName 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 versão e selecionando Exibir YAML ao editar a tarefa.

Versões da tarefa

As tarefas são executadas em versão 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 for lançada (por exemplo, 1.2 a 1.3), seu build ou versão usará automaticamente a nova versão. No entanto, se uma nova versão principal for lançada (por exemplo, 2.0), seu build ou versão continuará a usar a versão principal especificada até editar o pipeline e mudar manualmente para a nova versão principal. O log de build ou versão 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 de versão completo de uma tarefa após o @ sinal (exemplo: GoTool@0.3.1). Você só pode usar versões de tarefa existentes 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 controle de tarefa

Cada tarefa oferece algumas Opções de Controle.

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

- 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

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

- 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

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

- 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

Observação

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 tarefas/trabalhos com êxito ou com falha e tarefas/trabalhos downstream têm 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 no erro altera isso de forma sutil. Ele efetivamente "engana" todas as etapas/trabalhos downstream para tratar qualquer resultado como "sucesso" para fins de tomar essa decisão. Ou, para dizer de outra forma, ele diz "não considere a falha desta tarefa quando você está tomando uma decisão sobre a condição da estrutura que 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 está enfileirada ou está aguardando um agente.

Neste YAML, PublishTestResults@2 será executado mesmo que a etapa anterior falhe devido à condição succeededOrFailed().

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

Condições

  • Somente quando todas as dependências anteriores com o mesmo pool de agentes tiverem sido bem-sucedidas. Se você tiver pools de agentes diferentes, esses estágios ou trabalhos serão executados simultaneamente. Esse será o padrão se não houver uma condição 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.8

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

Aqui, o SampleTask host é 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 repetições se a tarefa falhar. O padrão é zero.

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

Observação

  • Requer o agente versão 2.194.0 ou posterior. Não há suporte para tarefas sem agente.
  • A tarefa com falha é repetida imediatamente.
  • Não há nenhuma suposição sobre a idempotency da tarefa. Se a tarefa tiver efeitos colaterais (por exemplo, se tiver criado um recurso externo parcialmente), poderá falhar na segunda vez em que for executada.
  • Não há informações sobre a contagem de repetição 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

Há suporte para pipelines YAML no Azure DevOps Server 2019 e superior.

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 de tarefa equivalente. Este exemplo atribui um valor à AZURE_DEVOPS_EXT_PAT variável de ambiente, que é usada para autenticar 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'

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 em tempo real (mesmo em agentes hospedados pela Microsoft) bem a tempo do build de CI.

  • Valide seu aplicativo ou biblioteca em 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 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

Crie um novo pipeline de build e execute-o. Observe como o build é executado. O Node.js Tool Installer baixará a versão Node.js se ainda não estiver no agente. O script da 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 de ferramentas

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

Desabilitar tarefas internas e do Marketplace

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

Ajuda e suporte