Solucionar problemas nas execuções de pipeline

  • Artigo

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

Se a execução do pipeline não for concluída, você poderá usar as informações de diagnóstico e os logs fornecidos pela página de resumo da execução do pipeline para ajudar a solucionar o problema.

Captura de tela da página de resumo da execução de pipeline.

Exibir logs

Selecione a mensagem de erro para exibir os logs da tarefa que não foi concluída.

Captura de tela da mensagem de erro da tarefa na página de resumo de execução de pipeline.

A página de logs é exibida, com o erro selecionado. Neste exemplo, há um erro na tarefa cmd-line, em que o comando echo é inserido como ech.

Captura de tela do log de diagnóstico para a execução de pipeline.

Você pode exibir o log bruto da tarefa escolhendo Exibir log bruto e pode pesquisar o log usando Localizar.

Captura de tela das opções de exibição de log no Azure DevOps.

Examine os logs da tarefa com falha em busca de informações de erro e pistas sobre por que a tarefa está falhando. Por padrão, os logs não detalhados são gerados por uma execução de pipeline. Se os logs padrão não indicarem a causa do problema, você poderá obter mais informações configurando logs detalhados.

Página de análise de erros

A assistência para solução de problemas está disponível usando a página Análise de erro. Mova o mouse sobre a linha de informações de erro e escolha o ícone Exibir análise.

Captura de tela do ícone de análise de exibição na página de resumo de execução de pipeline.

Captura de tela do ícone de análise de exibição do Azure DevOps Server.

Escolha Exibir agente para agentes auto-hospedados (ou Sobre a imagem do agente hospedado para agentes hospedados pela Microsoft) para exibir mais informações sobre o agente usado para executar o pipeline e Exibir log para exibir os logs de execução do pipeline.

Captura de tela da página de análise de erros no portal Azure DevOps.

Escolha o nome da tarefa abaixo dos Detalhes de tempo de execução para exibir informações sobre a tarefa.

Captura de tela dos detalhes da tarefa da análise de erros.

Neste exemplo, você pode ver que há um erro no Value do Script. Escolha Sobre esta tarefa para exibir a documentação da tarefa.

Se o problema não for aparente na página de resumo da execução do pipeline ou navegando nos logs, verifique a seção de problemas comuns a seguir e confira os Revisar logs para diagnosticar problemas de pipeline para obter informações sobre como baixar logs completos que incluem informações adicionais de diagnóstico.

Problemas comuns

Insights de tarefa para execuções de pipeline com falha

O Azure DevOps fornece uma configuração de Informações sobre Tarefas para Execuções de Pipeline com Falha, que, quando habilitada, fornece notificações pop-up de falhas de compilação com um link para exibir um relatório.

Captura de tela das métricas de insights da tarefa.

Para definir essa configuração, navegue até Visualizar recursos, localize Task Insights para Execuções de Pipeline Com Falha e escolha a configuração desejada.

Captura de tela dos insights de tarefa para a configuração de execuções de pipeline com falha.

Tempo limite do trabalho

Um pipeline pode ser executado por um longo tempo e, em seguida, falhar devido ao tempo limite do trabalho ser atingido. O tempo limite do trabalho depende muito do agente que está sendo usado. Os agentes hospedados gratuitos da Microsoft têm um tempo limite máximo de 60 minutos por trabalho para um repositório privado e 360 minutos para um repositório público. Para aumentar o tempo limite máximo de um trabalho, você pode optar por qualquer um dos itens a seguir.

  • Comprar um agente hospedado da Microsoft que lhe dará 360 minutos para todos os trabalhos, independentemente do repositório usado
  • Usar um agente auto-hospedado para descartar quaisquer problemas de tempo limite devido ao agente

Saiba mais sobre o tempo limite do trabalho.

Observação

Se os trabalhos do agente hospedado pela Microsoft estiverem atingindo o tempo limite, verifique se você não especificou um tempo limite de pipeline menor que o tempo limite máximo para um trabalho. Para verificar, confira Tempos limite.

Problemas ao baixar o código

Meu pipeline está falhando em uma etapa de check-out

Se você estiver usando uma etapa checkout em um Repositório do Git do Azure Repos em sua organização que esteja em um projeto diferente do pipeline, certifique-se de que a configuração Limitar o escopo de autorização de trabalho para o projeto atual esteja desabilitada, ou siga as etapas em Identidades de build com escopo para garantir que o pipeline tenha acesso ao repositório.

Quando o pipeline não puder acessar o repositório devido ao escopo de autorização de trabalho limitado, você receberá o erro Git fetch failed with exit code 128 e seus logs conterão uma entrada semelhante a Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Se o pipeline estiver falhando imediatamente com Could not find a project that corresponds with the repository, verifique se o nome do projeto e do repositório está correto na etapa checkout ou na declaração de recurso do repositório.

Problemas no Controle de Versão do Team Foundation (TFVC)

Obter fontes que não baixam alguns arquivos

Isso pode ser caracterizado por uma mensagem no log "Todos os arquivos atualizados" do comando tf get. Verifique se a identidade de serviço interna tem permissão para baixar as fontes. O Serviço de Build da Coleção de Projetos ou o Serviço da Coleção de Projetos da identidade precisará de permissão para baixar as fontes, dependendo do escopo da autorização selecionado na guia Geral do pipeline de build. Na interface do usuário da Web do controle de versão, você pode navegar pelos arquivos do projeto em qualquer nível da hierarquia de pastas e verificar as configurações de segurança.

Obter fontes pelo Proxy do Team Foundation

A maneira mais fácil de configurar o agente para obter fontes por meio de um Proxy do Team Foundation é definir a variável de ambiente TFSPROXY que aponta para o servidor proxy do TFVC para o usuário em que o agente está sendo executado.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

Meu pipeline está falhando em uma etapa da linha de comando, como MSBUILD

É útil restringir se uma falha de build ou versão decorre de um problema de produto do Azure Pipelines/TFS (agente ou tarefas). Falhas de build e versão também podem resultar de comandos externos.

Verifique os logs para obter a linha de comando exata executada pela tarefa com falha. A tentativa de executar o comando localmente na linha de comando pode reproduzir o problema. Pode ser útil executar o comando localmente em seu próprio computador e/ou entrar no computador e executar o comando como a conta de serviço.

Por exemplo, o problema está acontecendo durante a parte do MSBuild do pipeline de build (por exemplo, você está usando a tarefa MSBuild ou Build do Visual Studio )? Nesse caso, tente executar o mesmo comando do MSBuild em um computador local usando os mesmos argumentos. Se você puder reproduzir o problema no computador local, as próximas etapas serão investigar o problema do MSBuild.

Layout do arquivo

O local das ferramentas, bibliotecas, cabeçalhos e outras coisas necessárias para um build pode ser diferente no agente hospedado do que no computador local. Se um build falhar porque não consegue encontrar um desses arquivos, você poderá usar os scripts abaixo para inspecionar o layout no agente. Isso pode ajudar você a rastrear o arquivo ausente.

Crie um novo pipeline YAML em um local temporário (por exemplo, um novo repositório criado para fins de solução de problemas). Conforme escrito, o script pesquisa diretórios em seu caminho. Opcionalmente, você pode editar a linha SEARCH_PATH= para pesquisar em outros locais.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Diferenças entre o prompt de comando local e o agente

Tenha em mente que algumas diferenças estão em vigor ao executar um comando em um computador local e quando um build ou versão está em execução em um agente. Se o agente estiver configurado para ser executado como um serviço no Linux, macOS ou Windows, ele não será executado em uma sessão de logon interativa. Sem uma sessão de logon interativa, há interação com a interface do usuário e outras limitações.

Erros do arquivo ou pasta em uso

Os erros File or folder in use geralmente são indicados por mensagens de erro, como:

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Etapas para solucionar problemas:

Detectar arquivos e pastas em uso

No Windows, ferramentas como o Monitor de Processo podem ser para capturar um rastreamento de eventos de arquivo em um diretório específico. Ou, por um instantâneo no tempo, ferramentas como Explorador de Processos ou Identificador podem ser usadas.

Exclusão antivírus

A verificação de software antivírus nos arquivos pode causar erros de uso de arquivo ou pasta durante um build ou versão. Adicionar uma exclusão antivírus para o diretório do agente e a "pasta de trabalho" configurada pode ajudar a identificar o software antivírus como o processo de interferência.

MSBuild e /nodeReuse:false

Se você invocar o MSBuild durante o build, passe o argumento /nodeReuse:false (forma curta /nr:false). Caso contrário, os processos do MSBuild permanecerão em execução após a conclusão do build. Os processos permanecem por algum tempo em antecipação a uma possível compilação subsequente.

Esse recurso do MSBuild pode interferir nas tentativas de excluir ou mover um diretório devido a um conflito com o diretório de trabalho dos processos do MSBuild.

As tarefas do MSBuild e do Visual Studio Build já adicionam /nr:false aos argumentos passados para o MSBuild. No entanto, se você invocar o MSBuild de seu próprio script, será necessário especificar o argumento.

MSBuild e /maxcpucount:[n]

Por padrão, as tarefas de build, como MSBuild e Visual Studio Build, executam o MSBuild com a opção /m. Em alguns casos, isso pode causar problemas de acesso a arquivos de vários processos.

Tente adicionar o argumento /m:1 às tarefas de build para forçar o MSBuild a executar apenas um processo por vez.

Problemas de arquivo em uso podem ocorrer ao aproveitar o recurso de processo simultâneo do MSBuild. Não especificar o argumento /maxcpucount:[n] (forma curta /m:[n]) instrui o MSBuild a usar apenas um único processo. Se você estiver usando as tarefas do MSBuild ou do Visual Studio Build, talvez seja necessário especificar "/m:1" para substituir o argumento "/m" adicionado por padrão.

Falhas inconsistentes ou intermitentes do MSBuild

Se você estiver enfrentando falhas intermitentes ou inconsistentes do MSBuild, tente instruir o MSBuild a usar apenas um único processo. Erros intermitentes ou inconsistentes podem indicar que sua configuração de destino é incompatível com o recurso de processo simultâneo do MSBuild. Confira MSBuild e /maxcpucount:[n].

O processo para de responder

O processo interrompe as causas de resposta e as etapas de solução de problemas:

Aguardando entrada

Um processo que para de responder pode indicar que um processo está aguardando entrada.

Executar o agente na linha de comando de uma sessão interativa conectada pode ajudar a identificar se um processo está solicitando uma caixa de diálogo para entrada.

Executar o agente como um serviço pode ajudar a eliminar programas de solicitação de entrada. Por exemplo, no .NET, os programas podem depender do Boolean System.Environment.UserInteractive para determinar se o prompt deve ser solicitado. Quando o agente está em execução como um serviço Windows, o valor é false.

Despejo de processo

A análise de um despejo do processo pode ajudar a identificar o que um processo com deadlock está aguardando.

Projeto WiX

A criação de um projeto WiX quando agentes personalizados do MSBuild estão habilitados pode fazer com que o WiX faça deadlock aguardando o fluxo de saída. A adição do argumento /p:RunWixToolsOutOfProc=true adicional do MSBuild contornará o problema.

Terminações de linha para várias plataformas

Ao executar pipelines em várias plataformas, às vezes você pode encontrar problemas com terminações de linha diferentes. Historicamente, o Linux e o macOS usavam caracteres de avanço de linha (LF), enquanto o Windows usava um retorno de carro mais um avanço de linha (CRLF). O Git tenta compensar a diferença fazendo com que as linhas terminem automaticamente em LF no repositório, mas CRLF no diretório de trabalho no Windows.

A maioria das ferramentas do Windows funciona bem com terminações somente LF, e esse comportamento automático pode causar mais problemas do que resolver. Se você encontrar problemas com base em terminações de linha, recomendamos que você configure o Git para preferir LF em todos os lugares. Para fazer isso, adicione um arquivo .gitattributes à raiz do repositório. Nesse arquivo, adicione a seguinte linha:

* text eol=lf

Variáveis com ' (aspas simples) acrescentadas

Se o pipeline incluir um script Bash que define variáveis usando o comando ##vso, você poderá ver um ' adicional acrescentado ao valor da variável definida. Isso ocorre devido a uma interação com set -x. A solução é desabilitar set -x temporariamente antes de definir uma variável. A sintaxe do Bash para fazer isso é set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Por que isso acontece?

Muitos scripts Bash incluem o comando set -x para ajudar na depuração. O Bash rastreará exatamente qual comando foi executado e o ecoará para stdout. Isso fará com que o agente veja o comando ##vso duas vezes e, na segunda vez, Bash terá adicionado o caractere ' ao final.

Por exemplo, considere este pipeline:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

No stdout, o agente verá duas linhas:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Quando o agente vir a primeira linha, MY_VAR será definido como o valor correto, "my_value". No entanto, quando vir a segunda linha, o agente processará tudo até o final da linha. MY_VAR será definido como "my_value".

As bibliotecas não são instaladas no aplicativo Python quando o script é executado

Quando um aplicativo Python é implantado, em alguns casos, um pipeline de CI/CD é executado e o código é implantado com êxito, mas o arquivo requirements.txt responsável pela instalação de todas as bibliotecas de dependência não é executado.

Para instalar as dependências, use um script pós-implantação na tarefa de implantação do Serviço de Aplicativo. O exemplo a seguir mostra o comando que você deve usar no script pós-implantação. Você pode atualizar o script para seu cenário.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Para solucionar problemas relacionados a conexões de serviço, confira Solução de problemas de conexão de serviço.

Pipeline parou de ouvir o agente

Se o pipeline falhar com uma mensagem como We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., verifique a utilização de recursos do agente para ver se a máquina do agente está ficando sem recursos. A partir de Sprint 228, os logs do Azure Pipelines contêm métricas de utilização de recursos para cada etapa.

Ao usar o Azure DevOps Services, você pode ver o uso dos recursos nos logs, incluindo uso de disco, uso de memória e utilização da CPU, habilitando logs detalhados. Quando o pipeline for concluído, pesquise entradas nos logsAgent environment resources para cada etapa.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Para obter informações sobre como capturar logs de utilização de recursos adicionais, consulte Capturar detalhes de utilização de recursos.

Habilitar o Gerenciador de Armazenamento para implantar conteúdo estático como .css e .js em um site estático do Azure DevOps por meio do Azure Pipelines

Nesse cenário, você pode usar a tarefa Cópia de Arquivo do Azure para carregar conteúdo no site. Você pode usar qualquer uma das ferramentas descritas em Carregar conteúdo para carregar conteúdo no contêiner da Web.

Próximas etapas