Obrigado por seu resumo desses problemas!

É possível desativar os trabalhos apenas nos locais onde estão falhando?

Para crypto e fcrypt plugin @mpranj apontou que gpg-agent pode falhar no caso de alta carga do servidor. Talvez pudéssemos criar um trabalho de compilação separado para os testes do plugin crypto e fcrypt ? Para que outros desenvolvimentos não sejam bloqueados.

Obrigdo por sua contribuição!

Separar os trabalhos problemáticos pode tornar os ciclos de reconstrução mais curtos. Mas acho que está claro que não queremos nenhuma reconstrução manual. Portanto, temos as opções:

• tornando-o mais confiável
• alguns loops automáticos que tentam novamente em tais erros
• desativando os testes (quando alguém trabalha nessas partes, ela precisa ativá-los novamente)

O que você acha?

• tornando-o mais confiável

dificilmente possível, desde que utilizemos gpg-agent (o que é uma dor em trabalhos em lote)

• alguns loops automáticos que tentam novamente em tais erros

Isso parece sujo para mim.

• desativando os testes (quando alguém trabalha nessas partes, ela precisa ativá-los novamente)

Parece ser a opção que causa menos desconforto, embora fazer testes de regressão manual também não seja agradável.

Conforme discutido na reunião: devemos desativar os testes.

Alternativa também discutida na reunião: Usando ctest --rerun-failed

Executar ctest cria o arquivo <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (o carimbo de data / hora só é usado no modo Painel). Este arquivo também é usado por ctest --rerun-failed (consulte Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Ele simplesmente contém os números e nomes dos últimos testes reprovados.

Minha proposta seria chamar ctest como antes. Se sair sem sucesso, use grep em LastTestsFailed.log para verificar se um dos testes listados acima falhou. E só então use ctest --rerun-failed . Isso causa menos duplicação / saída confusa.

Mas se o problema realmente for uma carga elevada do servidor, isso não ajudará muito. Em vez disso, podemos tentar ctest --test-load . Isso deve fazer com que o ctest mantenha a carga da CPU abaixo de um certo limite.

IMO ainda a melhor opção seria desabilitar os testes e criar um pequeno trabalho de compilação que apenas instale as dependências necessárias para esses plugins / bibliotecas, apenas compile o que for necessário e execute apenas os testes problemáticos. Dessa forma, poderíamos levar o tempo de execução provavelmente para alguns minutos, caso em que a reinicialização manual seria aceitável, eu acho. Para comparação, nossos trabalhos do FreeBSD atualmente levam cerca de 10 minutos (7 minutos de construção, 2 minutos de teste, 1 minuto outro) para rodar cerca de 200 testes.

PS. Não tenho certeza sobre nossa configuração, mas reiniciar um pipeline jenkins a partir de um determinado estágio deve ser possível

Alternativa também discutida na reunião: Usando ctest --rerun-failed

Obrigado por investigar isso!

Mas se o problema realmente for uma carga elevada do servidor, isso não ajudará muito. Em vez disso, podemos tentar ctest --test-load.

@ingwinlu trabalhou muito nessa direção. Nossos servidores têm o maior rendimento com alta carga. Ou seja, desaceleraríamos nossos testes com essas opções.

IMO ainda a melhor opção seria desabilitar os testes e criar um pequeno trabalho de compilação que apenas instala o

Os casos de teste modulares são muito difíceis de alcançar e manter. @ingwinlu trabalhou muito nisso. Acho que não podemos nos esforçar novamente apenas para alguns testes não confiáveis.

PS. Não tenho certeza sobre nossa configuração, mas reiniciar um pipeline jenkins a partir de um determinado estágio deve ser possível

Isso seria bom. Mas não vejo o botão reiniciar em nossa GUI. Precisamos de outro plugin ou de uma versão mais recente? @ingwinlu tentou adicionar "jenkins build * please" para todas as etapas do pipeline, mas não funcionou.

Parece que ainda temos falhas (ver dbus # 2532)

Que tal excluir os casos de teste dbus para as compilações do Mac?

Parece que ainda temos falhas (ver dbus # 2532)

Sim nós fazemos.

gcc --version

Configured with: --prefix=/Applications/Xcode-10.2.1.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode-10.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1

Apple LLVM version 10.0.1 (clang-1001.0.46.4)

Target: x86_64-apple-darwin18.5.0

Thread model: posix

InstalledDir: /Applications/Xcode-10.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

(...)

DBUSRECV TESTS

==============

testing prerequisites

detecting available bus types - please ignore single error messages prefixed with "connect:"

connect: Failed to open connection to system message bus: Failed to connect to socket /usr/local/var/run/dbus/system_bus_socket: No such file or directory

test commit

test adding keys

../src/plugins/dbusrecv/testmod_dbusrecv.c:228: error in test_keyAdded: string "system/tests/testmod_dbusrecv/added" is not equal to "user/tests/foo/bar"

    compared: expectedKeyName and keyName (test_callbackKey)

test adding keys

testmod_dbusrecv Results: 34 Tests done — 1 error.

Você conseguiu reproduzi-lo localmente?

Ainda não sabemos por que esse problema ocorre esporadicamente. Se você tiver alguma contribuição, seria ótimo.

Talvez possamos simplesmente excluir os testes dos trabalhos de construção problemáticos? Ou os casos de teste dbus * falham em todos os trabalhos de construção em que são executados?

Você conseguiu reproduzi-lo localmente?

Infelizmente não. Estou no Ubuntu.

Talvez possamos simplesmente excluir os testes dos trabalhos de construção problemáticos? Ou os casos de teste dbus * falham em todos os trabalhos de construção em que são executados?

Acabei de reiniciar o trabalho de construção para ver se isso acontece novamente.

Por favor, reatribua-me se necessário.

Agora implementei a nova tentativa automática do ctest em # 3224. Se você ainda tiver falhas temporárias dos conjuntos de teste , reabra o problema. (Podemos aumentar o número de tentativas.)

Para outras falhas do Jenkins / Docker, precisamos encontrar outras soluções, mas primeiro finalmente precisamos fazer a migração. Portanto, continue reiniciando o trabalho nesses casos.