Solucionar problemas nas execuções de pipeline

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

Este tópico fornece diretrizes gerais de solução de problemas. Para obter solução de problemas específica sobre o .NET Core, consulte solução de problemas do .NET Core.

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.

Você pode usar as seções de solução de problemas a seguir para ajudar a diagnosticar problemas com seu pipeline. A maioria das falhas de pipeline se enquadra em uma dessas categorias.

O pipeline não será disparado

Se um pipeline não for iniciado, verifique os seguintes problemas comuns relacionados ao gatilho.

Observação

Um motivo adicional para que as execuções não sejam iniciadas é que sua organização fica inativa cinco minutos após o último usuário sair do Azure DevOps. Depois disso, cada um dos pipelines de build será executado mais uma vez. Por exemplo, enquanto sua organização está inativa:

  • Um build noturno de código em sua organização será executado apenas uma noite até que alguém entre novamente.
  • Os builds de CI de um outro repositório Git deixarão de ser executados até que alguém entre novamente.

As configurações da interface do usuário substituem a configuração do gatilho YAML

Os pipelines YAML podem ter suas trigger configurações de gatilho e pr de gatilho substituídas na interface do usuário das configurações do pipeline. Se seus trigger gatilhos pr não parecerem estar sendo disparados, verifique essa configuração. Ao editar seu pipeline, escolha ... e, em seguida, Gatilhos.

Pipeline settings UI

Verifique a substituição do gatilho YAML desta configuração para os tipos de gatilho (integração contínua ou validação de solicitação pull) disponíveis para o repositório.

Override YAML trigger from here.

Gatilhos de solicitação de pull sem suporte com Azure Repos

Se o pr gatilho não estiver sendo disparado e você estiver usando Azure Repos, isso ocorre porque pr os gatilhos não têm suporte para Azure Repos. No Azure Repos Git, as políticas de branch são usadas para implementar a validação de build de solicitação de pull. Para obter mais informações, consulte a política branch para validação de solicitação de pull.

Filtros de ramificação configurados incorretamente em gatilhos de CI e PR

Ao definir um gatilho YAML PR ou CI, você pode especificar as cláusulas e exclude as include cláusulas para branches e caminhos. Verifique se a include cláusula corresponde aos detalhes de sua confirmação e se a cláusula não os exclude exclui.

Importante

Quando você define um gatilho YAML PR ou CI, somente branches configurados explicitamente para serem incluídos dispararão uma execução. As inclusões são processadas primeiro e, em seguida, as exclusões são removidas da lista. Se você especificar uma exclusão, mas não especificar nenhuma inclusão, nada será disparado. Para obter mais informações, consulte pr e gatilho.

Ao definir um gatilho YAML PR ou CI, você pode especificar as cláusulas e exclude as include cláusulas para branches, marcas e caminhos. Verifique se a include cláusula corresponde aos detalhes de sua confirmação e se a cláusula não os exclude exclui. Para obter mais informações, consulte pr e gatilho.

Observação

Se você especificar uma exclude cláusula sem uma include cláusula, será equivalente a especificar * na include cláusula.

Conversões de fuso horário de gatilho agendadas

Os gatilhos agendados yaml são definidos usando fuso horário UTC. Se os gatilhos agendados não parecerem estar sendo disparados na hora certa, confirme as conversões entre UTC e seu fuso horário local, levando em conta também a configuração do dia. Para obter mais informações, consulte gatilhos agendados.

As configurações da interface do usuário substituem os gatilhos agendados do YAML

Se o pipeline YAML tiver gatilhos agendados yaml e gatilhos agendados definidos pela interface do usuário, somente os gatilhos agendados definidos pela interface do usuário serão executados. Para executar os gatilhos agendados definidos pelo YAML em seu pipeline YAML, você deve remover os gatilhos agendados definidos na interface do usuário das configurações do pipeline.

Para acessar a interface do usuário de configurações de pipeline de um pipeline YAML, edite seu pipeline, escolha ... e, em seguida, Gatilhos.

Pipeline settings UI

Remova todos os gatilhos agendados.

Delete scheduled triggers in the Pipeline settings UI.

Depois que todos os gatilhos agendados da interface do usuário forem removidos, um push deverá ser feito para que os gatilhos agendados yaml comecem a ser executados. Para obter mais informações, consulte gatilhos agendados.

Filas de pipeline, mas nunca obtém um agente

Se o pipeline for enfileirado, mas nunca receber um agente, verifique os itens a seguir.

Observação

Os seguintes cenários não consumirão um trabalho paralelo:

  • Se você usar pipelines de lançamento ou pipelines YAML de vários estágios, uma execução consumirá um trabalho paralelo somente quando ele estiver sendo implantado ativamente em um estágio. Embora a versão esteja aguardando uma aprovação ou uma intervenção manual, ela não consome um trabalho paralelo.
  • Quando você executa um trabalho de servidor ou implanta em um grupo de implantação usando pipelines de versão, não consome trabalhos paralelos.

Saiba mais: Como um trabalho paralelo é consumido por um pipeline, adicionar aprovações de pré-implantação, trabalhosde servidor, grupos de implantação

Limites de trabalho paralelos – nenhum agente disponível ou você atingiu seus limites gratuitos

Se você estiver executando outros pipelines no momento, talvez não tenha nenhum trabalho paralelo restante ou talvez tenha atingido seus limites livres.

Para verificar seus limites, navegue até Project configurações, trabalhos paralelos.

Pipelines concurrent jobs

Depois de examinar os limites, verifique a simultaneidade para ver quantos trabalhos estão em execução no momento e quantos estão disponíveis.

Se você estiver executando outros pipelines no momento, talvez não tenha nenhum trabalho paralelo restante ou talvez tenha atingido seus limites livres.

Não é possível acessar a Key Vault do Azure por trás do firewall de Azure DevOps

Se você não conseguir acessar o Azure Key Vault do pipeline, o firewall poderá estar bloqueando o endereço IP do agente Azure DevOps Services. Os endereços IP publicados no arquivo JSON semanal devem ser permitidos. Para obter mais informações, consulte agentes hospedados pela Microsoft: Rede.

Você não tem simultaneidade suficiente

Para verificar a quantidade de simultaneidade que você tem:

  1. Para verificar seus limites, navegue até Project configurações, trabalhos paralelos.

    Concurrent pipeline limits

    Você também pode acessar essa página navegando até https://dev.azure.com/{org}/_settings/buildqueue?_a=concurrentJobs, ou escolhendo gerenciar trabalhos paralelos nos logs.

    Manage parallel jobs

  2. Determine em qual pool você deseja verificar a simultaneidade (pools hospedados ou auto-hospedados pela Microsoft) e escolha Exibir trabalhos em andamento.

  3. Você verá o texto que diz que está executando trabalhos X/X no momento. Se ambos os números forem os mesmos, os trabalhos aguardarão até que os trabalhos em execução sejam concluídos no momento.

    View in-progress jobs

    Você pode exibir todos os trabalhos, incluindo trabalhos enfileirados, selecionando pools do Agente nas configurações de Project.

    View queued jobs

    Neste exemplo, o limite de trabalho simultâneo é um, com um trabalho em execução e outro enfileirado. Quando todos os agentes estão ocupados executando trabalhos, como neste exemplo, a seguinte mensagem é exibida quando trabalhos adicionais são enfileirados: The agent request is not running because all potential agents are running other requests. Current position in queue: 1. Neste exemplo, o trabalho é o próximo na fila, portanto, sua posição é uma.

Seu trabalho pode estar aguardando aprovação

Seu pipeline pode não passar para o próximo estágio porque está aguardando aprovação. Para obter mais informações, consulte Definir aprovações e verificações.

Todos os agentes disponíveis estão em uso

Os trabalhos podem esperar se todos os seus agentes estiverem ocupados no momento. Para verificar seus agentes:

  1. Navegue até https://dev.azure.com/{org}/_settings/agentpools

  2. Selecione o pool de agentes a ser verificado, neste exemplo , FabrikamPool e escolha Agentes.

    Agent status

    Esta página mostra todos os agentes atualmente online/offline e em uso. Você também pode adicionar agentes adicionais ao pool a partir desta página.

Demandas que não correspondem aos recursos de um agente

Se o pipeline tiver demandas que não atendam aos recursos de nenhum de seus agentes, o pipeline não será iniciado. Se apenas alguns dos seus agentes tiverem os recursos desejados e estiverem executando outros pipelines no momento, o pipeline será interrompido até que um desses agentes fique disponível.

Para verificar os recursos e as demandas especificadas para seus agentes e pipelines, confira Funcionalidades.

Observação

As funcionalidades e as demandas normalmente são usadas apenas com agentes auto-hospedados. Se o pipeline tiver demandas que não correspondam às funcionalidades do sistema do agente, a menos que você tenha rotulado explicitamente os agentes com recursos correspondentes, seus pipelines não receberão um agente.

Problemas de conexão do agente TFS

Falha na configuração ao testar a conexão do agente (somente TFS local)

Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs

Se o erro acima for recebido durante a configuração do agente, faça logon no computador TFS. Inicie o gerenciador do Serviços de Informações da Internet (IIS). Verifique se a Autenticação Anônima está habilitada.

is TFS anonymous authentication enabled

Comunicação perdida do agente

Esse problema é caracterizado pela mensagem de erro:

The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.

Esse erro pode indicar que o agente perdeu a comunicação com o servidor por um período de vários minutos. Verifique o seguinte para descartar a rede ou outras interrupções no computador do agente:

  • Verifique se as atualizações automáticas estão desativadas. Uma reinicialização do computador de uma atualização fará com que um build ou versão falhe com o erro acima. Aplique atualizações de forma controlada para evitar esse tipo de interrupção. Antes de reinicializar o computador do agente, o agente deve primeiro ser marcado como desabilitado na página de administração do pool e permitir que qualquer build em execução seja concluído.
  • Verifique se as configurações de suspensão estão desativadas.
  • Se o agente estiver em execução em uma máquina virtual, evite qualquer migração dinâmica ou outra operação de manutenção de VM que possa afetar severamente a integridade do computador por vários minutos.
  • Se o agente estiver em execução em uma máquina virtual, as mesmas recomendações de atualização do sistema operacional e recomendações de configuração de suspensão se aplicarão ao computador host. E também quaisquer outras operações de manutenção que afetam o computador host.
  • O log do monitor de desempenho ou outro log de métricas de integridade podem ajudar a correlacionar esse tipo de erro à disponibilidade restrita de recursos no computador do agente (disco, memória, arquivo de página, processador, rede).
  • Outra maneira de correlacionar o erro com problemas de rede é executar ping em um servidor indefinidamente e despejar a saída em um arquivo, juntamente com carimbos de data/hora. Use um intervalo íntegro, por exemplo, 20 ou 30 segundos. Se você estiver usando Azure Pipelines, convém executar ping em um domínio da Internet, por exemplo, bing.com. Se você estiver usando um servidor TFS local, convém executar ping em um servidor na mesma rede.
  • Verifique se a taxa de transferência de rede do computador é adequada. Você pode executar um teste de velocidade online para verificar a taxa de transferência.
  • Se você usar um proxy, verifique se o agente está configurado para usar o proxy. Consulte o tópico de implantação do agente.

Agente de Trabalho do TFS não iniciado

Isso pode ser caracterizado por uma mensagem no console Web "Aguardando a solicitação de um agente". Verifique se o TFSJobAgent (nome de exibição: Visual Studio Team Foundation Background Job Agent) Windows serviço foi iniciado.

URL de notificação configurada incorretamente (versão do agente 1.x)

Isso pode ser caracterizado por uma mensagem no console Web "Aguardando a saída do console de um agente" e o processo eventualmente atinge o tempo limite.

Uma URL de notificação incompatível pode fazer com que o trabalho processe para não se conectar ao servidor. Consulte o Console de Administração do Team Foundation, Camada de Aplicativo. O agente 1.x escuta a fila de mensagens usando a URL com a qual ele foi configurado. No entanto, quando uma mensagem de trabalho é extraída da fila, o processo de trabalho usa a URL de notificação para se comunicar novamente com o servidor.

Verificar Azure DevOps status de uma degradação do serviço

Verifique a Azure DevOps Portal de Status do Serviço para obter problemas que possam causar uma degradação do serviço, como o aumento do tempo de fila para os agentes. Para obter mais informações, consulte Azure DevOps Status do Serviço.

Falha na conclusão do pipeline

Se o pipeline receber um agente, mas não for concluído, verifique os seguintes problemas comuns. Se o problema não parecer corresponder a um destes, consulte Obter logs para diagnosticar problemas.

Tempo limite do trabalho

Um pipeline pode ser executado por um longo tempo e falhar devido ao tempo limite do trabalho. O tempo limite do trabalho depende muito do agente que está sendo usado. 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 para um trabalho, você pode optar por qualquer um dos seguintes.

  • Compre 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, consulte Timeouts.

Problemas ao baixar código

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

Se você estiver usando uma checkout etapa em um repositório git Azure Repos em sua organização que esteja em um projeto diferente do pipeline, verifique se o escopo de autorização de trabalho limite para a configuração atual do projeto está desabilitado ou siga as etapas nas 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 à 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, Could not find a project that corresponds with the repositoryverifique se o nome do projeto e do repositório estão corretos na etapa ou na checkout declaração de recurso do repositório.

Problemas de 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. A identidade Project Serviço de Build de Coleção ou Project Serviço de Build precisará de permissão para baixar as fontes, dependendo do escopo de autorização selecionado na guia Geral do pipeline de build. Na interface do usuário da Web de controle de versão, você pode procurar os arquivos de projeto em qualquer nível da hierarquia de pastas e verificar as configurações de segurança.

Obter fontes por meio do 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 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 build ou de versão é o resultado de um problema de produto 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. Tentar 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 fazer logon no computador e executar o comando como a conta de serviço.

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

Layout do arquivo

O local de 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 conseguir encontrar um desses arquivos, você poderá 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). Conforme escrito, o script pesquisa diretórios em seu caminho. Opcionalmente, você pode editar a SEARCH_PATH= linha 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 interativa de logon. Sem uma sessão interativa de logon, há interação com a interface do usuário e outras limitações.

Erros de arquivo ou pasta em uso

Erros de arquivo ou pasta em uso 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

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

Exclusão antivírus

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

MSBuild e /nodeReuse:false

Se você invocar MSBuild durante o build, certifique-se de passar o argumento /nodeReuse:false (forma /nr:falsecurta). Caso contrário, MSBuild processo permanecerá em execução após a conclusão do build. O processo(es) permanece por algum tempo na antecipação de um potencial build subsequente.

Esse recurso de MSBuild pode interferir nas tentativas de excluir ou mover um diretório devido a um conflito com o diretório de trabalho do MSBuild process(es).

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

MSBuild e /maxcpucount:[n]

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

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

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

Falhas de MSBuild intermitentes ou inconsistentes

Se você estiver enfrentando falhas de MSBuild intermitentes ou inconsistentes, tente instruir MSBuild 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 de MSBuild. Consulte MSBuild e /maxcpucount:[n].

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 contar com o Booleano System.Environment.UserInteractive para determinar se deseja solicitar. Ao executar como um serviço Windows, o valor é falso.

Despejo de processo

Analisar um despejo do processo pode ajudar a identificar o que um processo em deadlock está aguardando.

Projeto WiX

A criação de um projeto WiX quando agentes de MSBuild personalizados estiverem habilitados, poderá fazer com que o WiX esteja em deadlock aguardando no fluxo de saída. Adicionar o argumento /p:RunWixToolsOutOfProc=true MSBuild adicional solucionará 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, linux e macOS usavam caracteres de alimentação de linha (LF), enquanto Windows usavam um retorno de carro mais um CRLF (linefeed). O Git tenta compensar a diferença fazendo automaticamente que as linhas terminem em LF no repositório, mas CRLF no diretório de trabalho no Windows.

A maioria das ferramentas Windows está bem com finais 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 configurar o Git para preferir o LF em todos os lugares. Para fazer isso, adicione um .gitattributes arquivo à raiz do repositório. Nesse arquivo, adicione a seguinte linha:

* text eol=lf

Variáveis com ' (cotação única) acrescentadas

Se o pipeline incluir um script Bash que define variáveis usando o ##vso comando, 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 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 set -x comando para ajudar na depuração. Bash rastreará exatamente qual comando foi executado e o ecoará para stdout. Isso fará com que o agente veja o ##vso comando 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 ele vir a segunda linha, o agente processará tudo até o final da linha. MY_VAR será definido como "my_value".

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 por instalar 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 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 a solução de problemas de conexão de serviço.

Habilitar Gerenciador de Armazenamento implantar conteúdo estático como .css e .js em um site estático de Azure DevOps por meio de 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 no Upload de conteúdo para carregar conteúdo no contêiner da Web.

Obter logs para diagnosticar problemas

Se nenhuma das sugestões anteriores corresponder ao problema, você poderá usar as informações nos logs para diagnosticar o pipeline com falha.

Comece examinando os logs em sua compilação ou versão concluída. Você pode exibir os logs navegando até o resumo de execução de pipeline e selecionando o trabalho e a tarefa. Se uma determinada tarefa estiver falhando, verifique os logs dessa tarefa.

Além de exibir logs no resumo do build do pipeline, você pode baixar logs completos que incluem informações adicionais de diagnóstico e configurar logs mais detalhados para ajudar na solução de problemas.

Para obter instruções detalhadas sobre como configurar e usar logs, consulte Examinar logs para diagnosticar problemas de pipeline.

Preciso de mais ajuda. Encontrei um bug. Tenho uma sugestão. Para onde eu vou?

Obter assinatura, cobrança e suporte técnico

Relatar quaisquer problemas ou enviar comentários em Developer Community.

Damos as boas-vindas às suas sugestões: