Partilhar via

Resolver problemas de execuções de pipeline

  • Artigo

Serviços de DevOps do Azure | 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 do pipeline.

Ver registos

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 da execução do pipeline.

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

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

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

Captura de ecrã das opções de vista de registo no Azure DevOps.

Analise 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 erros . 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 do pipeline.

Captura de ecrã do ícone de análise de vista para o Azure DevOps Server.

Escolha View agent for self-hosted agents (ou About hosted agent image for Microsoft-hosted agents) para exibir mais informações sobre o agente usado para executar o pipeline e View log para exibir os logs de execução do pipeline.

Captura de ecrã da página de análise de erros no portal do Azure DevOps.

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

Captura de ecrã dos detalhes da tarefa a partir da análise de erros.

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

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

Problemas comuns

Informações de tarefas para execuções de pipeline com falha

O Azure DevOps fornece uma configuração Task Insights for Failed Pipeline Runs 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 de tarefas.

Para definir essa configuração, navegue até Visualizar recursos, localize Task Insights for Failed Pipeline Runs, e escolha a configuração desejada.

Captura de tela da configuração de insights de tarefas para 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. O tempo limite do trabalho depende muito do agente que está sendo usado. Os agentes alojados gratuitos da Microsoft têm um tempo limite máximo de 60 minutos por tarefa 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 seguintes.

  • Comprar um agente alojado da Microsoft que lhe dará 360 minutos para todos os trabalhos, independentemente do repositório utilizado
  • Utilizar um agente autoalojado para excluir quaisquer problemas de tempo limite devido ao agente

Saiba mais sobre o tempo limite da tarefa.

Nota

Se os trabalhos do agente hospedado pela Microsoft estiverem com o tempo limite, certifique-se de que você não especificou um tempo limite de pipeline inferior ao tempo limite máximo de um trabalho. Para verificar, consulte Tempos limites.

Problemas ao transferir código

Meu pipeline está falhando em uma etapa de checkout

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

Quando seu pipeline não puder acessar o repositório devido ao escopo limitado de autorização de trabalho, 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 repositoryo , certifique-se de que o nome do projeto e do checkout repositório esteja correto na etapa ou na declaração de recurso do repositório.

Problemas do 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 tf get comando. Verifique se a identidade de serviço incorporada tem permissão para transferir as origens. A identidade Project Collection Build Service ou Project Build Service precisará de permissão para baixar as fontes, dependendo do escopo de autorização selecionado na guia Geral do pipeline de compilação. Na IU da Web do controlo de versões, pode procurar os ficheiros de projeto em qualquer nível da hierarquia de pastas e verificar as definições de segurança.

Obtenha fontes através do Team Foundation Proxy

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

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 de linha de comando, como MSBUILD

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

Verifique nos logs a linha de comando exata executada pela tarefa com falha. Tentar executar o comando localmente a partir da linha de comando pode reproduzir o problema. Pode ser útil executar o comando localmente a partir da sua própria máquina e/ou iniciar sessão na máquina e executar o comando como a conta de serviço.

Por exemplo, o problema está acontecendo durante a parte MSBuild do seu pipeline de compilação (por exemplo, você está usando a tarefa MSBuild ou Visual Studio Build )? Em caso afirmativo, tente executar o mesmo comando MSBuild em uma máquina local usando os mesmos argumentos. Se você pode reproduzir o problema em uma máquina local, então suas próximas etapas são investigar o problema MSBuild.

Layout do arquivo

O local das ferramentas, bibliotecas, cabeçalhos e outras coisas necessárias para uma compilação pode ser diferente no agente hospedado do que na sua máquina local. Se uma compilação falhar porque não consegue encontrar um desses arquivos, você pode usar os scripts abaixo para inspecionar o layout no agente. Isso pode ajudá-lo 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). Como escrito, o script pesquisa diretórios em seu caminho. Opcionalmente, você pode editar a SEARCH_PATH= linha para pesquisar outros lugares.

# 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 uma máquina local e quando uma compilação ou versão está sendo executada em um agente. Se o agente estiver configurado para ser executado como um serviço no Linux, macOS ou Windows, ele não estará sendo executado em uma sessão interativa conectada. Sem uma sessão interativa conectada, a interação da interface do usuário e outras limitações existem.

Erros de ficheiros ou pastas em utilização

File or folder in use Os erros são frequentemente indicados por mensagens de erro, tais 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 [...]

Passos de resolução de problemas:

Detetar arquivos e pastas em uso

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

Exclusão de antivírus

A verificação de software antivírus de seus arquivos pode causar erros de arquivo ou pasta em uso durante uma compilação ou lançamento. 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 a compilação, certifique-se de passar o argumento /nodeReuse:false (forma /nr:falsecurta). Caso contrário, os processos do MSBuild permanecerão em execução após a conclusão da compilação. Os processos permanecem por algum tempo na expectativa de uma potencial construção subsequente.

Este recurso do MSBuild pode interferir com as tentativas de excluir ou mover um diretório - devido a um conflito com o diretório de trabalho do(s) processo(s) do MSBuild.

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

MSBuild e /maxcpucount:[n]

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

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

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

Falhas intermitentes ou inconsistentes de MSBuild

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

O processo deixa de responder

O processo para de responder causas e 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 a partir da 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 solicitar entrada. Por exemplo, no .NET, os programas podem confiar no Boolean System.Environment.UserInteractive para determinar se devem solicitar. Quando o agente está sendo executado como um serviço do Windows, o valor é false.

Despejo de processo

Analisar um despejo do processo pode ajudar a identificar o que um processo bloqueado está esperando.

Projeto WiX

A criação de um projeto WiX quando os registradores MSBuild personalizados estão habilitados pode fazer com que o WiX bloqueie a espera no fluxo de saída. Adicionar o argumento /p:RunWixToolsOutOfProc=true MSBuild adicional irá contornar o problema.

Terminações de linhas para várias plataformas

Quando você executa pipelines em várias plataformas, às vezes pode encontrar problemas com terminações de linha diferentes. Historicamente, Linux e macOS usavam caracteres linefeed (LF), enquanto o Windows usava um retorno de carro mais um linefeed (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 está bem com terminações somente LF, e esse comportamento automático pode causar mais problemas do que resolve. Se você encontrar problemas com base em terminações de linha, recomendamos que configure o Git para preferir LF em todos os lugares. Para fazer isso, adicione um .gitattributes arquivo à raiz do seu repositório. Nesse arquivo, adicione a seguinte linha:

* text eol=lf

Variáveis com ' (aspas simples) anexadas

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

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

Por que isso acontece?

Muitos scripts Bash incluem o set -x comando para ajudar na depuração. Bash irá rastrear exatamente qual comando foi executado e ecoá-lo para stdout. Isso fará com que o agente veja o ##vso comando duas vezes, e na segunda vez, Bash terá adicionado o ' personagem 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 para o valor correto, "my_value". No entanto, quando vê 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 para o 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, consulte Solução de problemas de conexão de serviço.

Pipeline parou de ouvir do 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 do Sprint 228, os logs do Azure Pipelines contêm métricas de utilização de recursos para cada etapa.

Ao usar os Serviços de DevOps do Azure, você pode ver a utilização de recursos nos logs, incluindo uso de disco, uso de memória e utilização de CPU, habilitando logs detalhados. Quando o pipeline for concluído, procure entradas nos logs para Agent environment resources 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.

Habilite 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 Upload de conteúdo para carregar conteúdo para o contêiner da Web.

Próximos passos