Sequência de execução do gasoduto

Azure DevOps Services | Azure DevOps Server | 2020 Azure DevOps Server 2019

As corridas representam uma execução de um oleoduto. Durante uma corrida, o oleoduto é processado, e os agentes processam um ou mais empregos. Um gasoduto inclui empregos, passos e tarefas. Executa a alimentação tanto dos gasodutos de integração contínua (CI) como de entrega contínua (CD).

Pipeline overview

Quando se corre um oleoduto, muitas coisas acontecem debaixo dos lençóis. Embora muitas vezes não precise de saber sobre eles, ocasionalmente é útil ter o panorama geral. A um nível elevado, a Azure Pipelines:

Do lado do agente, para cada trabalho, um agente:

Os empregos podem ter sucesso, falhar ou ser cancelados. Há também situações em que um trabalho pode não estar completo. Entender como isto acontece pode ajudá-lo a resolver problemas.

Vamos dividir cada ação um a um.

Processar o oleoduto

Expand YAML templates

Para transformar um oleoduto numa corrida, a Azure Pipelines passa por vários passos nesta ordem:

  1. Primeiro, expanda os modelos e avalie as expressões do modelo.
  2. Em seguida, avalie as dependências ao nível do estágio para escolher o(s) primeiro estágio(s) a correr.
  3. Para cada etapa selecionada para correr, duas coisas acontecem:
  4. Para cada trabalho selecionado para executar, expanda multi-configs (strategy: matrix ou strategy: parallel em YAML) em vários trabalhos de tempo de execução.
  5. Para cada trabalho em tempo de execução, avalie as condições para decidir se esse trabalho é elegível para executar.
  6. Solicite um agente para cada trabalho de execução elegível.

À medida que os trabalhos de funcionamento terminam, a Azure Pipelines verá se há novos postos de trabalho elegíveis para serem geridos. Em caso afirmativo, os passos 4- 6 repetem-se com os novos empregos. Da mesma forma, à medida que as etapas estiverem concluídas, os passos 2 - 6 serão repetidos para quaisquer novas etapas.

Esta encomenda ajuda a responder a uma pergunta comum: por que não posso usar certas variáveis nos parâmetros do meu modelo? Passo 1, expansão do modelo, funciona apenas no texto do documento YAML. As variáveis de tempo de execução não existem durante esse passo. Após o passo 1, os parâmetros do modelo foram resolvidos e já não existem.

Também responde a outra questão comum: por que não posso usar variáveis para resolver nomes de conexão de serviço/ambiente? Os recursos são autorizados antes de uma fase começar a funcionar, por isso não existem variáveis de nível de estágio e de nível de trabalho. Podem ser utilizadas variáveis ao nível do gasoduto, mas apenas as explicitamente incluídas no oleoduto. Os grupos variáveis são, por si só, um recurso sujeito a autorização, pelo que os seus dados também não estão disponíveis na verificação da autorização de recursos.

Solicite a um agente

Sempre que a Azure Pipelines precisar de um emprego, vai pedir à piscina um agente. (Os trabalhos de servidor são uma exceção, uma vez que funcionam no próprio servidor Azure Pipelines.) As piscinas de agentes hospedados e auto-hospedados pela Microsoft funcionam de forma ligeiramente diferente.

Pedidos de piscina de agente hospedados pela Microsoft

Primeiro, o serviço verifica os trabalhos paralelos da sua organização. Soma todos os postos de trabalho em todos os agentes hospedados pela Microsoft e compara-os com o número de empregos paralelos comprados. Se não houver vagas paralelas disponíveis, o trabalho tem de esperar por uma ranhura para se libertar.

Uma vez disponível uma ranhura paralela, o trabalho é encaminhado para o tipo de agente solicitado. Conceptualmente, a piscina hospedada pela Microsoft é um gigantesco conjunto global de máquinas. (Na realidade, são muitas piscinas físicas diferentes divididas por geografia e tipo de sistema operativo.) Com base no vmImage (em YAML) ou no nome da piscina (no editor clássico) solicitado, é selecionado um agente.

Pool selection

Todos os agentes na piscina da Microsoft são novas máquinas virtuais que nunca executaram nenhum oleoduto antes. Quando o trabalho terminar, o agente VM será descartado.

Pedidos de piscina de agente auto-hospedado

Semelhante ao pool hospedado pela Microsoft, o serviço verifica primeiro os trabalhos paralelos da sua organização. Soma-se todos os postos de trabalho em todos os agentes auto-alojados e compara-o com o número de empregos paralelos adquiridos. Se não houver vagas paralelas disponíveis, o trabalho tem de esperar por uma ranhura para se libertar.

Uma vez que uma ranhura paralela está disponível, a piscina auto-hospedada é examinada para um agente compatível. Os agentes auto-hospedados oferecem capacidades, que são cordas que indicam que determinado software está instalado ou as definições são configuradas. O oleoduto tem exigências, que são as capacidades necessárias para gerir o trabalho. Se um agente livre cujas capacidades correspondem às exigências do oleoduto não for encontrado, o trabalho continuará à espera. Se não houver agentes na piscina cujas capacidades correspondam às exigências, o trabalho falhará.

Os agentes auto-hospedados são normalmente reutilizados de corrida para correr. Isto significa que um trabalho de gasoduto pode ter efeitos colaterais: aquecimento de caches, tendo a maioria dos compromissos já disponíveis no repo local, e assim por diante.

Prepare-se para gerir um emprego

Uma vez que um agente aceite um trabalho, tem algum trabalho de preparação a fazer. O agente descarrega (e caches para a próxima vez) todas as tarefas necessárias para executar o trabalho. Cria espaço de trabalho no disco para manter o código de origem, artefactos e saídas usadas na execução. Depois começa a correr.

Executar cada passo

Os passos são executados sequencialmente, um após o outro. Antes de um passo começar, todos os passos anteriores devem ser terminados (ou ignorados).

Run each task

Os passos são implementados por tarefas. As tarefas em si são implementadas como Node.js ou scripts PowerShell. O sistema de tarefas encaminha entradas e saídas para os scripts de suporte. Também fornece alguns serviços comuns, tais como alterar o caminho do sistema e criar novas variáveis de gasoduto.

Cada passo corre no seu próprio processo, isolando-o do ambiente deixado por passos anteriores. Devido a este modelo process-per-passo, as variáveis ambientais não são preservadas entre etapas. No entanto, as tarefas e scripts têm um mecanismo para comunicar de volta ao agente: registar comandos. Quando uma tarefa ou script escreve um comando de registo para padrão, o agente tomará todas as medidas solicitadas.

Há um comando de agente para criar novas variáveis de gasoduto. As variáveis de gasoduto serão automaticamente convertidas em variáveis ambientais no passo seguinte. Para definir uma nova variável myVar com um valor de myValue, um script pode fazê-lo:

echo '##vso[task.setVariable variable=myVar]myValue'
Write-Host "##vso[task.setVariable variable=myVar]myValue"

Reportar e recolher resultados

Cada passo pode reportar avisos, erros e falhas. Erros e avisos são comunicados à página de resumo do pipeline, marcando a tarefa como "bem sucedida com problemas". As falhas também são reportadas à página do resumo, mas marcam a tarefa como "falhada". Um passo é uma falha se reportar explicitamente falha (usando um ##vso comando) ou terminar o script com um código de saída não zero.

Logs and results flow from agent to service

À medida que os passos são executados, o agente está constantemente a enviar linhas de saída para o serviço. É por isso que se pode ver uma transmissão em direto da consola. No final de cada passo, toda a saída do degrau também é carregada como um ficheiro de registo. Os registos podem ser descarregados uma vez que o gasoduto esteja terminado. Outros itens que o agente pode carregar incluem artefactos e resultados de testes. Estes também estão disponíveis após o fim do gasoduto.

Estado e condições

O agente acompanha o sucesso ou o fracasso de cada passo. À medida que os passos forem bem sucedidos com problemas ou falhas, o estado do trabalho será atualizado. O trabalho reflete sempre o "pior" resultado de cada um dos seus passos: se um passo falhar, o trabalho também falha.

Antes de dar um passo, o agente verificará a condição do passo para determinar se deve funcionar. Por defeito, um passo só será executado quando o estatuto do trabalho for bem sucedido ou sucedido com problemas. Muitos postos de trabalho têm medidas de limpeza que precisam de ser executadas independentemente do que mais aconteceu, para que possam especificar uma condição de "sempre()". As etapas de limpeza também podem ser definidas para serem executadas apenas no cancelamento. Um passo de limpeza que se sucede não pode salvar o trabalho de falhar; empregos nunca podem voltar ao sucesso depois de entrar em fracasso.

Tempos limite e desligamentos

Cada trabalho tem um tempo limite. Se o trabalho não tiver terminado no tempo especificado, o servidor cancelará o trabalho. Tentará sinalizar o agente para parar, e marcará o trabalho como cancelado. Do lado do agente, isto significa cancelar todos os passos restantes e carregar quaisquer resultados restantes.

Os empregos têm um período de carência conhecido como o tempo limite de cancelamento para completar qualquer trabalho de cancelamento. (Lembre-se, os passos podem ser marcados para correr mesmo no cancelamento.) Após o intervalo de tempo mais o tempo limite de cancelamento, se o agente não tiver comunicado que o trabalho parou, o servidor marcará o trabalho como uma falha.

Como a Azure Pipelines distribui trabalho a máquinas de agentes, de vez em quando, os agentes podem deixar de responder ao servidor. Isto pode acontecer se a máquina de hospedeiro do agente desaparecer (perda de energia, VM desligada) ou se houver uma falha de rede. Para ajudar a detetar estas condições, o agente envia uma mensagem de batimento cardíaco uma vez por minuto para informar o servidor de que ainda está a funcionar. Se o servidor não receber um batimento cardíaco durante cinco minutos consecutivos, assume que o agente não voltará. O trabalho é marcado como uma falha, informando o utilizador de que deve voltar a tentar o oleoduto.

Gerir corre através do CLI

Utilizando o Azure DevOps CLI, pode listar o pipeline que corre no seu projeto e ver detalhes sobre uma execução específica. Também pode adicionar e eliminar tags na sua tubagem.

Pré-requisitos

  • Deve ter instalado a extensão CLI do Azure DevOps, conforme descrito em Introdução com o Azure DevOps CLI.
  • Inscreva-se em Azure DevOps usando az login.
  • Para os exemplos deste artigo, desate a organização predefinido utilizando az devops configure --defaults organization=YourOrganizationURL.

A lista de gasodutos corre

A listar o gasoduto corre no seu projeto com o comando da lista de gasodutos az . Para começar, consulte Introdução com o Azure DevOps CLI.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Parâmetros opcionais

  • ramo: Filtro por construções para este ramo.
  • org: Azure DevOps organização URL. Pode configurar a organização predefinida utilizando az devops configure -d organization=ORG_URL. Requerido se não configurado como padrão ou recolhido através da utilização git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: IDs separados pelo espaço de definições para as quais listar construções.
  • projeto: Nome ou ID do projeto. Pode configurar o projeto predefinido utilizando az devops configure -d project=NAME_OR_ID. Requerido se não configurado como padrão ou recolhido através da utilização git config.
  • pedido de consulta: Definir a ordem em que o gasoduto funciona são listados. Os valores aceites são FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc e StartTimeDesc.
  • razão: Apenas a lista constrói por esta razão especificada. Os valores aceites são batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated e valideShelveset.
  • solicitado: Limite às construções solicitadas para um utilizador ou grupo especificado.
  • resultado: Limite às construções com um resultado especificado. Os valores aceites são cancelados, falhados, nenhum, parcialmenteduzidos e bem sucedidos.
  • estado: Limite às construções com estatuto especificado. Os valores aceites são todos, cancelados, concluídos, inProgress, nenhum, não Foi Iniciado e adiado.
  • tags: Limite às construções com cada uma das etiquetas especificadas. Espaço separado.
  • top: Número máximo de construções para listar.

Exemplo

O comando que se segue lista as três primeiras corridas de gasodutos que têm um estatuto de concluído e resultado de sucesso, e devolve o resultado em formato de tabela.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Mostrar detalhes de execução do gasoduto

Mostre os detalhes para uma corrida de gasodutos no seu projeto com os gasodutos az runs show command. Para começar, consulte Introdução com o Azure DevOps CLI.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parâmetros

  • id: Obrigatório. Identificação do oleoduto.
  • aberto: Opcional. Abre a página de resultados de construção no seu navegador web.
  • org: Azure DevOps organização URL. Pode configurar a organização predefinida utilizando az devops configure -d organization=ORG_URL. Requerido se não configurado como padrão ou recolhido através da utilização git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • projeto: Nome ou ID do projeto. Pode configurar o projeto predefinido utilizando az devops configure -d project=NAME_OR_ID. Requerido se não configurado como padrão ou recolhido através da utilização git config.

Exemplo

O seguinte comando mostra detalhes para o gasoduto executado com o ID 123 e devolve os resultados em formato de tabela. Também abre o seu navegador web para a página de resultados da construção.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Adicione etiqueta ao gasoduto

Adicione uma etiqueta a um gasoduto executado no seu projeto com os gasodutos az runs tag adicionar comando. Para começar, consulte Introdução com o Azure DevOps CLI.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parâmetros

  • run-id: Necessário. Identificação do oleoduto.
  • tags: Requerido. Etiquetas a adicionar ao gasoduto (valores separados por vírgulas).
  • org: Azure DevOps organização URL. Pode configurar a organização predefinida utilizando az devops configure -d organization=ORG_URL. Requerido se não configurado como padrão ou recolhido através da utilização git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • projeto: Nome ou ID do projeto. Pode configurar o projeto predefinido utilizando az devops configure -d project=NAME_OR_ID. Requerido se não configurado como padrão ou recolhido através da utilização git config.

Exemplo

O seguinte comando adiciona a tag YAML ao gasoduto executado com o ID 123 e devolve o resultado em formato JSON.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Listar etiquetas de corrida de gasodutos

Enuse as etiquetas para uma corrida de gasodutos no seu projeto com os gasodutos az executa o comando da lista de tags . Para começar, consulte Introdução com o Azure DevOps CLI.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parâmetros

  • run-id: Necessário. Identificação do oleoduto.
  • org: Azure DevOps organização URL. Pode configurar a organização predefinida utilizando az devops configure -d organization=ORG_URL. Requerido se não configurado como padrão ou recolhido através da utilização git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • projeto: Nome ou ID do projeto. Pode configurar o projeto predefinido utilizando az devops configure -d project=NAME_OR_ID. Requerido se não configurado como padrão ou recolhido através da utilização git config.

Exemplo

O comando a seguir lista as etiquetas para o gasoduto executado com o ID 123 e devolve o resultado em formato de tabela.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Eliminar tag do gasoduto executar

Elimine uma etiqueta de um gasoduto executado no seu projeto com os gasodutos az executa o comando de exclusão de etiqueta . Para começar, consulte Introdução com o Azure DevOps CLI.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parâmetros

  • run-id: Necessário. Identificação do oleoduto.
  • tag: Requerido. Etiqueta a eliminar do gasoduto.
  • org: Azure DevOps organização URL. Pode configurar a organização predefinida utilizando az devops configure -d organization=ORG_URL. Requerido se não configurado como padrão ou recolhido através da utilização git config. Exemplo: --org https://dev.azure.com/MyOrganizationName/.
  • projeto: Nome ou ID do projeto. Pode configurar o projeto predefinido utilizando az devops configure -d project=NAME_OR_ID. Requerido se não configurado como padrão ou recolhido através da utilização git config.

Exemplo

O seguinte comando elimina a etiqueta YAML do gasoduto com o ID 123.

az pipelines runs tag delete --run-id 123 --tag YAML