Builds com falha

Há vários motivos pelos quais seu build pode ter falhado e que podem ser exclusivos do seu projeto. Geralmente, uma maneira eficiente de diagnosticar falhas de build é compará-las a um build de trabalho. Esse processo pode minimizar variáveis e identificar condições relevantes para seu cenário.

Se a construção funcionar localmente, mas não no App Center

Normalmente, esse problema ocorre devido a arquivos não confirmados, ferramentas diferentes ou dependências não controladas. Para verificar, você pode fazer um git clone completo do projeto em uma nova pasta. Em seguida, compile com a mesma configuração que o App Center para comparação.

1. Abra o terminal ou o prompt de linha de comando e digite: mkdir appcenter-test
2. Em seguida, altere os diretórios: cd appcenter-test
3. Clone seu repositório com: git clone -b <branch> <remote_repo>
4. Inicie o projeto recém-clonado no IDE local ou na linha de comando.
5. Tente comparar o comando de build executado no App Center com o comando executado localmente.
6. Comparar as versões das ferramentas que você está usando localmente com nossos computadores de build de nuvem

Arquivos com nomes de arquivo ou locais modificados são ignorados

Os builds podem ignorar um arquivo de chave que foi movido ou renomeado recentemente. Tente selecionar Salvar ou Salvar & Build na configuração de build. Qualquer opção reindexa a árvore do repositório e atualiza a definição de build.

As causas conhecidas estão movendo ou renomeando scripts de build & arquivosnuget.config.

Comparando diferentes builds no App Center

Controlar alterações nas configurações de build

Você pode registrar a configuração do branch chamando este método de API: https://openapi.appcenter.ms/#/build/branchConfigurations_get

A API não permite a gravação direta de configurações anteriores. No entanto, você pode executar esse comando com um script de build personalizado para que seus builds registrem automaticamente a configuração atual quando forem executados.

Controlar alterações em computadores de build de nuvem do App Center

Assim como as configurações de build, você pode marcar as ferramentas atuais examinando este documento: Máquinas de Build de Nuvem.

No entanto, você pode registrar quais dessas ferramentas estão disponíveis para um build específico executando este comando em um script de build:

eval cat $HOME/systeminfo.md

Alguns branches funcionam enquanto outros falham

Tente verificar se há diferenças nas configurações de build ou no código confirmado entre branches. Além disso, se o build começar a falhar consistentemente após um determinado commit no mesmo branch, vale a pena verificar quais alterações foram feitas na confirmação com falha.

Os builds falham intermitentemente

Um build pode falhar sem nenhuma alteração no código-fonte ou nas configurações de build. Por exemplo:

• Versões diferentes de pacotes restaurados
• Serviços externos não estão respondendo
• Tarefas individuais no tempo limite de build
• e assim por diante

Tente verificar se o erro para o build é consistente quando as falhas ocorrem.

Isolando e interpretando mensagens de erro

Realce de erro automático

O Build do App Center tenta automaticamente realçar mensagens de erro comuns ou uma saída útil para torná-la mais visível. Muitas vezes, as pistas podem ser encontradas no erro primário, no log anterior ou no registro em log posteriormente. Esse aplicativo é assinado pelas configurações do projeto & configuração de build. Portanto, o jarsigner do Android registra um erro:

jarsigner: unable to sign jar: java.util.zip.ZipException: invalid entry compressed size (expected 13274 but got 13651 bytes)
##[error]Error: /usr/bin/jarsigner failed with return code: 1
##[error]Return code: 1

Explorando ainda mais

Se você não encontrar mensagens de erro relevantes, a próxima etapa será baixar os logs de build, o que você pode fazer na página de build do main. Abra a pasta chamada logs_n > Build e você verá uma lista de arquivos de log separados listados em ordem numérica. Por exemplo:

• 1_Intialize job.txt
• 2_Checkout.txt
• 3_Tag build.txt
• e assim por diante

Os logs são numerados com base nas fases principais do build. A maioria das falhas no build faz com que as fases sejam ignoradas e o log associado seja omitido:

• (Etapas 1 a 9)...
• Script.txt de build do 10_Pre
• 11_Build project.txt Xamarin.Android
• 12_Sign APK.txt
• Script.txt de build do 15_Post
• Checkout.txt de trabalho 20_Post
• 21_Finalize Job.txt

A fase 13 foi ignorada primeiro, portanto, a fase 12 é um bom ponto de partida. Fases posteriores também foram ignoradas, mas é menos provável que sejam relevantes.

Identificando commits correlacionados

Na interface do usuário do Build, você pode exibir o mensagem do commit e o hash aplicáveis ao seu build atual. Você pode usar esse recurso para rastrear e correlacionar resultados de build a alterações no código-fonte.

Você pode exibir mensagens de confirmação & hashes acessando Appcenter.ms -> [Nome da Organização] -> [Nome do Aplicativo] -> Build -> [Nome do Branch] -> [Número de Build]

URL do protótipo: https://appcenter.ms/orgs/[ORG-NAME]/apps/[APP-NAME]/build/branches/[BRANCH-NAME]/builds/[BUILD-NUMBER]

Na parte superior das informações do build, você verá o nome e o hash abreviado do commit. Na captura de tela:

• Bump Xamarin.UITest de 3.0.5 para 3.0.6
• Commit 328ff115

Clicar no hash abreviado abre o repositório vinculado no mesmo commit: https://github.com/microsoft/appcenter-Xamarin.UITest-Demo/commit/328ff115cb67280f7bdc70074ff605c8962470e4

Próximas etapas

Aqui estão algumas opções para pesquisar ainda mais seu problema:

• Outros documentos de solução de problemas de build
• StackOverflow (App Center)
• Documentação da plataforma de desenvolvimento.

Entrar em contato com o suporte

Faça logon https://appcenter.ms/apps e clique no ícone de chat no canto inferior direito da tela. Para obter melhores resultados, é uma boa ideia abrir o tíquete com:

• Um resumo de suas observações
• Detalhes e citações de sua pesquisa sobre o assunto
• URLs para builds com falha, incluindo informações essenciais como o nome do aplicativo & ID de build
• URLs para passar builds para comparar com as falhas (se aplicável)