Libelektra: Coisas do servidor de compilação

@ markus2330

Acabei de enviar algumas correções relacionadas ao sistema de compilação. Mas você também precisa consertar alguns pacotes em sua máquina estável com debian:

• Instale o qtdeclarative5-dev a partir do wheezy-backports (você pode remover /opt/Qt5.3.0 depois)
• Instale o java8 como pacote:
  
  
  
  • Use este método: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • Vamos cmake realmente encontrar jdk8: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • kill + reinicie o processo java local jenkins. Caso contrário, todas as compilações falharão
  
  
  • Opcional: remova jdk7
  
  

Parece bom, obrigado por corrigir esses problemas.

Eu também fiz essas etapas no agente estável do debian.

Para outras máquinas, a instalação do qtdeclarative5-dev não foi possível, porque está em conflito com o qdbus, que é necessário para o kde4. Então, restaurei o script anterior configure-debian-wheezy como configure-debian-wheezy-local.

Também adicionei as etapas de instalação que você mencionou como notas no README.md porque podem ser do interesse de outras pessoas.

Obrigado por atualizar os agentes!

Coisas que faltam no estável

1.) látex (+ acho que o texlive-latex-recommended é necessário também)
consulte http://build.libelektra.org : 8080 / job / elektra-doc / 495 / console

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) Você pode instalar o clang (para elektra-clang, o clang de chiado não funciona)?
3.) Você pode instalar o mingw + wine para elektra-gcc-configure-mingw?

apt install --no-install-recommends doxygen-latex + clang + mingw feito

Por que você precisa de vinho?

A propósito, você deve alterar i586-mingw32msvc-X para i686-w64-mingw32-X em Toolchain-mingw32.cmake . No momento, isso não funcionará na instável.

Obrigado por docu!

o wine é necessário para executar os binários do Windows compilados (por exemplo, exporterrors.exe)

Acho que você instalou o mingw que constrói para w64. No pacote mingw32, ainda existe um /usr/bin/i586-mingw32msvc-c++ .

Um novo arquivo de conjunto de ferramentas para w64 é, no entanto, apreciado.

Eu instalei gcc-mingw-w64-i686 que é a compilação x64 do mingw com i686 como destino.
O pacote mingw32-binutils está obsoleto e não está mais disponível na instável.

Vinho instalado em ambos os recipientes.

Na verdade, a construção do mingw é estável, então isso não deve ser um problema.

MinGW-w64 é um fork do mingw e é um alvo bem diferente. Ninguém testou até agora.

obrigado por instalar o vinho

Mingw-w64 parece superior. Talvez seja hora de seguir em frente :-)

Contribuições bem-vindas;) Não tenho nenhuma máquina para testá-lo.

Receio que tenha escolhido o vinho errado, deve ser apt-get install wine32

consulte também http://build.libelektra.org : 8080 / job / elektra-gcc-configure-mingw / 218 / console

Não.

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

ok, dpkg --add-architecture i386 resolverá isso. Mas você não pode simplesmente fixar o trabalho mingw / wine em sua máquina de construção? A configuração do mingw é bastante especial.

Edit: Vou ver se consigo construir o elektra com mingw-w64 para que não precise instalar toneladas de libs i686.

O problema é que não tenho uma máquina jessie sobressalente e o wheezy mingw não conhece C ++ 11.

Consegui fazer o mingw-w64 funcionar. No entanto, std :: mutex não está disponível porque não há glibc no Windows e std :: mutex depende de pthreads. Alguma ideia?

Nossa, obrigado!

Isso leva a um erro de compilação? O std :: mutex não é usado para interno
funcionalidade, mas apenas em um arquivo de cabeçalho a ser incluído por um usuário. É usado
em casos de teste embora.

Uma solução para problemas de compilação é fornecer um std :: mutex no mingw
caso lançando erros de sistema em cada tentativa de bloquear / desbloquear. Na verdade, eu iria
espere que o pessoal do mingw pelo menos forneça algo assim (por exemplo, quando
alguma macro está definida, semelhante a -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads pode ser outra maneira. Mas isso é
provavelmente só será útil se todos os casos de teste, exceto aqueles envolvendo std :: mutex
já correu.

Basicamente, esta é apenas uma instância do C ++ 11 não disponível adequadamente.

status do mingw agora:

• adicionado dlfcn-win32 como projeto externo ao libloader. desta forma, o cmake faz check-out + compila a biblioteca como uma etapa adicional de construção. Estou ligando o arquivo para evitar dependências dll adicionais.
• adicionou dependência winsock2.h / ws2_32.dll a cpp11_benchmark_thread. exigido por gethostname () - chamar

No momento, estou construindo com -static-libgcc + -static-libstdc++ . Caso contrário, o vinho não conseguirá encontrar as dlls. Mutex adicional também não compila. Tentei mingw-std-threads. acabei de obter mais erros de compilação :-)

Se eu mudar de x86_64-w64-mingw32-X para x86_64-w64-mingw32-X-posix std :: mutex compila bem, porque o material de pthread está definido. No entanto, recebo uma dependência adicional para libwinpthread-1.dll, que o wine não consegue encontrar.

Mas acho que nossa melhor aposta é usar x86_64-w64-mingw32-X-posix .

Mais uma vez, estou surpreso que você tenha esse problema. Até agora éramos felizes quando obtivemos um libelektra.dll.

Não posso dizer nada sobre essa decisão x86_64-w64-mingw32-X-posix , porque não a uso e não conheço as implicações. Eu estou me perguntando se tal posix-lib ainda existe, eu pensei que a abordagem da camada posix é cygwin e não mingw.

Essa decisão tem efeito sobre o libelektra.dll? Se for apenas para os casos de teste, ninguém se importará (contanto que o servidor de compilação seja capaz de executá-lo). Se os casos de teste forem executados, será um grande benefício. (Veja # 270 onde os testes de unidade revelaram alguns bugs estranhos no Mac OS X)

Parece que libwinpthread-1.dll podem ser baixados, mas não sei se funcionam com vinho? Você também pode adicioná-lo como projeto externo, como feito com dlfcn-win32 (de modo que todas as dlls sejam tratadas da mesma maneira)? Caso contrário, se você precisar baixar 1 ou 3 dlls para os testes, pode não importar muito (novamente, eu não sou um usuário e não entendo o conceito de implantação, se houver, de dlls do Windows).

@beku O que você acha? Você tem tempo para testar nosso último 0.8.13 mingw-w64 build no Windows junto com oyranos?

Os testes geralmente estão habilitados para o trabalho de construção do mingw? Ontem todos eles foram desativados.

Sim, eles foram desativados. Mas alguns exemplos / benchmarks como cpp11_benchmark_thread foram desativados. Então eu pensei que você mudou e compilou mais do que era feito anteriormente.

Compilei todo o repositório com C ++ 11 habilitado. Nada mais.

Mas executáveis ​​como bin / basename.exe compilados com -posix funcionam bem, desde que você copie as dlls necessárias para o diretório bin (obrigado, Windows, por não ter RPATH). Não encontrei uma maneira de a) deixar o cmake localizar o diretório dll + b) apontar o wine para o diretório dll.
Achei que a vinculação estática funcionaria, mas a compilação falha com símbolos duplicados durante a vinculação da dll elektra. Porque a dll já tem os símbolos incluídos.

@ markus2330 Consegui fazer o elektra compilar com mingw + rodando com wine sem copiar nenhum dll. O truque é sempre habilitar links estáticos para objetos executáveis ​​E compartilhados ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ").

Para contornar símbolos duplicados, adicionei scripts de versão para libelektra e libelektratools. Dessa forma, apenas nossos símbolos são exportados.

Isso funciona muito bem. por exemplo

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

Até bin / cpp11_benchmark_thread.exe funciona.

Outras coisas simplesmente travam:

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

No momento, simplesmente adicionei o material do script de versão sem pensar em outros compiladores. Devo continuar meu trabalho ou não estou interessado?

trava em src / plugins / wresolver / wresolver.c porque pk-> nome do arquivo é NULL

pk é do tipo resolverHandles.user

Tentei dar uma olhada no plug-in, mas não consigo entender o loop for em elektraWresolverOpen . O loop chama elektraWresolveFileName -> elektraResolve{Spec,Dir,User,System} que todos malloc resolverHandle->filename e portanto vazam memória.

Obrigado por apontar isso! O código está obviamente quebrado desde a introdução em c87ae8e87a716b02b2c7ed790ad56a89d95547a9
Durante o loop apenas e sempre o identificador do sistema foi inicializado. Isso levava a travamentos quando outro namespace era usado.

Eu consertei em
edb4d50856bb5331749220de5a83fa2062624a9d

Sobre continuar o trabalho: por um lado, seria bom se o material compilado também rodasse. Por outro lado, o lançamento deve acontecer neste fim de semana, então uma solicitação de pull seria importante em breve (deve haver pelo menos uma chance de um curto círculo de feedback, por exemplo, o que os scripts de versão realmente fazem)

Mas imho, é o suficiente se apenas uma variante (a compilação estática) funcionar. Ótimo ver a ferramenta kdb rodando!

Onde posso encontrar edb4d50856bb5331749220de5a83fa2062624a9d?

edb4d50856bb5331749220de5a83fa2062624a9d foi enviado um pouco mais tarde.

Quais versões do gcc estão instaladas no debian-unstable-mm?

http://build.libelektra.org : 8080 / job / elektra-multiconfig-gcc-unstable / build_type = Release, gcc_version = 5.2, plugins = ALL / 56 / console

diz que não há gcc-5.2

Você pode instalar o máximo de compiladores possível, por favor?

Em algum problema ou RP, eu disse que removi todos os compiladores, exceto o mais recente.
Editar: gcc 4.9 no estável, 4.9 + 5.x (padrão) no instável

Faça esse tipo de teste (acho-os altamente desnecessários de qualquer maneira) em seus próprios contêineres. O meu não vai ficar para sempre de qualquer maneira.

Eu não li isso Eles têm talvez 50 MB cada. Você poderia instalá-los novamente e responder à primeira pergunta?

Talvez eu tenha te contado em nossa reunião. Mas eu definitivamente te disse.

debian-unstable:~ # gcc -v 2>&1 | tail -n 1
gcc version 5.2.1 20150903 (Debian 5.2.1-16)

O binário específico da versão é chamado gcc-5. Não há mais pacote separado para versões secundárias. Portanto, seu multiconfig-gcc com esse nível de detalhe é meio obsoleto. Eu recomendo remover o gcc 4.7 e substituir gcc-5.2 por gcc-5 e pronto.

O único compilador adicional disponível que não instalei é o gcc-4.8. E o gcc-4.8 já foi marcado para remoção.

Obrigado pela informação! Parece que os dias de glória de muitos compiladores disponíveis acabaram.

Eu consertei multiconfig-unstable.

Vou encerrar por enquanto, obrigado pela excelente configuração do agente.

Olá, jessie (estável) precisa de mais alguns pacotes. Você poderia instalar:

• [] fakeroot
• [] gpg (+ criar chave para Autobuilder [email protected])
• [] reprepro (talvez já instalado, o script não foi tão longe)

fakeroot instalado, gpg + repropro já está instalado.
Você pode me enviar sua chave gpg já existente? Portanto, ambas as máquinas de construção têm o mesmo

Não há problema em ter chaves gpg diferentes. Não tenho certeza se a configuração atual os usa, então primeiro espere se http://build.libelektra.org : 8080 / job / elektra-git-buildpackage-jessie / 2 / falhar.

• debhelper + libsystemd-journal-dev instalado
• python-dev é uma dependência errada. deve ser python2.7-dev ou python3-dev ou ambos
• por que precisamos de suporte a python?

Obrigado pela instalação!

python-dev está disponível para Jessie e python-support também. Por favor, instale-os.

Eu testei localmente, quando esses pacotes são instalados, ele constrói para jessie.

Claro, está disponível, mas é uma dependência errada. python-dev depende de python2.7-dev que _não_ é suficiente. Em vez disso, python2.7-dev + python3-dev é necessário.

o suporte a python não é necessário de forma alguma imho.

Não sei por que as dependências foram escolhidas dessa forma, a maioria do empacotamento foi feito por @iandonnelly durante o gsoc.

Sim, os pacotes também devem ser atualizados para construir ligações python3. Atualmente, simplesmente não é feito. No entanto, você pode instalar o python3-dev, para que a compilação não seja interrompida (quando ligações + plug-ins python3 são adicionados ao pacote debian).

Isso não significa que eles estão corretos :-) - Eu tenho quase certeza sobre os deps python-dev.
Você pode substituí-los e remover o dep python-support?

python3-dev e python2.7-dev já estão instalados. Caso contrário, nenhuma ligação seria criada.

Por falar nisso. o pacote debian oficial de @pinotree constrói somente python3. Seria uma perda de tempo consertar o que está em nosso branch "debian", o trabalho do @pinotree é superior de qualquer maneira.

Quando eu encontrar tempo, irei atualizar nosso branch "debian" para o que @pinotree fez no pacote oficial. Ele já nos permitiu fazer isso. Vou esperar a atualização qt-gui, atualmente não há pressa para mudar. E ter suporte para python2 seria importante para uma instalação (onde cheetah é usado, o que não funcionará com python3).

Eu nunca disse que vou remover os pacotes python2. Tudo o que estou dizendo é que python-dev é uma dependência imprecisa. Exigimos versões explícitas. Portanto, pythonX-dev é o dep correto a ser usado.

Esperançosamente, Pinotree resolveu a dependência corretamente.

A propósito, a chita está morta. Não use isso.

Ok, substituiu. Reverta b7c266b36b0ab0fad9120e67a457b580c7c44690 e instale o suporte a python se for necessário.

Tenho certeza de que pinotree fez isso corretamente;)

E diz: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org : 8080 / job / elektra-git-buildpackage-jessie / 3 / console

instalado

python-dev é uma dependência errada. deve ser python2.7-dev ou python3-dev ou ambos

• python-dev instala o pacote de desenvolvimento para a versão padrão do Python 2; desde Wheezy, este é o Python 2.7
• python3-dev instala o pacote de desenvolvimento para a versão padrão do Python 3; Python 3.2 em Wheezy, 3.4 em Jessie e até agora ainda 3.4 em Stretch (acho que em breve será 3.5)

Então, se você quiser construir contra a versão padrão do Python 2/3, use respectivamente python-dev / python3-dev , não as versões pythonX.Y-dev (que você precisa usar quando explicitamente deseja uma versão precisa do Python instalada, mesmo que não seja a única instalada no sistema, e não a padrão). Usar qualquer um é o que eu recomendo.

de python-dev descrição:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

De acordo com este texto, o python-dev pode certamente depender do python3 em breve

Mais ainda: Nunca haverá outra versão do python2. Portanto, o python2.7-dev será o último pacote python2 dev de todos os tempos.

Dependendo do python3-dev é o que eu disse.

Agora só falta a chave:

gpg: new configuration file `/home/jenkins/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/jenkins/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/jenkins/.gnupg/secring.gpg' created
gpg: keyring `/home/jenkins/.gnupg/pubring.gpg' created
gpg: skipped "Autobuilder <[email protected]>": secret key not available
gpg: /tmp/debsign.DlSdnFtB/elektra_0.8.13-1.41.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/08C91995 2015-09-30
      Key fingerprint = BA4C 688E 9071 FD3F 57ED  E9D6 D0A9 EDB9 08C9 1995
uid                  Autobuilder <[email protected]>
sub   2048R/E69F110A 2015-09-30

feito

Obrigado!

Exporte / home / jenkins / repository via http.

cannot access /home/jenkins/repository: No such file or directory ?

→ http://194.117.254.29/elektra-stable/

@manuelm Você poderia instalar ronn nos agentes? (necessário para gerar páginas de manual)

apt-get install ruby-ronn

feito

Obrigado, os pacotes jessie são compilados novamente e as páginas de manual agora estão incluídas!

Por favor, instale o musl, ou seja

apt-get install musl musl-dev musl-tools

Obrigado!

musl instalado e agends atualizado

Duas coisas importantes sobre o servidor de compilação:

1. Não crie novos trabalhos vazios, mas sim duplique, eles têm as configurações corretas (exceto o que está mencionado no número 2.).
2. Devemos usar clones de referência (em / home / jenkins / libelektra) ou preferir clones superficiais para cada trabalho de construção (atualmente feito apenas para alguns, por exemplo, elektra-clang). Atualmente o tráfego é> 300 MB em commits por causa de muitos reclones desnecessários.

@mpranj Seria ótimo se você pudesse corrigir 2.

@ markus2330 apenas para ter certeza: devo aplicar o mesmo comportamento de clone a todos os jobs de construção como em elektra-clang ?

Clones rasos aplicados a todos os trabalhos de construção, exceto :

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-wheezy
• [] elektra-multiconfig-gcc-stable
• [] elektra-multiconfig-gcc-unstable
• [] elektra-source-package-test

Esses trabalhos são registrados em algum subdiretório. Não tinha certeza do que você queria lá, então vou deixá-los como estão por enquanto.

Obrigado! Sim, eles precisam de histórico completo e branches, clones superficiais não fazem sentido, mas o repositório de clones de referência seria útil.

Jenkins foi atualizado para 1.651.2. Além disso, todos os plug-ins foram atualizados.

Vou manter o problema aberto para os repositórios de clones de referência. Devemos também ter "tarefas cron" que atualizam os repositórios de tempos em tempos, de preferência usando o próprio jenkins.

Jenkins parou de construir alguns empregos (aparentemente desde a atualização). Falha com
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Obrigado pela informação. Tento fazer o downgrade do construtor de solicitações do github de 1.31 para 1.14.

Agora parece travado ao definir o status de compilação para o commit do Github. Ele avisa que isso está obsoleto na configuração.

Eu também tentei fazer o downgrade de cada plugin com *git* em seu nome, mas ainda havia erros (erro estranho relacionado ao plugin do Mailer, o downgrade do plugin do Mailer não ajudou). Então, eu atualizei tudo para as versões recentes novamente. O problema parece ser um problema conhecido no upstream:

https://github.com/janinko/ghprb/issues/347

Eu espero que eles consertem isso logo.

Outra pergunta: alguém sabe como executar vários trabalhos para cada RP? (Eu gostaria de executar elektra-mergerequests-stable e elektra-mergerequests-unstable)

O trabalho elektra-test-bindings está funcionando bem com compilações parametrizadas (como também descrito no tíquete upstream). Não poderíamos simplesmente mudá-lo para compilações parametrizadas? O bug foi relatado upstream por um tempo, não o vejo corrigido em breve.

Boa ideia, poderíamos mudar todos os trabalhos de RP para compilações parametrizadas; na verdade, isso só tem vantagens. Ele nos permite executar os trabalhos manualmente especificando um branch também. E também pode ser usado para trabalhos regulares de construção.

Idealmente, cada trabalho também poderia ser executado por PRs do github. (Exceto aqueles especificamente para tarefas não relacionadas a RP que atualizam a documentação ou cobertura do ramo mestre)

Uma desvantagem da configuração do elektra-test-bindings é que ela só faz polling e leva muito tempo até começar a compilar (até 5 minutos). Não desejo ativar "Usar github hooks para ativação de build", no entanto, para não interromper o trabalho de build.

Por falar nisso. tem certeza de que a opção "clone raso" é adequada para os trabalhos do construtor github pullrequest?

Eu me pergunto como o github escolhe o trabalho de construção que usa para novos PRs. Por que os elektra-test-bindings e elektra-ini-mergerequests nunca foram selecionados para um novo PR? Por que às vezes é elektra-mergerequests-unstable e às vezes elektra-mergerequests (-stable)?

@manuelm você tem alguma ideia?

Por falar nisso. de alguma forma, a comunicação de trabalhos de construção concluídos e github é severamente prejudicada (mesmo para ligações de teste de elektra). Agora diz em quase todos os builds "Algumas verificações ainda não foram concluídas".

Uma desvantagem da configuração do elektra-test-bindings é que ela só faz polling e leva muito tempo até começar a compilar (até 5 minutos).

E isso é um problema porque? O teste leva mais de 5 minutos de qualquer maneira.

Por que os elektra-test-bindings e elektra-ini-mergerequests nunca foram selecionados para um novo PR?

Por que deveria? elektra-test-bindings é acionado apenas pela "frase de acionamento". Não faço ideia do que é elektra-ini-mergerequests .

Por que às vezes é elektra-mergerequests-instável e às vezes elektra-mergerequests-estável?

O -stable / -unstable é novo? Não tenho certeza se acionar vários empregos por novo PR é possível. Eu faria subjobs.

A propósito, eu já disse isso algumas vezes, mas acho que a quantidade de jobs está ficando ridícula e um sinal de uma configuração bagunçada. Mas criticar é sempre mais fácil do que resolver algo.

Os 5 minutos são um problema quando você deseja depurar o servidor de compilação. E ainda espero que façamos um primeiro teste rápido em algum momento, levando cerca de 5 minutos.

Ahh, ok, perdi a opção "Usar apenas frase de acionamento para acionamento de build". A configuração do criador de solicitações do github é realmente uma bagunça.

Alguém falou sobre os projetos do github em que há vários trabalhos em execução para cada RP. (Exibido individualmente)

O que é um subjob? Você quer dizer multijob ?

Alguém falou sobre os projetos do github em que há vários trabalhos em execução para cada RP. (Exibido individualmente)

Você terá que adicionar dois serviços no github.

O que é um subjob? Você quer dizer multijob?

Sim, multijob.

btw, que tal https://docs.travis-ci.com/ ? Travis tem suporte para OSX.

Eu sei que ele não substituirá Jenkins, mas pode substituir o PR / em cada build de commit. Jenkins ainda pode fazer o teste de compilador múltiplo / etc.
Edit: Travis ainda tem gcc + clang.

Concordo, seria interessante usar a energia / eletricidade da CPU de graça, já que a elektra é um código aberto.

É provável que a conexão entre o github e o jenkins seja de 1: 1. No serviço github, entrei em http://build.libelektra.org : 8080 / github-webhook / e não encontrei uma maneira de criar outra URL em jenkins. (Eu só encontrei uma maneira de especificar uma substituição, mas isso não criou uma nova URL).

Em https://github.com/janinko/ghprb/issues/142, eles discutem que deve "simplesmente funcionar"? (Sem adicionar vários serviços)

O problema sha1, no entanto, deve ser resolvido agora. Ele foi quebrado porque o Jenkins introduziu uma nova medida de segurança que remove variáveis ​​de ambiente desconhecidas. Eu fixa-lo como -Dhudson.model.ParametersAction.safeParameters sugeridas (adicionado = ghprbActualCommit, ghprbActualCommitAuthor, ghprbActualCommitAuthorEmail, ghprbAuthorRepoGitUrl, ghprbCommentBody, ghprbCredentialsId, ghprbGhRepository, ghprbPullAuthorEmail, ghprbPullAuthorLogin, ghprbPullAuthorLoginMention, ghprbPullDescription, ghprbPullId, ghprbPullLink, ghprbPullLongDescription, ghprbPullTitle, ghprbSourceBranch, ghprbTargetBranch, ghprbTriggerAuthor, ghprbTriggerAuthorEmail, ghprbTriggerAuthorLogin, ghprbTriggerAuthorLoginMention, GIT_BRANCH, sha1 para / etc / default / jenkins).

Sobre o uso de servidores de compilação adicionais: Sim, vá em frente. Ele também resolve o problema de vários trabalhos de construção para um único PR;) Eu nunca usei travis-ci, então não posso dizer nada sobre isso. Dei permissão para que o travis tenha acesso ao ElektraInitiative.

Primeira construção do travis: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Acho que precisamos de algum arquivo yaml para que travis saiba o que fazer.

E descobri como fazer vários trabalhos da Jenkins por RP, um contexto diferente para cada trabalho de construção era necessário. Na próxima reunião, discutiremos o que o trabalho "rápido" e outros trabalhos de construção devem fazer.

Estou trabalhando em travis (ou verificando algumas coisas)

Divirta-se. Travis também adicionou um serviço github, então acho que um PR será construído com travis também.

Eu já estou xingando alto

- NÃO foi possível encontrar JNI (ausente: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
- Excluir Plugin jni porque jni não foi encontrado

Não consigo configurar o plugin java corretamente. No entanto, as ligações Java funcionam. No debian instável. Alguma ideia? Olhar para o módulo cmake não ajuda muito.

Editar: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h e /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h estão no lugar

Editar 2: Entendi. JAVA_HOME = / usr / lib / jvm / java-1.8.0-openjdk-amd64 / ....

https://travis-ci.org/manuelm/libelektra/builds/130638376

Debian instável construído dentro de um contêiner docker. Mas a construção leva séculos.
Alguma boa ideia?

o clang costuma ser mais rápido em relação ao tempo de compilação, mas acho que a instalação das dependências é o que leva muito tempo

Não existe uma imagem docker do debian mais minimalista do que a usada? Parece que muitos pacotes são instalados que não deveriam ser necessários.

@sirblackheart O que te faz pensar isso? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm provavelmente o dist-upgrade. muitos pacotes são atualizados e são específicos da área de trabalho, como o wayland

Não. A atualização dist é curta. talvez um minuto. cerca de 50% do tempo é gasto com a instalação dos build deps.

Estou enviando a imagem de compilação para hub.docker.com agora. Espero que isso acelere as coisas. Mas a imagem tem 1,9 gb

Tempo decorrido 14 min 8 seg

Não tenho certeza se podemos fazer muito melhor

como eu disse, o clang pode nos levar de 2 a 3 minutos. pelo menos serve para o projeto aseprite
https://travis-ci.org/aseprite/aseprite

Seria útil ter os dois compiladores de qualquer maneira.

Tive uma ideia enquanto preparava o material de trabalho: e se extrairmos os caminhos de todos os commits na solicitação de push e construirmos ligações / plug-ins apenas se eles forem afetados? por exemplo

• mudança em cmake / * aciona tudo (plugins + ligações)
• mudança em src / bindings / foo aciona binding foo
• mudança em src / plugins / foo triggers plugin foo
• mudança em tudo não compila plugins + ligações

Ainda temos o build diário / duas vezes por dia completo no Jenkins.

@manuelm boa ideia, @ tom-wa escreveria esse script, você pode criar um novo problema para isso?

@mpranj : Lembrete: adicione compilações do Mac OS X ao travis e adicione compilações do mingw ao PR. (* BSD parece exigir mais esforço)

@ markus2330 agora eu entendo a abordagem docker do @manuelm , travis não suportará o ubuntu 16.04 até o próximo ano, então o docker é necessário para obter todas as dependências que o ubuntu 14.04 não tem = swig3.0 libsystemd-devel.

Lamento não ter podido comparecer à reunião de hoje. No trabalho, ainda estamos preparando um grande lançamento de software hoje, então não posso deixar o escritório. Mas com um pequeno atraso posso responder aos e-mails.

Comecei a adicionar compilações do OS X para travis há 2 dias: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
O Build está aqui: https://travis-ci.org/manuelm/libelektra/builds/130898079
Abra as coisas aqui:

• [] cryto_openssl falha ao compilar
• [] testes de ligação falham
• [] sem java

Fico feliz se alguém assumir meu trabalho a partir daqui. Não tenho o OS X e esperar que o travis inspecione o sistema OSX é muito rápido.

re: docker: Sim, a versão padrão do travis para ubuntu não funciona bem. Até o cmake é muito antigo.
A obtenção da imagem carregada do docker leva apenas cerca de 3 minutos. E adicionar mais imagens é um acéfalo. Portanto, acho que é uma boa maneira de contornar quaisquer armadilhas que o ambiente travis linux padrão tem (ou pode ter após uma atualização).

Não descobri uma boa maneira de integrar as diferentes fases de construção e teste do libelektra (cmake + make + make test) com docker (build + run) + travis (before_install, before_script, script). Os contêineres do Docker saem após a conclusão do comando. Como os contêineres docker devem ser descartados, você não pode retomar depois disso. Portanto, seu estado de disco / compilação desaparece, a menos que você monte um diretório local no contêiner. Continuará a trabalhar no docker na próxima semana.

@manuelm Ótimo, você foi mais longe do que pensávamos. Mac OS X para PRs e por commit seria realmente ótimo. Muitas pessoas estão usando o Mac OS X agora e não quero interromper a compilação para eles novamente e novamente. Na reunião de hoje @mpranj disse que

Não, já que o arquivo travis ainda precisa ser modificado depois. Caso contrário, ele construirá apenas o OS X. Eu prefiro que @mpranj pegue meu arquivo travis e conserte os problemas restantes relacionados ao OSX. Em seguida, pegarei seu arquivo travis, converterei em uma compilação de matriz e integrarei as compilações linux / docker + # 730 (se disponível até então)

PS: faça o teste travis em um repositório com espaço de nome de usuário. Você fará muitos empurrões :-)

mingw64 baseia-se no PR adicionado, deve funcionar. Desculpe pelo atraso. Vou procurar travis hoje!

Existe uma desvantagem em permitir que os jobs de construção sejam acionados com uma frase em um PR (com o construtor de PR do Github)?

Eu gostaria de configurar os trabalhos de # 745 para que eu possa testar se o consertei, mas posso aplicá-lo à maioria / (todos) os trabalhos de construção.

EDIT: Prefiro não iniciar todos os trabalhos automaticamente, já temos alguns.

Acho uma boa ideia se pudermos configurar cada job para ser acionado com uma frase. Eu acho que há uma pequena desvantagem (pelo menos para elektra-test-bindings): você deve inserir para qual branch deseja construir e não pode simplesmente pressionar "build job now". Seria ótimo se você encontrasse uma solução para isso.

E você tem razão quanto ao fato de que devemos reduzir os trabalhos automáticos.

Na verdade, existe uma solução muito simples. Estamos usando a variável (env) sha1 para construir PRs. Construções parametrizadas solicitam o valor, esteja um valor padrão definido ou não.

Solução: defina a variável env sha1 para master (na própria configuração do jenkins) e desative as compilações parametrizadas. Se não houver objeção em definir a variável, isso resolveria exatamente o que você mencionou acima @ markus2330.

Eu já o configurei, então você pode clicar no botão de compilação, por exemplo, elektra-mergerequests e ele começará a compilar o mestre.

Sim, é uma solução muito boa, gosto dela. Isso também nos permitiria construir um branch de lançamento com um único switch (se precisarmos de um no futuro). Até então, "master" é sempre a escolha correta se não for executado de dentro de um PR.

Acho que também resolveria o problema da variável de ambiente filtrado, que tínhamos anteriormente.

Então, também podemos pensar em reduzir os trabalhos de construção (sem duplicação para os trabalhos bulid -mergerequest) e um novo esquema de nomenclatura consistente. (Sugestões podem ser feitas aqui.) Pode haver um problema em aberto: Atualmente construímos a cobertura, docu, .. para ambos PRs e master e os copiamos para locais separados. Se fundirmos os trabalhos de construção, precisamos de uma maneira de distinguir dentro do mestre de trabalho / trabalhos de PR para copiar a cobertura, docu para locais diferentes.

Estou quase terminando de aplicar isso a todos os trabalhos (mas o servidor _apenas_ ficou muito lento).
Não se aplica a trabalhos que criam caracteres curinga ** (doc e alguns outros, mas muito poucos)

Você sempre pode interromper a criação de trabalhos quando quiser trabalhar neles, se reiniciá-los mais tarde (exceto no tempo de lançamento). Normalmente, o próprio Jenkins é o motivo da desaceleração da máquina. No momento, um rsync de um backup pode ser o problema, mas é urgente.

Sim, sem problemas, deveria ser feito, mas farei algumas últimas verificações.

A notícia @ ElektraInitiative / elektradevelopers:

• como mencionado, quase _tudo_ pode ser construído agora a partir de PRs e / ou apertando apenas o botão de construção
• as frases de gatilho são sempre o nome do trabalho sem o prefixo elektra- . (por exemplo, elektra-clang: jenkins build clang, por favor) Eu não alterei jenkins build please e outras frases antigas por motivos de legado
• a mensagem de status de compilação do github é sempre exatamente o nome do trabalho de compilação

Obrigado, muito bem! Atualize doc / GIT.md para que todos saibam quais frases estão funcionando agora.

(Espero que @mention funcione apenas para uma única mensagem e nem todos leiam todas as mensagens que escrevemos aqui)

A compilação do Mac OS X para xcode 6.1 parece estar corrompida:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

Eu acionei uma reconstrução para aquele, mas me parece uma falha temporária de travis.

Você pode documentar como reativar uma construção para um PR? Eu não sabia que isso era possível.

Diretamente em travis-ci.org, usando o link acima:

Duvido que seja digno de documento, mas posso fazê-lo no entanto.
A compilação ainda não está funcionando apenas por causa do checkout do git. Não acho que seja nossa culpa.

Ah. Acho que você o mesclou antes que a construção fosse acionada / iniciada em primeiro lugar.
Quando reconstruo outros PRs anteriormente bem-sucedidos, ele também é quebrado.

Este é mais um problema de travis do que qualquer outra coisa.

Ok, obrigado por investigar.

@manuelm debian-stable-mm parece estar inacessível (tanto para jenkins quanto para mim da rede TU). Você poderia, por favor, investigar?

Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Removed slice User and Session Slice.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Graphical Interface.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Multi-User System.
etc..

Parece que alguém parou o contêiner. Eu comecei de novo.

A propósito, a partir de amanhã de manhã estarei longe de casa até 1º de agosto. Ainda estou disponível por e-mail, mas espero um pequeno atraso.

Obrigado pela solução rápida! Então, suponho que você também não estará aqui nas próximas reuniões.

Sim

Alguns trabalhos apresentam o erro:

Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.

por exemplo, http://community.markus-raab.org : 8080 / job / elektra-icheck / lastFailedBuild / console http://community.markus-raab.org : 8080 / job / elektra-doc / lastFailedBuild / console

Pode ser causado por uma atualização do Jenkins ou @KurtMi criando o kdb_import_man ?

Nota para mim mesmo: o cppcms precisa ser instalado.

Desculpem o ramo, fiz um RP direto na página do github.

É mais fácil criar PRs dessa maneira? O github não oferece a exclusão do branch depois que ele foi mesclado?

A mudança foi tão mínima que fiquei preguiçoso. Para correções muito pequenas, sim, mas aparentemente o branch não será excluído depois. Eu não vi nenhum branch de exclusão após a fusão.

Acho que a construção instável está quebrada:

Cloning the remote Git repository
Cloning repository git://github.com/ElektraInitiative/libelektra.git
 > git init /home/jenkins/workspace/workspace/elektra-mergerequests-unstable # timeout=10
Fetching upstream changes from git://github.com/ElektraInitiative/libelektra.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: The remote end hung up unexpectedly

Log completo

A instabilidade do

 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/* --depth=1
Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.
org.eclipse.jgit.errors.RevWalkException: Walk failure.

@mpranj Talvez devêssemos adicionar mais scripts no código-fonte, isso permitiria atualizações mais fáceis para cada trabalho de construção. Em # 806 encontramos outro bug com espaços no diretório de construção, então devemos adicionar globalmente (para cada trabalho de construção) adicionar espaços no diretório de construção. Eu preferiria se pudéssemos adicionar um script jenkins-setup que exporta algumas variáveis ​​úteis (como export HOME="$WORKSPACE/user space ) e faz

mkdir "build space"
cd "build space"

Além disso, devemos criar build-jobs que atualizam um repo global. Tarefas individuais, veja acima.

O repo global definitivamente pode ajudar a reduzir a largura de banda. Construir scripts no código-fonte também pode ser uma boa ideia, pelo menos eles seriam rastreados pelo git.

Não sou fã de espaços em caminhos, mas com certeza.

compilação rápida no passwd quebrado?

O trabalho de compilação rápida é irritante, tento remover o kdberrors.h em todas as compilações e ver se funciona melhor. A longo prazo, a proposta de @manuelm em # 730 é a melhor solução: devemos simplesmente verificar como a fonte foi atualizada e, com base nisso, tomar as medidas apropriadas.

Acho que o # 894 também corrige a compilação rápida. Vou comentar a linha removendo kdberrors.h.

Alguns jobs estão corrompidos, por exemplo, o job doc html.

@mpranj Você tem tempo para olhar para isso?

@ markus2330 Concluído. As falhas de compilação restantes não parecem relacionadas ao sistema de compilação.

@mpranj Obrigado! O que você fez para consertar? Acho que seria útil se coletarmos aqui também soluções para criar problemas de servidor.

Mudei em "Gerenciamento de código-fonte"> "Git"
"Branch Specifier" value "**" to "$ {sha1}"

Isso é o que usamos nos outros empregos também. Isso permite acionar o build por botão (o padrão do branch é master) ou pelo github PR builder (sha1 de commit).

Lembro-me de definir a variável ENV "sha1" para "master" uma vez. Parece que está faltando agora, mas os trabalhos funcionam bem, então vamos ignorar isso.

Acho que poderíamos acelerar as compilações muito mais usando Bibliotecas de objetos com mais frequência. Muitos arquivos de objeto são compilados várias vezes. Nós apenas teríamos que ter certeza de que os sinalizadores de compilação são os mesmos para todos os lugares em que usamos as bibliotecas de objetos, mas acho que isso deve ser facilmente possível.

Um exemplo onde pode fazer uma grande diferença é o KDB na minha opinião.

@Namoshek Por favor, poste apenas coisas do _server_ de compilação aqui, não sobre o sistema de compilação em geral. Bibliotecas de objetos já são usadas para plug-ins, mas para diferentes variantes, são necessárias diferentes bibliotecas de objetos (por causa de diferentes sinalizadores de compilador). Mas, por favor, reporte sugestões concretas como um problema separado (você quer dizer ferramentas kdb?).

Jenkins foi atualizado para 2.7, todos os plug-ins atualizados, plug-ins recomendados foram adicionados:

• Pipeline (a instalação parece ter falhado?)
• Plug-in de pasta de organização do GitHub

e alguns plug-ins desinstalados:

• API Branch
• CVS / SVN (parece não ser mais essencial)

Além disso, o ruby-dev foi instalado em todos os agentes.

Eu atualizei os "Problemas atuais" no post superior. Seria importante que o Elektra também compilasse sem nenhuma dependência instalada, portanto, devemos verificar isso com agentes de servidor de compilação que não têm nenhuma dependência instalada (exceto cmake e build-essential). Os agentes de construção do FreeBSD e do OpenBSD, no entanto, também são importantes;)

@mpranj Você tem alguma idéia do que há de errado com elektra-multiconfig-gcc47-cmake-options? Eles têm erros "fatal: a referência não é uma árvore:" O trabalho deles tem "sha1" em sua configuração?

Fiz o multiconfig independente de compiladores concretos (existem outros trabalhos de construção suficientes para compiladores específicos), portanto, eles devem ser capazes de rodar em qualquer agente.

@ markus2330 Não

• acionou manualmente uma compilação do mestre
• acionou uma compilação do github

Ambas as compilações foram capazes de verificar a árvore e começar a construir.
Então: eu não consigo reproduzi-lo.

Uma ideia: travis teve problemas quando havia um PR e você mesclou antes que travis pudesse fazer o clone. Talvez algo semelhante tenha acontecido com elektra-multiconfig-gcc47-cmake-options pois uma compilação leva cerca de 3 horas.

Enviar artefatos para doc.libelektra.org funciona novamente, Jenkins e Plug-ins foram atualizados.

Atualizei a nova URL do servidor de compilação https://build.libelektra.org nos Webhooks do github. Então, esperançosamente, os próximos PRs serão construídos novamente.

A casa de Jenkins está quase cheia. Também parece não estar construindo PRs.

A casa de Jenkins está quase cheia.

Obrigado, redimensionei.

Também parece não estar construindo PRs.

Você tem alguma ideia do que pode estar errado aqui? O acionamento manual parece funcionar?

Publicando docu em doc.libelektra. org: 12025 falhou para as compilações. Eu reiniciei o servidor ssh (no agente build-homepage) e parece funcionar novamente.

O vserver para * .libelektra.org parece não estar acessível. Eu relatei no hetzner.

O motivo para encerrar a conexão de rede do contêiner é que libelektra.org está comprometido. Consulte # 1505 para obter mais informações.

Seria ótimo se pudéssemos adicionar um pacote git-build para stretch, há mais e mais lugares surgindo onde precisaríamos de pacotes debian construídos para stretch.

@BernhardDenner você deu uma olhada no post principal? Existe algo que você pode fazer facilmente? Existe algo que @mpranj precisa considerar ao melhorar a construção de trabalhos de servidor no futuro?

Conforme solicitado por @sanssecours , @KurtMi

jenkins build gcc-configure-debian-optimizations por favor

@KurtMi Se você precisar de mudanças no que o trabalho de construção faz, simplesmente modifique os scripts / configure-debian-optimizations

@sanssecours agora também tem acesso ao servidor de compilação.

Por falar nisso. você pode cancelar trabalhos se eles forem substituídos por outros trabalhos de qualquer maneira (atualmente há uma carga pesada). Apenas tome cuidado para não abortar trabalhos para PRs ativos, caso contrário, o PR não ficará verde. (A menos que você os reinicie com a frase "jenkins build ... please".)

@sanssecours Jenkins foi reiniciado (a segunda vez). Você poderia documentar aqui se instalar novos plug-ins. (As atualizações não precisam ser documentadas).

Os pedidos de reinicialização também podem ser feitos aqui.

Eu mudei o "período silencioso" de 2 para 5 para dar mais tempo para mesclar vários PRs e / ou enviar diferentes commits sem reconstruir repetidamente.

Além disso, abri a edição nº 1689 descrevendo tempos limite em compilações (não o adicionei aqui devido a longas mensagens de erro).

Também movi algumas tarefas obsoletas acima na nova seção "Problemas obsoletos / irrelevantes [motivo]:".

Eu atualizei os plug-ins no servidor de compilação. Esperançosamente, as atualizações corrigem os problemas que temos em PR # 1698 e PR # 1692.

@ markus2330 Você pode reiniciar o servidor de compilação?

Eu atualizei o Jenkins de 2.73.2 para 2.73.3 e reiniciei o Jenkins.

Esperançosamente, as atualizações corrigem os problemas que temos em PR # 1698 e PR # 1692.

Pode ser um problema geral não relacionado a esses dois PRs? Esperançosamente está consertado agora.

Parece que JENKINS_HOME está quase cheio 😢.

@ markus2330 👋 Você poderia, por favor

• limpe o diretório inicial ou diga-me como posso fazer isso,
• atualizar Jenkins e todos os plug-ins desatualizados?

Obrigado por me pingar!

Parece que um plugin tinha uma "vulnerabilidade de leitura de arquivo arbitrário", ou seja, o "Script Security Plugin 1.35".

Eu atualizei todos os plug-ins e também o jenkins de 2.73.3 para 2.89.1.

Além disso, redimensionei o disco de 20 GB para 50 GB.

Devemos reiniciar o servidor em breve, existem alguns processos não reiniciados que podem ser afetados por atualizações da biblioteca, que podem ser inseguros no momento (não relacionados ao jenkins, no entanto). @BernhardDenner Você pode reiniciar (e fazer as correções se algo não inicializar)?

Não hesite em relatar qualquer coisa que quebrei durante essas atualizações.

O servidor carregou 20 e quase não respondeu. Precisamos ter cuidado com "jenkins build all please" e, a longo prazo, devemos mover os agentes para longe do servidor principal.

Eu atualizei para o Jenkins 2.89.2 e reiniciei o servidor. Vou relatar quando tudo estiver funcionando novamente.

Parece que agora todos os agentes estão desconectados com o erro "A chave de host do servidor não foi aceita pelo retorno de chamada do verificador".

@BernhardDenner Eu vi que o puppet apply estava rodando. Você está trabalhando na configuração?

Tentei fazer o downgrade para 2.89.1 e 2.73.3 sem sucesso: a conexão com os agentes ainda não funciona.

Muito obrigado a @BernhardDenner que corrigiu o problema de ssh.

Devemos parar de atualizar o Jenkins sem ler as notas de lançamento, parece que mesmo as atualizações estáveis ​​quebram muitas coisas. (Isso não pode ser revertido por rebaixamento!)

Tenho que relatar um grande gargalo no servidor de compilação.
elektra-multiconfig-gcc47-cmake-options leva 14h e o
elektra-multiconfig-gcc-stable leva 4h.
Não tenho certeza se esse é um comportamento novo e estou ciente de que esses trabalhos não são um único trabalho de construção, mas esse gargalo não deve passar despercebido.

Obrigado por relatar. A ideia era distribuir subjobs desses jobs para o hardware ryzen, infelizmente ninguém teve tempo para a configuração. Se alguém estiver interessado, entre em contato comigo.

a7.complang.tuwien.ac.at (ryzen) parece ter travado. Eu relatei o problema. Esperamos que nosso administrador reinicie o computador na segunda-feira.

Desativei temporariamente o incremental (erro estranho, consulte # 1784), o administrador reiniciou o servidor ryzen e, em seguida, reiniciei o jenkins (porque o Jenkins não conseguiu se conectar ao ryzen e havia um grande acúmulo de compilações ryzen).

ryzen agora funciona novamente e constrói o backlog.

A ideia era distribuir subjobs dessas tarefas para o hardware ryzen

@ markus2330 Notei que existe uma opção chamada Run each configuration sequentially nas configurações da matriz de configuração do trabalho multiconfig. Talvez ele seja distribuído automaticamente se simplesmente desmarcarmos para que ele crie várias opções de configuração de uma vez, ou você já tentou fazer isso?

Não, eu não tentei, por favor, tente.

@ markus2330 julgando pela fila do servidor de compilação, isso parece funcionar, vou aplicá-lo ao gcc-stable adicionalmente depois que funcionou para gcc-stable-multiconfig

Percebi, no entanto, que o ryzen não parece lidar com esses trabalhos. Acho que isso ocorre porque ele está configurado para lidar apenas com trabalhos que correspondam a suas tags e as compilações multiconfig não parecem definir essas tags adequadamente à primeira vista. Portanto, devemos fazer ryzen executar tudo o que for possível ou definir mais tags nos trabalhos de construção. Parece que ryzen não lida com jobs que não tenham nenhuma tag definida.

vou aplicá-lo ao gcc-stable adicionalmente depois que funcionou para gcc-stable-multiconfig

Obrigado!

Percebi, no entanto, que o ryzen não parece lidar com esses trabalhos.

Não, não faz, mas já executa um monte de outras tarefas. Mas talvez possamos fazer v2 para fazer isso?

vou aplicá-lo ao gcc-stable adicionalmente

feito

Mas talvez possamos fazer v2 para fazer isso?

Eu configurei o v2 e agora só espero que o PR # 1806 seja mesclado para que eu possa permitir mais compilações do que uma. Achei que 8 jobs deveriam ser adequados para ele, já que é um 8-core, com -j 2 para utilizar o SMT também?

Para reiniciar o contêiner build-v2 no caso de v2 travar ou for reiniciado, basta digitar. Observe que isso só pode ser feito se o contêiner já tiver sido criado - siga doc / docker / jenkinsnode / README.md para obter essas instruções. Em seguida, use este comando para reiniciar depois que o contêiner foi criado, mas parou:

docker start build-v2

Além disso, para encaminhar a conexão ssh do novo nó de compilação da v2 via a7 para o mundo externo, configurei o seguinte túnel ssh na a7 (o contêiner docker mapeia sua porta ssh para 22222 na v2):

ssh -L 0.0.0.0:22222:localhost:22222 <username>@v2.complang.tuwien.ac.at

Além disso, a chave ssh pública do contêiner do docker muda em cada reconstrução de imagem e, portanto, também deve ser ajustada no servidor de construção. Isso não é necessário se o contêiner apenas for reiniciado. Para descobrir, digite o seguinte na v2:

sudo docker exec -it build-v2 bash
# now you should be on the docker machine
cat /etc/ssh/ssh_host_ecdsa_key.pub
> ecdsa-sha2-nistp256 <blablablalb> <root@6b906cc01f23>

Copie apenas as duas primeiras coisas, portanto, o algoritmo de chave e a própria chave, não copie essas informações do usuário no final para a configuração de ryzen-v2 em jenkins para a chave ssh!

v2 está fora do ar, informei o administrador. É muito estranho: a7 e v2 são ambos hardwares completamente novos e os incidentes são bastante frequentes.

v2 parece estar de volta e eu reiniciei o contêiner de compilação lá. Então, esperançosamente, temos compilações mais rápidas agora novamente. Além disso, adicionei elektra-haskell a "jenkins build all please", pois quero ter compilações de haskell estáveis ​​para meu verificador de tipos, então o teste é uma boa adição.

Além disso, quero deixar uma nota aqui que também queremos criar outro nó de compilação que cuide das compilações mm que agora parecem ser o novo gargalo na v2 também.

Por último, @ markus2330 acho que o verificador de bashism run point já está feito, pois este é um dos nossos testes usuais /testscr_check_bashisms.sh .

Todos os nós do rótulo debian-jessie-homepage||homepage e do agente de compilação debian-wheezy-mr estão atualmente offline. Reiniciar os agentes de construção não funciona. Seria muito bom se alguém com SSH ou acesso físico a esses nós pudesse examinar esse problema.

Eu reiniciei os vservers, mas reiniciar os agentes dentro de jenkins não funcionou com o erro "Nenhum fragmento válido foi incluído na solicitação". @BernhardDenner Você tem uma ideia?

Parece que a v2 também está inativa. Portanto, temos 3 agentes não funcionais 😢

v2 está de volta, mas eu me pergunto por que sempre vai para baixo? isso poderia estar relacionado ao nosso processo de construção?

Em relação à "migalha não válida", também vi isso quando tentei reiniciar o agente na v2, mas quando tentei novamente, funcionou.

v2 está de volta, mas eu me pergunto por que sempre vai para baixo? isso poderia estar relacionado ao nosso processo de construção?

Parece ser uma falha de kernel / hardware (nem mesmo o sysreq funciona quando o computador trava). Nosso uso pode desencadear o erro. O computador funcionou sem erros por vários meses e, como o usamos, já o travamos três vezes.

Eu atualizei o kernel e limpei o servidor X.

Em relação à "migalha não válida", também vi isso quando tentei reiniciar o agente na v2, mas quando tentei novamente, funcionou.

Obrigado! Agora eu era capaz de iniciar o agente da página inicial novamente.

Além disso, desativei o agente debian-jessie-minimal e seu trabalho de construção. Devemos criar contêineres docker para trabalhos mínimos, adicionei isso como tarefa.

Como ficamos surpresos ontem, o servidor da comunidade caiu porque travou e um cache ARP errado redirecionou nossos IPs para outros servidores. Depois de reiniciar, tudo funcionou novamente, mas a sincronização do raid ainda está em andamento. (Pode ser muito lento devido à carga elevada.)

O servidor da comunidade tem uma carga quase constante de 10. No momento, são 13h20 11,29 9,35. Realmente devemos reduzir os trabalhos em execução diretamente no servidor da comunidade e mover a carga para v1. Quaisquer voluntários?

Há uma atualização do Jenkins de 2.89.2 para 2.89.4. Infelizmente, não encontrei uma maneira fácil de ver o Changelog ( apt-get changelog falha porque é um pacote não oficial). Alguma razão para não fazer esta atualização?

O changelog upstream está em https://jenkins.io/changelog-stable/
Aparentemente, 2.89.4 contém correções de segurança.

Obrigado por consultar!

Eu atualizei para Jenkins 2.89.4 e tudo está funcionando novamente.

elektrahomepage não foi iniciado por padrão após as reinicializações, eu mudei isso (/ etc / vservers / elektrahomepage / apps / init / mark = default).

Eu também ativei o trabalho de compilação test-docker.

v2 está desativado, novamente: choro:

Mas pelo menos a7 parece estar estável agora.

Eu instalei o clang-format-5.0 no a7 e no nó stretch (debian-stretch-mr).

Para os próximos PRs, reformate de acordo com o clang-format-5.0.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ foi temporariamente desativado.

No momento, estamos investigando a v2. UEFI é de 6.6.17. Parece que os travamentos sempre aconteciam nos finais de semana, talvez haja uma carga maior nesse horário? Vou tentar replicar a configuração da v1 na v2.

v1 e v2 estão funcionando com o mesmo kernel.

@ e1528532 parece que sua ponte ssh não iniciou e o comando em doc / docker / jenkinsnode / README.md falha com "não foi possível preparar o contexto: não foi possível avaliar os links simbólicos no caminho do Dockerfile: lstat / root / Dockerfile: nenhum arquivo ou diretório. "e, em seguida," Incapaz de localizar a imagem 'buildelektra- stretch: mais recente ' localmente ". Isso significa que a v2 não está acessível no momento.

@ markus2330 escreveu: mudou o problema para # 1829

Acho que uma das últimas atualizações do servidor de compilação quebrou elektra-gcc-configure-debian-stretch , que não é

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not known)

.

Acho que o problema com elektra-gcc-configure-debian-stretch é o servidor de compilação ryzen , que não consegue se conectar ao GitHub. Mudei o rótulo do trabalho de construção de debian para debian-stretch-mr acordo. Agora, o trabalho de construção parece funcionar novamente .

ryzen, que não consegue se conectar ao GitHub

Parece que a correção do NetworkManager do nosso administrador com "manged = true" não funcionou de forma confiável. Após reiniciar, "/etc/resolv.conf" era novamente um link simbólico pendente. Corrigi-o novamente, o GitHub deve ser acessível a partir de ryzen. Infelizmente, o rzyen v2 ainda não está acessível (falta a ponte ssh).

Elektra 0.8.22 foi finalmente lançado. Vou adicionar o link para # 676 assim que o site for construído, a construção do site leva mais de uma hora. Talvez possamos mover a construção da página inicial para uma máquina mais rápida e apenas copiar o site resultante para seu local.

Acho que temos que fazer algo sobre o servidor que hospeda http://build.libelektra.org. É apenas insuportavelmente lento e sem resposta 😢. Pessoalmente, não me importo se uma compilação completa de todos os testes levar muito tempo. No entanto, da forma como está atualmente, leva minutos até mesmo para se conectar ao servidor, se formos capazes de nos conectar ao servidor:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em><a href="/jenkins/">GET&nbsp;/jenkins/</a></em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.10 (Debian) Server at build.libelektra.org Port 443</address>
</body></html>

.

Sim, afetado não é apenas o Jenkins, mas todo o resto em execução neste servidor. Para mim, a situação muitas vezes também é inaceitável. Parece que há pouca RAM. (Troca 2GiG é usada)

Jenkins pode ser o motivo, existem dezenas de processos Java que lideram a lista em htop. Por muito tempo tivemos RAM suficiente e quase não usamos swap, e não mudamos muito (exceto na atualização do Jenkins e no aumento do número de trabalhos de construção).

Eu sugiro parar de usar o servidor da comunidade como um agente. Para isso, precisaríamos de v2 de volta, mas @ e1528532 parece estar ocupado. Também poderíamos alugar um servidor melhor, mas então precisaríamos de alguém com tempo para a migração.

@ markus2330 Você pode reiniciar o servidor de compilação? Atualmente, até mesmo trabalhos simples como elektra-todo falham.

Eu reiniciei a v2 no domingo, mas aparentemente já está fora do ar novamente, então devemos primeiro estabilizar a v2 antes de pensar em colocar outras coisas nela.

Eu reiniciei o Jenkins e a v2. Jenkins parece estar funcionando bem novamente.

@ e1528532 O túnel ssh parece ainda não funcionar. Mesmo depois de reiniciar a7, não é possível conectar-se à v2.

portanto, devemos primeiro tornar a v2 estável antes de pensar em colocar outras coisas nela.

O principal tempo de inatividade foi causado pela ponte ssh. Se a v2 apresentava problemas, geralmente era reiniciada em um dia.
Agora removi o resto do servidor X, então espero que a v2 agora esteja estável também. Para a7, este parecia ser o truque (não foi necessário reiniciar por algum tempo). Sem carga na v2 (que requer a ponte ssh), no entanto, não saberemos com certeza se ela é estável.

Que tal dividir as discussões sobre hardware (reinicializações) e software (atualizações do Jenkins)?

Parece haver um problema de conectividade de rede entre a7 e v2. A v2 está instalada e funcionando, mas ainda recebo "Nenhuma rota para o host". Parece que não posso consertar hoje.

A rede da v2 caiu porque a desinstalação do GNOME também desinstalou o gerenciador de rede. Agora corrigimos a rede (usando / etc / network / interfaces) e atualizamos para o BIOS / UEFI mais recente. Então, espero que agora tudo esteja estável.

Por falar nisso. existe mais um hardware que poderíamos usar através de uma ponte ssh ... (PCS)

O túnel ssh parece ainda não funcionar. Mesmo depois de reiniciar a7, não é possível conectar-se à v2.

Sim, isso não foi automatizado. Agora cuidei de tudo. O contêiner do docker deve reiniciar automaticamente agora se a máquina for reiniciada. Pelo menos eu configurei o sinalizador --restart para "sempre" de acordo com https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode # 37618747

Além disso, criei um novo usuário chamado "ssh-tunnel-a7-v2" que não tem senha definida em a7 e v2 (portanto, desabilitei a autenticação de senha para aquele). Criei um certificado SSH para o usuário na a7 e adicionei a chave pública dele aos hosts conhecidos na v2. Em seguida, adicionei um serviço systemd a /etc/systemd/system/ssh-tunnel-a7-v2.service que abre o túnel ssh automaticamente como um serviço systemd de acordo com https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service. Portanto, também deve funcionar quando o servidor for reiniciado ou a conexão ssh travar e não depender mais de mim ou do meu usuário. Devido ao uso de um certificado, nenhuma senha precisa ser usada para as conexões.

Além disso, a v2 é reiniciada, é claro, com essa nova configuração automatizada ativa. Esperançosamente, ele sobrevive ao próximo travamento (se houver), teoricamente deveria, mas veremos.

O trabalho de construção test-docker sempre falha, se o Jenkins executa o trabalho em ryzen v2 :

docker inspect -f . elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: docker: not found
[Pipeline] sh
[test-docker] Running shell script
+ docker pull elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: docker: not found

. Eu queria restringir o trabalho a nós diferentes de ryzen v2 , mas parece que a opção para esta etapa está faltando na página de configuração de test-docker . Alguém poderia dar uma olhada e corrigir este problema?

Obrigado olhando para isso! Não é possível atribuir vários rótulos aos agentes? Em seguida, você pode atribuir um rótulo exclusivo para ryzen v2 e vincular o trabalho a ele.

Felizmente, em breve obteremos suporte para o nosso servidor de compilação: +1:

Não é possível atribuir vários rótulos aos agentes?

Pelo que sei, sim, é possível atribuir vários rótulos a um agente.

Em seguida, você pode atribuir um rótulo exclusivo para ryzen v2 e vincular o trabalho a ele.

Como já afirmei antes [[1]], a opção “Restringir onde este projeto pode ser executado” parece estar faltando:

Eu queria restringir o trabalho a nós diferentes de ryzen v2 , mas parece que a opção para esta etapa está faltando na página de configuração de test-docker .

.

Ahh, entendi mal sua declaração como: "Não há como escrever uma expressão booleana que me permita dizer (estável &&! Ryzenv2)", não que não haja nenhuma opção de restrição de agente.

Talvez isso possa ser feito pelo DSL. Vou perguntar a Lukas se ele sabe o que fazer.

Oi,

como @sanssecours observou, ryzen v2 não tem o docker instalado, mas tem a tag docker.
As execuções de test-docker requerem que os nós tenham a tag docker.

As soluções possíveis são instalar o docker no nó ou remover a etiqueta do nó no jenkins

As soluções possíveis são instalar o docker no nó ou remover a etiqueta do nó no jenkins

Obrigado por fornecer uma solução para o problema. Acabei de remover a tag docker de ryzen v2 . Pelo que posso dizer, tudo parece funcionar agora.

Atualizei a descrição do nó 'ryzen v2' para refletir que ele é, na verdade, 'apenas' um contêiner docker em execução na v2. Daí porque o docker não estava disponível mesmo estando instalado na v2.

Também foi adicionado um plugin para jenkins que permite a visualização de dados de construção mais fácil (não ter que clicar em cada construção)

v2 caiu novamente, eu relatei.

Reiniciei a v2, mas não consegui reconectar o agente.

Pelo menos finalmente recebemos mensagens de erro sobre o que aconteceu antes da falha (claro que não há garantia de que as mensagens de erro tenham algo a ver com a falha):

watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [docker-containe:789]
...
NMI watchdog: Watchdog detected hard LOCKUP on cpu 14
...

Estranho, parece que minha máquina de reinicialização funcionou, o túnel ssh e os nós do docker foram reiniciados e posso me conectar a a7.complang.tuwien.ac.at -p 22222, o que significa que tudo deve estar aberto. No entanto, de alguma forma, Jenkins acabou de me mostrar uma roda giratória infinita por algum motivo, sem tempo limite, sem nada.

Eu tentei minha ponte ssh manual como tínhamos feito antes, o mesmo. Reiniciou o contêiner do docker mais uma vez, o mesmo. Então, honestamente, não tenho certeza do que exatamente está errado agora sem uma mensagem de erro, a única coisa que encontrei é um cara que aparentemente tem um bug semelhante (roda girando, mas nenhuma mensagem), mas nenhuma solução para isso além de reiniciar todo o mestre Jenkins nó (que não tentei): https://issues.jenkins-ci.org/browse/JENKINS-19465

EDITAR: tentei uma das soluções alternativas sugeridas (redefinir a configuração do nome do host para algo que não existe, reconectar e, em seguida, jenkins percebe que o nome do host está errado, mude de volta para o nome do host real e, de repente, funcionou sem qualquer aborrecimento). Então eu acho que este erro aconteceu em vez de algo com minha configuração de reinicialização, mas vamos esperar pela próxima falha para ter certeza disso;)

@ markus2330 aposto que você já descobriu isso, mas uma pesquisa rápida me mostrou que isso pode estar relacionado à configuração do c-state: https://bugzilla.kernel.org/show_bug.cgi?id=196683 , existem algumas sugestões soluções alternativas para isso

Parece que o servidor de compilação ryzen não consegue se conectar ao nosso repositório :

Falha ao buscar em https://github.com/ElektraInitiative/libelektra.git

.

a configuração do dns estava pendurada novamente. Já que eu não entendo completamente porque é
configuração da maneira que está atualmente, eu apenas restaurei as configurações do servidor de nomes e
reiniciou o trabalho de construção do docker.

Em 12 de março de 2018 às 17:03, René Schwaiger [email protected] escreveu:

Parece que o servidor de compilação ryzen não consegue se conectar ao nosso repositório
https://build.libelektra.org/jenkins/job/test-docker/162/console :

Falha ao buscar em https://github.com/ElektraInitiative/libelektra.git

.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

Uma vez que não entendo totalmente por que ele está configurado da maneira que está atualmente

Receio que ninguém o entenda. Talvez o servidor DNS esteja configurado incorretamente e não forneça informações adequadas sobre o servidor de nomes. Para a v2, desinstalamos o gerenciador de rede e parece que o resolv.conf está estável lá. Portanto, uma opção é desinstalar o gerenciador de rede em a7 também. (e use / etc / network / interfaces) Não há razão para que v2 e a7 tenham configurações divergentes, é apenas por causa da administração malfeita.

Idealmente (no longo prazo), gerenciamos ambos usando o Puppet.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , existem algumas soluções alternativas sugeridas para isso

C6 deve ser desativado, mas continuaremos a investigação.

O novo agente de compilação "ryzen v2 docker" não parece ter um daemon D-Bus rodando como "debian-stable-mm" .

Alguém pode instalar / iniciá-lo ou me dizer qual script configura as compilações multiconfig-gcc47-cmake-options para que eu possa adicionar um trecho para ter certeza de que foi iniciado?

@ markus2330 Suspeito que, como o ifupdown e o networkmanager estão habilitados, eles se metem no cabelo um do outro. desativar um dos dois certamente ajudaria.

Ok, removi o gnome e o gerenciador de rede em a7 para ficar consistente com a v2.

O novo agente de compilação "ryzen v2 docker" não parece ter um daemon D-Bus rodando como "debian-stable-mm".

O agente de compilação reside em um contêiner do docker, esperançosamente @ingwinlu ou @ e1528532 pode ajudá-lo a iniciar o daemon dbus lá.

Obrigada. Deve ser bastante fácil. Eu o inicio no contêiner do docker (Ubuntu 17.10 artful construído a partir de docs/docker/Dockerfile ) com os seguintes comandos:

mkdir /var/run/dbus # create directory for pidfiles & co
dbus-daemon --system

O servidor de compilação ryzen não conseguiu se conectar ao nosso repositório novamente 😭.

Desculpe, minha culpa. Parece que parar o gerenciador de rede foi o suficiente para quebrar o sistema.

Deve ser consertado agora. Por favor, não hesite em relatar quaisquer outros problemas.

@ markus2330 tenho certeza de que teria quebrado novamente na próxima reinicialização

Tomei a liberdade de refazer o arquivo / etc / network / interfaces (e mover a configuração das interfaces para /etc/network/interfaces.d)
que combinado com a desinstalação do gerenciador de rede deve mantê-lo estável

reveja a configuração e talvez reinicie para ver se funcionou

@ingwinlu Obrigado pela correção, a reinicialização funcionou bem.

Descobri que removi muitos pacotes, então instalei o Java (openjdk 9 headless e default-jre) novamente: smile:

@ingwinlu Você poderia fazer o dbus rodar no agente v2? Idealmente, mude também "/ home / armin / buildelektra-stretch / Dockerfile" para algum destino não específico do usuário.

@ markus2330 minha proposta de como proceder com o ambiente de compilação, na verdade, prevê a remoção do nó dockercontainer-on-v2 atual e substituí-lo por um compatível com docker (ou seja, não mais apontando para um contêiner docker na v2, mas aponta diretamente para v2) .

Depois, podemos configurar o pipeline de construção para construir a própria imagem a partir de Dockerfiles verificados no repositório para fornecer os diferentes ambientes necessários para os testes.

Posso priorizar o lançamento de uma imagem docker compatível com dbus quando chegar a ela, mas não gostaria de fazer um trabalho que será irrelevante em breve se não for necessário.

Sim, isso faz sentido!

O objetivo de longo prazo da v2 é que temos que compartilhá-lo com alguns outros contêineres docker (não para Elektra), então seria uma boa coisa se todas as nossas peças fossem virtualizadas de uma forma que não pudessem influenciar os outros contêineres docker. (talvez docker recursivo ou Xen?) Podemos / devemos fazer o mesmo para a7 ter configurações idênticas.

Continuaremos a ter acesso diretamente nas máquinas, mas devemos reduzir qualquer risco de que o Jenkins possa matar máquinas Docker com as quais ele não tem nada a ver.

Para alguns agentes, já temos uma configuração de Puppet. Seria ótimo se não o contornássemos ou ainda melhor: estender essa configuração para a7 e v2. Espero que @BernhardDenner possa lhe dar mais informações sobre isso em breve.

O servidor de compilação está inativo novamente 🙌.

A propósito, poderíamos mover a discussão sobre o status do servidor de compilação para uma discussão da equipe do GitHub , já que este tópico pode não ser interessante para todas as pessoas inscritas neste problema.

Sim, todo o servidor está inativo, incluindo o servidor de compilação: cry: E a v2 também está inativa (independentemente). Eu reiniciei a v2 e mudei a opção C-States na UEFI. Mas parece que há um grande problema com nosso servidor. Esperamos que ele seja substituído por um hardware melhor com mais memória: Cross_fingers:

Discussão da equipe do GitHub

Todos os ElektraDevelopers não são notificados se escrevermos algo na discussão da equipe do GitHub? Nesta edição, todos podem decidir se desejam se inscrever.

Para mim, uma questão ainda em aberto é se devemos dividir esse problema em dois: relacionado a hardware e relacionado ao Jenkins.

Todos os ElektraDevelopers não são notificados se escrevermos algo na discussão da equipe do GitHub?

Pelo que eu posso dizer, sim.

Nesta edição, todos podem decidir se desejam se inscrever.

Isso também é

O servidor de compilação está ativo novamente. Configurações alteradas:

• Configurações xms e xmx para reduzir a quantidade de coleta de lixo quando muitas compilações na fila
• Notei que usamos o scm polling. Limitei o poller para 4 enquetes simultâneas globalmente por vez para reduzir um pouco os picos que o servidor está obtendo atualmente.

EDITAR:

* Defina o número de build para manter 30 para todos os pipelines, de acordo com várias fontes que são lidas ao acessar o webui e, portanto, um grande número de builds antigos retarda as solicitações

Atualize o Jenkins para ver. 2.107.1

• Atualizar arquivo de guerra jenkins
• Desative a configuração de segurança do plug-in Use browser for metadata download , pois não permitiria a atualização dos plug-ins
• Atualize os plug-ins para as versões mais recentes disponíveis

EDITAR 18/03/2018:

• Adicionado um segundo executor a todos os nós em execução no mm

* despriorizou todos os agentes em execução no mr

O Master deve ser muito mais responsivo agora sob carga. Construir tudo deve ser mais próximo de 2h em relação às 4h + de antes.

EDITAR 24/03/2018:
desculpe pelos atrasos, semana agitada ...

• Adicionado um novo trabalho ao jenkinsserver (elektra-jenkinsfile) que executará o Jenkinsfile encontrado no repo (assim que existir)

EDITAR 28/03/2018:

• Refez o arquivo de unidade de túnel, agora ele analisa arquivos de ambiente e, portanto, pode ser ajustado para apontar para vários alvos
• Adicionado servidor v2 como um escravo capaz de executar docker
  
  
  
  • adicionou o usuário jenkins na v2
  
  
  • openjdk-9 instalado na v2
  
  

EDITAR 29/03/2018:

• Corrigir configurações de ulimit no jenkins master

Embora eu tenha certeza de que @ingwinlu ou alguém já está nisso: Parece que ryzen v2 está configurado incorretamente:

FATAL: Could not apply tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <[email protected]>) not allowed

de https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON , BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON / console, mas aconteceu em várias ocasiões.

OPA, desculpe. Ele não tem dependências instaladas e só deve atuar como um host docker. Vou remover os sinalizadores adicionais.
// EDITAR: deve ser feito. esperançosamente isso foi o suficiente
// EDIT2: Eu também desativei test-docker por enquanto, pois obviamente não consigo encontrar as imagens de construção necessárias para executar os testes.

Mas, droga, a coisa é rápida se realmente conseguir algo que possa construir
// EDIT3: renabled test-docker para rodar apenas em nós com a tag docker-prefab e deu essa tag para ryzen

Infelizmente, o problema parece ser maior do que o esperado originalmente.

Alguns trabalhos têm seus nós codificados permanentemente. Algumas tags estão desatualizadas (estáveis ​​em nós jessie). Algumas tarefas não exigiam os nós corretos e eram executadas apenas no nó correto, pois foram executadas antes e construídas com sucesso.

A introdução de um novo nó (nativo ryzen v2) alterou um pouco a alocação, embora não devesse.

Por favor, espere algum comportamento inesperado até que tudo esteja funcionando onde estava novamente.

Changelog:

• nós renomeados, <os>-<hostname>-<buildenv>
• desativou elektra-multiconfig-gcc47-cmake-options
  na verdade, ele não está sendo executado em escravos gcc47 há algum tempo, com uma mistura de construção gcc49 ou gcc63 dependendo de onde foi agendado. Se for renativado, ele provavelmente deve ir para o dockercontainer habilitado para gcc63 na v2
• retagged uma tonelada de jobs (pode ter perdido alguns deles)
  
  
  
  • elektra-todo estava exigindo stable , mas nem todos os nós estáveis ​​realmente tinham sloccount instalados
  
  
  • muitos mais casos semelhantes
  
  

A7 parece estar baixo

waht [email protected] schrieb am Do., 29. Marz 2018, 21:24:

Embora eu tenha certeza de que @ingwinlu https://github.com/ingwinlu ou
alguém já está nisso: Parece que ryzen v2 está configurado incorretamente:

FATAL: Não foi possível aplicar a tag jenkins-BUILD_FULL = ON, BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build # 185 jenkins-BUILD_FULL = ON, BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON-185" retornou código de status 128 :
stdout:
stderr:
* Por favor, me diga quem você é.

Corre

git config --global user.email " [email protected] "
git config --global user.name "Seu nome"

para definir a identidade padrão da sua conta.
Omita --global para definir a identidade apenas neste repositório.

fatal: nome de identificação vazio (para [email protected] ) não permitido

a partir de
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON , BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON / console
mas aconteceu em várias ocasiões.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

Você quer trabalhar nisso? Eu poderia reiniciá-lo hoje. Como alternativa, nosso administrador ou eu podemos reiniciá-lo na terça-feira.

Se não for muito complicado. Do contrário, não posso trabalhar em minhas relações públicas no
final de semana

markus2330 [email protected] schrieb am Sa., 31. März 2018, 14:33:

Você quer trabalhar nisso? Eu poderia reiniciá-lo hoje. Como alternativa, nosso
admin ou eu poderia reiniciá-lo na terça-feira.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

Ok, eu reiniciei e também desativei o C6-State no BIOS / UEFI (estava ativado). Também removi o gnome / xorg (pensei que já tivesse feito isso?).

Por falar nisso. a tela estava completamente preta, então só podemos adivinhar qual foi a causa.

estes têm aparecido em A7 a cada 10 minutos ou mais:

Apr 04 07:14:23 a7 kernel: [Hardware Error]: Corrected error, no action required.
Apr 04 07:14:23 a7 kernel: [Hardware Error]: CPU:0 (17:1:1) MC15_STATUS[Over|CE|MiscV|-|AddrV|-|-|SyndV|-|CECC]: 0xdc
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Error Addr: 0x00000003705a2f00
Apr 04 07:14:23 a7 kernel: [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x0000015c0a400f03
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Extended Error Code: 0
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Error: DRAM ECC error.
Apr 04 07:14:23 a7 kernel: EDAC MC0: 1 CE on mc#0csrow#3channel#0 (csrow:3 channel:0 page:0x700b45 offset:0xf00 grain
Apr 04 07:14:23 a7 kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
lines 5977-6036/6036 (END)

Essas podem ser as razões para o tempo de inatividade do a7, bem como alguns dos comportamentos de construção estranhos no a7 tardio

Seção valgrind desativada em elektra-ini-mergerequests , pois era executada por meio de make run_memcheck

estes têm aparecido em A7 a cada 10 minutos ou mais

Sim, já os vimos. Quando o computador foi comprado, alguém realmente verificou se o ECC funciona e nenhum erro desse tipo ocorria naquela época. A frequência desses erros depende de alguma forma da carga do sistema?

Seção valgrind desativada em elektra-ini-mergerequests, uma vez que era executado via make run_memcheck

Obrigado por limpar isso.

Estou tendo outtakes aleatórios (contêineres travando, compilações parando no meio, desconectando, ...) em a7 sem nenhum log 'real' novamente. apenas as correções de memória já mencionadas.

Obrigado, parece que algo está muito errado. E agora também temos erros incorrigíveis:

Apr  5 09:50:40 a7 kernel: [39549.503787] mce: Uncorrected hardware memory error in user-access at 73d6ce880
Apr  5 09:50:40 a7 kernel: [39549.503794] [Hardware Error]: Uncorrected, software restartable error.
Apr  5 09:50:40 a7 kernel: [39549.505882] [Hardware Error]: CPU:2 (17:1:1) MC0_STATUS[-|UE|MiscV|-|AddrV|-|Poison|-|-|UECC]: 0xbc002800000c0135
Apr  5 09:50:40 a7 kernel: [39549.506581] [Hardware Error]: Error Addr: 0x000000073d6ce880
Apr  5 09:50:40 a7 kernel: [39549.507287] [Hardware Error]: IPID: 0x000000b000000000
Apr  5 09:50:40 a7 kernel: [39549.507980] [Hardware Error]: Load Store Unit Extended Error Code: 12
Apr  5 09:50:40 a7 kernel: [39549.508677] [Hardware Error]: Load Store Unit Error: DC data error type 1 (poison consumption).
Apr  5 09:50:40 a7 kernel: [39549.509378] [Hardware Error]: cache level: L1, tx: DATA, mem-tx: DRD
Apr  5 09:50:40 a7 kernel: [39549.510136] Memory failure: 0x73d6ce: Killing java:1470 due to hardware memory corruption
Apr  5 09:50:40 a7 kernel: [39549.510908] Memory failure: 0x73d6ce: recovery action for dirty LRU page: Recovered

lá vai a7 novamente.

em uma frente mais produtiva: instalei o frontend do oceano azul para Jenkins. Antevisão

lá vai a7 novamente.

É realmente frustrante. Reiniciei a máquina e reconectei os agentes. Vou pedir ao nosso administrador para substituir a RAM amanhã, portanto, espere tempos de inatividade amanhã.

em uma frente mais produtiva: instalei o frontend do oceano azul para Jenkins. Antevisão

Parece ótimo! Talvez você possa nos mostrar na próxima reunião?

Nosso admin já está no fim de semana. Vou reiniciar o A7 e redefinir o BIOS / UEFI para os padrões de fábrica. Se os erros continuarem durante o fim de semana, ele deverá trocar a RAM.

EDIT: Nenhum trabalho de compilação estava em execução, portanto, nenhum trabalho de compilação foi cancelado.

EDIT: Tudo está de volta. Nenhum erro de memória até agora.

Está muito melhor. Alguém assistiu muitas dicas técnicas do linus e fez overclock do servidor?

Desculpe, eu tive que parar Jenkins por algum tempo. O servidor carregou 20 e as coisas que eu precisava fazer não eram mais possíveis (tempo de espera> 1h, então desisti e parei o Jenkins).

É possível que mesmo trabalhos de construção não iniciados precisem de RAM? (a lista de filas era muito longa) Caso contrário, os trabalhos de construção locais são os melhores candidatos para esses problemas. (3 trabalhos de construção local estavam em execução)

@ingwinlu Idealmente, não construímos nada nesse servidor. Além disso, podemos criar trabalhos de construção dependentes da carga em um servidor. (Não inicie trabalhos em um servidor com carga> 5?).

Comecei tudo de novo, mas espero que encontremos uma solução rápida para isso.

Eu bombeei VERSION e CMPVERSION nas configurações do sistema Jenkins.

@ingwinlu Seria ótimo se tivéssemos essas configurações também no Jenkinsfile.

@ markus2330 veja 8de9272051fe903a7df08f0abdf18879701f7ac9 para um exemplo de como conseguir isso em um Jenkinsfile

Removido make run_memcheck dos seguintes alvos devido a eles falharem há algum tempo e finalmente aparecerem no sistema de compilação graças a # 1882

• gcc-configure-debian-stretch-minimal
• gcc-configure-debian-wheezy
• elektra-gcc-i386

restringir elektra-gcc-configure-debian-stretch para executar em nós: stretch && !mr

Atualize o jenkins master para ver. 2.107.2 + atualizar todos os plug-ins

Eu tentei adicionar allowMembersOfWhitelistedOrgsAsAdmin a todas as tarefas de construção hoje, mas parece que ainda não consigo acionar uma construção de todas (consulte # 1863) corretamente e apenas algumas tarefas são executadas

@ markus2330 https://github.com/janinko/ghprb/issues/416#issuecomment -266254688

Alguém pode por favor

• consertar
• desativar, ou
• (melhor ainda) delete

elektra-clang-asan por favor 🙏. Atualmente, o trabalho de construção falha, embora todos os testes com falha:

• testlib_notification
• testshell_markdown_base64
• testshell_markdown_ini
• testshell_markdown_mini
• testshell_markdown_tcl
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

funcionam bem no Travis .

Eles não testam da mesma forma que (por exemplo) usam diferentes versões do clang ...

Uma vez que este tópico é absolutamente impossível de rastrear para relatórios de bugs ou discussões mais longas, irei abrir novos problemas para clang e clang-asan assim que eu chegar a ele.

Eles não testam da mesma forma que (por exemplo) usam diferentes versões do clang ...

Eu concordo, enquanto Travis usa o clang 5.0.0 desatualizado, a versão do Clang em elektra-clang-asan é antiga ( 3.8.1 ). Não vejo o valor de um trabalho de construção habilitado para ASAN para um compilador tão antigo.

Eu criei # 1919 para o teste de falha "testlib_notification" em "elektra-clang-asan".

Eu testei uma compilação com todos os agentes mr desabilitados e o mestre respondeu perfeitamente, enquanto uma compilação com todos os agentes mr habilitados, na verdade, atingiu o tempo limite de algumas compilações. Portanto, o # 1866 certamente fornecerá uma melhoria se pudermos nos livrar de todos os agentes mr (-wheezy, pois não pode ser armazenado em contêineres)

Testes posteriores mostram que é praticamente apenas o trabalho de construção da página inicial. Eu o removi de build all por enquanto, então ele só pode ser executado explicitamente.

Ele será substituído por uma solução em contêineres.

v2 está online novamente com o BIOS mais recente.

Por favor, relate quaisquer segfaults aqui (a CPU pode estar com bugs).

a7 parece estar baixo?

Em 4 de maio de 2018 às 11h10, markus2330 [email protected] escreveu:

v2 está online novamente com o BIOS mais recente.

Por favor, relate quaisquer segfaults aqui (a CPU pode estar com bugs).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 está de volta com o BIOS mais recente

a7 abaixou de novo?

Sim, havia quebrado. Ele mostrou o prompt de login sem nenhuma mensagem de erro e nenhuma reação a qualquer entrada (incluindo sys-req). Apenas o hard-reset ajudou.

Se você tem alguma idéia de qual poderia ser o problema, por favor, diga.

infelizmente, nenhum diário persistente é configurado em a7, então nenhum registro

quando podemos esperar que a7 e v2 estejam disponíveis novamente?

Ohh, eu não sabia que eles estavam caídos. Vou pedir ao nosso administrador para reiniciar e se ele não puder, farei isso por volta das 17:00.

Edit: Ele disse que irá reiniciá-los agora.

Edit: Ambos estão de volta.

Eu reiniciei a7 e v2 manualmente hoje. parece que a v2 não está mais acessível. você pode por favor, ele está realmente funcionando?

// EDITAR: resolvido corrigindo a configuração de rede em ambas as máquinas

aparentemente, a7 caiu novamente.

Ok, vou reiniciá-la. Caso contrário, nunca faremos esse lançamento.

alguma indicação da causa? apenas problemas de rede ou a máquina não respondeu novamente?

Tudo deve estar instalado e funcionando agora.

Acabei de receber no momento certo, havia alguns logs até que finalmente congelou completamente.

Os logs eram:

INFO: rcu_sched detected stalls on CPUs/tasks:
...
rcu_sched kthread starved for 7770 jiffies
watchdog: BUG soft lockup - CPU#2 stuck for 22s! [docker-gen]
... (many repetitions)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 2

Isso pode ser qualquer coisa. da cpu ryzen com defeito para uma psu com defeito :(

Em 12 de maio de 2018 às 14:33, markus2330 [email protected] escreveu:

Tudo deve estar instalado e funcionando agora.

Acabei de receber no momento certo, havia alguns registros até que finalmente
completamente congelado.

Os logs eram:

INFO: rcu_sched detectou paralisações em CPUs / tarefas:
...
rcu_sched kthread faminto por 7770 minutos
cão de guarda: BUG soft lockup - CPU # 2 travado por 22s! [docker-gen]
... (muitas repetições)
Watchdog NMI: Watchdog detectou LOCKUP rígido na CPU 2

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

Sobre # 1993

@ingwinlu Por favor, desabilite os jobs se eles não tiverem sucesso (ou pelo menos não os acione por padrão nem com "jenkins build all please"). Deve ter alta prioridade que não reprovemos empregos em RPs onde, na verdade, está tudo bem. (asan falhando por algum tempo não era uma boa situação)

Se eles falharem por causa de alguma ação do Jenkins que você executou, reiniciar os trabalhos seria bom: coração: Dizer isso aqui no # 160 também está certo.

A v2 está de volta, com uma nova CPU!

Envie muitos trabalhos para teste de estresse: sorria:

a7 parece ter caído novamente.

Obrigado, está tudo certo de novo.

Reiniciei o A7 novamente.

Ter um circuito que zera a7 a cada hora provavelmente aumentaria a disponibilidade.

quando podemos esperar para ver a7 novamente online?

a7 está de volta online

v2 está de volta online

A alimentação da v2 será trocada em cerca de 1h.

@ingwinlu você pode desativar os agentes e ativá-los novamente depois? (Se você estiver trabalhando nisso).

Os agentes v2 estão desativados por enquanto

v2 está funcionando novamente. Ele tem uma nova fonte de alimentação. Envie muitos trabalhos para teste de estresse da máquina.

Eu atualizei os plug-ins do Jenkins. A reinicialização resultante restaurou parcialmente os nós jenkins antigos (antes de serem renomeados), resultando em compilações quebradas em todos os lugares, pois os repositórios git foram quebrados.

Limpei os repositórios afetados e limpei os contêineres do docker em cache apenas para ter certeza.

a7 está inativo novamente e, como tal, as compilações baseadas em docker não estão disponíveis novamente.

Também estou revertendo a atualização para o xunit, pois ela viola as restrições de segurança.

Reinicializei a7 e reconectei todos os agentes.

as compilações do docker não estão disponíveis porque a7 está inativo novamente.

Reinicializei o servidor e reconectei os agentes.

Acho que substituir a7 é o melhor caminho a seguir, consulte # 2020

Acho que está fora do ar novamente, meu último commit resultou em Não é possível contatar a7-debian-stretch: java.lang.InterruptedException

@ e1528532 Obrigado por escrever aqui! Se quiser, você também pode votar em # 2020

Reiniciei a7 e reconectei os agentes.
Esperamos pelo melhor para que não ocorram problemas durante o fim-de-semana.

a7 está abaixo de novo: choro: Surpreendente que funcionou quase o fim de semana inteiro. Pode ser o recorde de tempo de atividade da semana. No entanto, # 2020 não recebeu muitos comentários.

Eu reiniciei o a7 (ele reagiu ao sysctl) e outra pessoa iniciou o jenkins. Tudo está instalado e funcionando novamente.

a7 acabou de cair novamente.

Obrigado pela informação! Reiniciei a7 e reconectei os agentes.

Faz sentido termos o agente "debian-jessie-minimal"? Acho que você pode removê-lo com segurança, uma vez que esteja integrado no Docker. (e parece que já é)

EDITAR:
Em https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
e https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
existem avisos:

WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask<strong i="13">@544b40e</strong>
java.lang.LinkageError
    at hudson.util.ProcessTree$UnixReflection.<clinit>(ProcessTree.java:710)
    ...
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
    at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854)

más notícias. v2 também caiu.

EDITAR: mas parece que consigo me conectar a ele via ssh ....
EDIT2: emitiu uma reinicialização na v2, mas agora não consigo mais conectar. ainda pode ser pingado de a7 embora ...

EDIT3: agora a7 também está desativado.

Obrigado por relatar! Eu reiniciei a7 e v2. Devemos reconsiderar # 2020.

Acho que a v2 caiu de novo:

Não é possível entrar em contato com v2-debian-stretch: java.lang.InterruptedException

Com a v2 estava tudo bem, mas a7 estava fora do ar novamente. Todos os agentes estão online novamente.

v2 parece estar sem resposta novamente. pingável de a7, mas nenhuma ação ssh. devem ser os problemas do btrfs apenas dos sintomas. você pode reiniciar tudo antes de ir para casa no fim de semana?

@ingwinlu Obrigado, @waht e eu reinicializamos a v2 com sucesso, mas não consigo conectar os agentes ("Conexão recusada (Conexão recusada)"). Alguma ideia do que está errado aqui? (login ssh interativo funciona)

ssh funcionou apenas quando não estava conectado através da ponte.

depois de reiniciar o serviço de ponte, a conexão pode ser estabelecida.

parece que o túnel ssh acabou em um estado indefinido estranho e não se matou. Não tenho certeza por que ele não se matou (serveraliveinterval está ativado).

Eu também precisei limpar manualmente todos os espaços de trabalho na v2, pois o fs foi corrompido e todos os trabalhos de compilação falharam.

a7 parece estar desativado. Não tenho certeza se posso reiniciá-lo antes de segunda-feira.

Eu reiniciei a7 e v2. (v2 porque havia mensagens de erro em a7 informando que ele não pode criar a ponte ssh para v2. Mas também após a reinicialização da v2 as mesmas mensagens de erro ocorreram. No entanto, a ponte ssh parece funcionar. Talvez alguma dependência (rede?) esteja faltando em os scripts de inicialização do A7?)

Talvez alguma dependência (rede?) Esteja faltando nos scripts de inicialização do a7

Não, está lá.

não pode criar a ponte ssh para v2

Acredito que esse comportamento ocorre quando o kernel v2 começa a não responder (e, portanto, nenhuma conexão de rede de entrada pode ser estabelecida). No passado, você mencionou logs indicando erros de btrfs na v2.

Eu preparo o servidor de construção para um desligamento para substituir a CPU mais tarde.

a7 e v2 estão de volta (a7 com nova CPU, v2 com seu sistema de arquivos raiz verificado)

embora tenha continuado durante o dia (com buildign consistente), parece que o a7 acabou de cair novamente.

Sim, vou reiniciar amanhã de manhã.

Devemos discutir novamente # 2020.

Eu reiniciei a7. Foi novamente um travamento da CPU.

a7 está desativado novamente.

Obrigado, eu reiniciei. Todos os agentes estão novamente online.

Parece que alguns dos nós debian estão inativos e, portanto, alguns PRS já estão esperando por um longo tempo para que a execução do teste comece. Isso é intencional?

Parece que alguns dos nós debian estão inativos e, portanto, alguns PRS já estão esperando por um longo tempo para que a execução do teste comece. Isso é intencional?

Durante uma atualização no nó mm-debian-unstable, a máquina parou de responder e não pudemos nos conectar a ela desde então. Uma vez que o proprietário não está respondendo aos nossos e-mails, provavelmente desaparecerá para sempre.

Embora tenhamos transferido uma boa quantidade de trabalhos de construção para o novo sistema, os que estão faltando são aqueles que estão atualmente na fila.

Desativei os trabalhos afetados e marquei-os como sendo substituídos e removidos dos documentos

@ingwinlu Obrigado por cuidar disso!

Ler os testes xdg é muito importante se alguém quiser trabalhar no resolvedor. Eu adicionei no post superior aqui. Você pode atualizar o que já conquistou na lista de verificação acima?

Desta vez, v2 é o vencedor.

@ markus2330 eu limpei o post superior.

Obrigado pela limpeza! Vou reiniciar a v2 (e talvez a7, vamos ver) amanhã de manhã.

Eu reiniciei. Não houve reação nem mensagem. Veja # 2020

Reinicie a7 e v2.

Eu reiniciei a7. Não encontrei nenhum problema com a v2, devo reiniciá-la mesmo assim?

i7 agora está disponível em 192.168.173.96 você pode criar uma ponte via a7 para ele?

Você precisa criar um usuário ssh-tunnel-a7-v2 na máquina ou criar uma conta para mim.

Adicionamos um escravo de compilação adicional i7-debian-stretch que ajudará com libelektra buildjobs.

v2-docker-buildelektra-stretch (offline) já que não há mais trabalhos de construção agendados lá. O ssh-bridge em a7 que expôs o agente também foi desabilitado.

Olá @ingwinlu ,
conforme discutido na última reunião, eu precisaria do ponto de acesso.
Você poderia me enviar as informações por e-mail, meu e-mail está em AUTHORS.md .
Por falar nisso. não conseguiu encontrar seu e-mail em nenhum lugar, talvez você deva se adicionar a este arquivo.

Nosso servidor de compilação v2 ficará offline até 31.07 09:00, pois estamos executando benchmarks nele. Espere tempos de construção mais longos.

Desculpe pela inconveniência.

// EDITAR: tempo de inatividade estendido em 2 horas

Parece que a extensão agora também foi aprovada. Seria bom ter de volta as compilações rápidas após o almoço (cerca de 13:00). :sorriso:

mm-debian-unstable foi atualizado e está online novamente. Existem trabalhos que podemos reativar e fixar no servidor?

Parece que o disco do i7 está cheio. Meus trabalhos falham com No space left on device ( Trabalho e Trabalho )

A propósito, eu realmente gosto da nova interface de construção (dockerization & jenkinsfile). Muito útil para reproduzir erros de compilação.

Obrigado por relatar!

Infelizmente, o redimensionamento exigiria uma reinicialização (rootfs precisa ser reduzido antes que o outro pudesse ser estendido) e só traria 20G. Eu removi as pastas de construção do Jenkins, mas elas eram minúsculas, então ainda estamos em 99%.

Portanto, limpar _docker seria mais eficaz:
@ingwinlu parece que _docker / overlay2 é enorme. Alguma ideia de por que tudo isso foi coletado lá?

Eu forço a limpeza dos artefatos do docker com docker system prune -fa . Esse
limpou cerca de 190 GB de espaço usado nas imagens do docker.

Na segunda-feira, 13 de agosto de 2018 às 07:54, markus2330 [email protected] escreveu:

Obrigado por relatar!

Infelizmente, o redimensionamento exigiria um reinício (rootfs precisa ser feito
menor antes que o outro pudesse ser estendido) e só traria 20G. eu
removeu as pastas de construção do Jenkins, mas elas eram minúsculas, então ainda estamos
99%.

Portanto, limpar _docker seria mais eficaz:
@ingwinlu https://github.com/ingwinlu parece tanto _docker / overlay2
é enorme. Alguma ideia de por que tudo isso foi coletado lá?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

Obrigado!

Podemos colocar isso no libelektra-daily ou no cronjob?

Diariamente faz algo semelhante, mas menos agressivo. Terá que levar outro
olha quando estou de volta a Viena.

markus2330 [email protected] schrieb am Mo., 13 de agosto de 2018, 09:22:

Obrigado!

Podemos colocar isso no libelektra-daily ou no cronjob?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Como você deve ter notado, o servidor de compilação estava inativo pela manhã (qualquer talvez à noite). A fonte de alimentação foi danificada e agora foi substituída.

Além disso, a7 ou v2 podem ficar offline para benchmarks por curtos períodos na próxima semana. Você verá a mensagem offline "benchmark" se anton iniciar benchmarks. Se o computador ficar off-line por muito tempo (por exemplo, mais de um dia), entre em contato conosco. (Então, pode ter sido esquecido de alternar para online novamente.)

Resolvido um problema com nossa imagem sid.

testkdb_allplugins falhou em nossa imagem sid durante os testes debian-unstable-full-clang, mas apenas quando executado na v2. Atualizei manualmente a imagem para usar os pacotes disponíveis mais recentes e coloquei-a em nosso registro.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ passou, mas ficará de olho nisso.

O problema foi mencionado em # 2216 e # 2215 ( @mpranj @sanssecours).

Implementei o acesso público ao nosso registro docker. Veja aqui alguma documentação sobre como acessá-lo.

Avise-me se algo não funcionar como esperado.

// EDITAR parece que o push não funciona, embora o login seja bem-sucedido.
// O acesso público do EDIT2 é desabilitado novamente. https://github.com/moby/moby/issues/18569. funcionalidade restaurada para construir o sistema
// EDIT3: o repositório público está ativo novamente em hub-public.libelektra.org

Anton quer substituir a placa-mãe do computador onde o hyper-threading é desativado na próxima terça ou quarta-feira (podemos escolher). Alguém precisa do buildserver em um desses dois dias?

Eu reiniciei o registro do docker e executei uma limpeza manualmente. esperançosamente, isso resolveu todos os problemas de construção com a imagem do site.

@ingwinlu obrigado pelo trabalho de manutenção!

Infelizmente, o estágio WebUI falha de forma bastante confiável, por exemplo, 321 ou 320 (falhou ainda antes, mas também ao puxar o WebUI?).

Estou cada vez mais convencido de que cancelar trabalhos no master é uma má ideia. Quase não temos compilações bem-sucedidas no master porque as compilações foram canceladas ou falham devido a problemas de rede. No histórico de commits é difícil dizer o que aconteceu porque de qualquer maneira eles são simplesmente mostrados como falha.

Como solução alternativa, desativei os estágios não confiáveis ​​em c3b59ecef95287ffc33b094b37e03d0ec6b5710f, mas espero que possamos ativá-los novamente em breve!

a7-debian-stretch ainda deve estar offline para os benchmarks? (colocado off-line desde 21 de fevereiro de 2019 10:47:56)

Obrigado por relatar! Parece que Anton se esqueceu de reativar. Eu ativei o nó novamente e também removi os nós antigos (exceto mm, pois eles ainda estão em execução).

Houve um tempo de inatividade do nosso servidor pela manhã. Tudo funciona novamente, mas recebemos uma oferta para que eles troquem o hardware. Portanto, provavelmente teremos outro tempo de inatividade de cerca de uma hora hoje.

O servidor está ativo novamente. Infelizmente, temos o mesmo hardware. Se alguém tiver tempo para a instalação / configuração, podemos atualizar o hardware.

Parece que as compilações do Jenkins são muito lentas (várias horas para uma compilação completa). Pelo que eu posso dizer, apenas a7-debian-stretch e i7-debian estão executando testes, enquanto todos os outros nós estão ociosos. Este é o comportamento esperado?

Obrigado por denunciar este problema!

Não, esse comportamento não é esperado. Parece que a v2 está desativada. Vou reiniciar o mais rápido possível.

v2 agora deve estar ativo novamente

A v2 está desativada e temo que continue assim até segunda-feira. As compilações serão muito lentas até então.

v2 está de novo com uma nova placa-mãe

Vou atualizar todos os 3 agentes de compilação (i7, v2, a7, nessa ordem) para Buster para evitar # 2852

Vou tentar manter o tempo de inatividade o mínimo possível. Os trabalhos de construção podem falhar, reinicie-os (depois que os agentes estiverem ativos novamente).

i7-debian-buster, ex-i7-debian-stretch está online novamente

v2 é a próxima

v2-debian-buster e a7-debian buster também estão online novamente

Eu reiniciei o trabalho anterior de compilação bem-sucedido no mestre para ver se tudo funciona novamente:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

Além disso, eu adicionei o PR https://github.com/ElektraInitiative/libelektra/pull/2876 para permitir trabalhos de construção de buster.

v2 parece estar fora do ar (também falha a conexão ssh), infelizmente não estou em Viena. Espero que nosso administrador de sistema conserte isso amanhã.

a7 agora também está inativo e com ele i7 (que está conectado via bridge sobre a7).

Portanto, atualmente nenhuma construção pode ser executada. Entrei em contato com o administrador.

Todos os servidores estão ativos novamente. Reinicie as compilações empurrando novos commits ou escrevendo "jenkins build libelektra please" como comentário para o seu PR.

Nota técnica: a7 caiu por causa de "bloqueio de software de bug watchdog". Tentei adicionar "nomodeset nmi_watchdog = 0". Esperemos que não estejam novamente tão instáveis ​​como já foram.

a7 (e também v2 e i7 porque eles estão conectados por meio de uma ponte sobre a7) estão desativados. Entrei em contato com nosso administrador. Por favor, tente evitar iniciar as compilações agora, pois isso só criará uma longa fila.

a7 está online novamente (já era ontem), a v2 não foi afetada

De acordo com a página de status do servidor de compilação, os servidores:

• a7-debian-buster ,
• i7-debian-buster , e
• v2-debian-buster

estão para baixo. O diretório de dados do Jenkins também parece estar bem cheio. E já que estamos nisso: seria ótimo se pudéssemos atualizar o Jenkins e seus plug-ins. Estou interessado em consertar esses problemas. No entanto, existem dois problemas.

1. Não tenho muita (ou realmente nenhuma) experiência em administração de servidores.
2. Eu provavelmente precisaria de acesso físico às máquinas, uma vez que elas parecem ser bastante instáveis.

a7 é uma ponte para i7 e v2, portanto, com a7 desativado, não sabemos sobre i7 e v2.

O acesso não é problema, posso dar para você. Mas você deve estar ciente de que atualizar o Jenkins é uma operação grande, pois geralmente requer reconfigurar o Jenkins (de acordo com as notas de lançamento, que são muitas, pois não atualizamos há algum tempo) e corrigir o Jenkinsfile (de acordo com as alterações de API dos plug-ins ) Me mande um e-mail se quiser acessar.

a7 (e todos os outros) estão de volta.

a7 está fora do ar novamente, entrei em contato com o administrador.

Nota técnica: a7 caiu por causa de "bloqueio de software de bug watchdog".

Uma pesquisa rápida sugere que este pode ser um problema de BIOS. Alguém verificou se há atualizações de BIOS disponíveis?

a7 é uma ponte para i7 e v2, portanto, com a7 desativado, não sabemos sobre i7 e v2.

Parece um péssimo design. Não há maneira de contornar isso?

Uma pesquisa rápida sugere que este pode ser um problema de BIOS. Alguém verificou se há atualizações de BIOS disponíveis?

Instalamos um novo BIOS, substituímos a CPU e atualizamos o kernel (veja as mensagens acima). O sistema ficou estável desde então. Agora, após a atualização para o buster Debian, ele está instável novamente.

No entanto, perguntei ao administrador se há um novo BIOS disponível.

Parece um péssimo design. Não há maneira de contornar isso?

i7 e v2 estão em uma rede privada porque não há endereços IPv4 suficientes. Perguntei ao nosso administrador se talvez uma configuração IPv6 fosse possível.

Perguntei ao nosso administrador se talvez uma configuração IPv6 fosse possível.

Na verdade não precisamos do IPv6, bastaria usar outro servidor mais estável como bridge.

Provavelmente, a v2 é tão instável quanto a7 (houve apenas um travamento, mas isso não diz muito porque imediatamente quando a7 morre, ela leva a carga da v2). Podemos usar i7 como ponte. Mas se v2 e a7 caírem, i7 também não terá muita utilidade, demoraria muitas horas para terminar um trabalho de construção. Além disso, o i7 não tem espaço suficiente para o registro do docker.

Portanto, essa mudança exigiria muito esforço e pouco ganho.

Corrigir o problema real de a7 e v2 é muito mais promissor.

Além disso, o i7 não tem espaço suficiente para o registro do docker.

Nesse caso, a única solução é consertar a7.

Infelizmente a7 caiu de novo: choro:

Tentei inicializar com o kernel antigo, mas isso não ajudou.

Para o BIOS, existem algumas outras versões disponíveis, mas de acordo com suas notas de lançamento, há pouca esperança de que eles consigam corrigir esse problema e não há como fazer o downgrade novamente se ele piorar ...

O BIOS para a7 está atualizado. Além disso, tentaremos usar um kernel mais novo a partir de backports.

A7 esperançosamente estará de volta em breve.

O novo BIOS não ajudou, agora a7 travou em minutos.

a7 está fora do ar novamente, entrei em contato com o administrador. O kernel mais recente dos backports será testado na próxima reinicialização.

a7 está de volta com o kernel 5.2

Acho que travou de novo ...

Ainda recebemos as mesmas mensagens de erro ou há pelo menos alguma mudança?

Sim, a7 caiu de novo, relatei ao admin. Ele nos contará sobre as mensagens ao reiniciar.

Alguém tem outra ideia? (Já atualizamos o BIOS e o kernel.)

Algumas fontes sugerem problemas com o driver gráfico nouveau e que devemos tentar nouveau.modeset=0 (de alguma forma, isso é diferente de nomodeset ). Também foi sugerido desativar "C-states" no BIOS.

Sim, a7 caiu de novo, relatei ao admin. Ele nos contará sobre as mensagens ao reiniciar.

Alguém tem outra ideia? (Já atualizamos o BIOS e o kernel.)

talvez desabilite a7 como um escravo jenkins para determinar se ele ocorre apenas quando a carga 'real' está na máquina.

@ingwinlu obrigado, boa ideia. Reduzi agora a um trabalho de construção um a7 (eram 2). Para o fim de semana (assim que o administrador sair do escritório), irei desabilitar o agente completamente.

@kodebach : obrigado, vou encaminhar as informações para o admin.

Existe algum prazo para quando a7 estará no ar novamente?

a7 está ativo novamente, com o hyperthreading desativado e apenas um trabalho de construção simultâneo.

Também poderíamos tirar um pouco da carga do a7, movendo as compilações alpine e ubuntu-xenial para o Cirrus. Ambos são execuções simples de "construção e teste". Eles não estão fazendo nada de especial como reportagens.

O Cirrus permite 8 compilações Linux simultâneas por usuário . Atualmente, a compilação linkchecker é a única compilação do Linux no Cirrus.

Na verdade, ubuntu-xenial é um pouco redundante, já que nossas compilações do Travis são executadas no Ubuntu Xenial.

Obrigado pelas dicas, mas não planejamos descarregar nenhuma versão do Linux do Jenkins. Ao contrário, @Mistreated trabalhará para melhorar nossa infraestrutura Jenkins para ser ainda mais atualizada e útil (por exemplo, criando mais pacotes). As vantagens do nosso Jenkins são:

1. nós temos tudo sob nosso controle
2. podemos escalá-lo facilmente (apenas Java + Docker é necessário nos agentes de compilação)
3. o Jenkinsfile é muito simples e (na maioria das partes) facilmente extensível

Mas é claro, todos são convidados a estender o Cirrus (ou qualquer outro sistema de compilação adicional oferecido gratuitamente, consulte # 1540).

Era apenas uma solução temporária, para neutralizar a desativação do hyperthreading e limitar a 1 trabalho simultâneo em a7.

a7 constrói apenas uma pequena parte (cerca de 2/5), então a redução pela metade deve ser quase imperceptível. Ou existem problemas específicos agora? (No momento, é claro, leva tempo para acompanhar as muitas tarefas do tempo de inatividade.)

a7 constrói apenas uma pequena parte (cerca de 2/5)

2/5 é 40%. Eu não consideraria isso uma pequena parte.

Ou existem problemas específicos agora?

Não, na verdade parece estar funcionando melhor do que antes.

Desculpe, eu quis dizer cerca de 2/6 (1/6 é i7, 3/6 é v2). E essa parte não é removida, mas apenas reduzida.

Não, na verdade parece estar funcionando melhor do que antes.

Perfeito!

Parece que a7 caiu de novo 😭.

Obrigado! Eu relatei.

No futuro, seria excelente se aquele que detecta primeiro pudesse reportar diretamente para

herbert em complang.tuwien.ac.at

Basta dizer que "a7 ist leider nicht erreichbar".

E depois reporte aqui também, para que o herbert não receba vários e-mails.

Certamente existe uma maneira de fazer o servidor mestre Jenkins enviar esse e-mail automaticamente e talvez também postar neste problema do GitHub. Seria muito estranho se não houvesse um plugin do Jenkins para uma tarefa tão simples ...

Sim, existe https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin, mas não tenho certeza se faz exatamente o que queremos. Ele também pode enviar e-mails quando alguém distrai o agente de propósito. E um e-mail pessoal tem muito mais probabilidade de ser tratado pelo administrador mais rapidamente.

Se automatizarmos algo, então reinicializaremos diretamente os PCs se eles estiverem inacessíveis (talvez eles até tenham algum tipo de watchdog embutido?)

a7 foi reiniciado e o "controle global C-State" desabilitado.

No entanto, não está online como agente de compilação.

Vamos ver se ele também trava sem carga. v2 e i7 funcionam novamente.

O administrador (Herbert) não está disponível amanhã, então deixo a7 desativado como agente de compilação por enquanto.

Meu plano (se não houver protestos ou travamentos do A7 antes) é ligar o A7 como agente de compilação amanhã. Se o a7 travar novamente, Herbert pode reiniciar o a7 na sexta-feira. Esta tudo bem?

Se a fila não for muito longa, acho que devemos manter o agente de compilação em a7 desativado por um pouco mais. A última falha ocorreu após 3 dias. Se o habilitarmos amanhã, não saberemos se o agente de construção causou o travamento ou não, a menos que ele trave antes disso.

Ok, então vamos ver como é o tamanho da fila.

Espero que o "controle C-State global" finalmente resolva o problema e acho que precisamos de uma carga elevada para testá-lo.

A fila era muito longa e as compilações principais estavam todas suspensas, pois precisavam de um 7 para a implantação do site.

Então eu comecei o agente a7 novamente.

Alguns dos trabalhos de compilação recentes do Jenkins foram cancelados devido à falta de espaço em disco no servidor de compilação principal. Liberei algum espaço removendo registros de trabalhos de construção antigos. Observe que também posso ter removido alguns arquivos de log de novos trabalhos de construção. Em alguns casos, a compilação do Jenkins para seu último commit pode ter falhado e agora você só vê alguma mensagem sobre um erro 404. Nesse caso, por favor, apenas

• use jenkins build libelektra please em um comentário abaixo do PR para reiniciar a compilação do Jenkins, ou
• reescrever o último commit sem alterações (por exemplo, usando git commit --amend ) e fazer um push forçado

. Desculpe pela inconveniência.

Obrigado por mantê-lo!

Eu marquei o nó v2-debian-buster como temporariamente offline , uma vez que não parece funcionar corretamente. Para obter mais informações, consulte a edição nº 2995 (e a edição nº 2994).

Obrigado por procurar a infraestrutura!

v2 estava sem espaço em disco. Executei docker system prune Espaço total recuperado: 58,37 GB

Em seguida, reiniciei a v2 e fiz o agente se conectar novamente.

Agora executei du -h | sort -h para encontrar outros arquivos a serem removidos.

Comecei a v2 novamente com uma nova versão do Docker. Por favor, relate compilações quebradas imediatamente.

Reinstalei o docker, limpei todas as configurações e removi / var / lib / docker. Esperançosamente, isso corrige o problema.

v2 será incluído novamente. Relate compilações com problemas imediatamente.

Como sugerido aqui , agora executei

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

e também reiniciei o i7 (havia muitas interfaces de rede do docker, elas se foram agora)

docker-ce está agora em todo lugar 5:19.03.1~3-0~debian-buster

Por favor, relate compilações quebradas imediatamente.

Parece que a compilação master falhou novamente , devido a problemas de conexão com v2-debian-buster (veja também o problema # 2995).

Pedi ao nosso administrador para olhar a alternância entre a7 / v2 / i7. Desativei v2 e i7 por enquanto.

Eu reiniciei o libelektra / master e o libelektra-daily.

Mudamos as portas para todos os 3 PCs.

Em seguida, removi jenkins homedir em v2 / i7 e reiniciei o agente v2 / i7.

Parece que não há mais espaço disponível em v2-debian-buster :

Status de saída de ApplyLayer 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: nenhum espaço restante no dispositivo

.

Obrigado por relatar, eu criei (muito) mais espaço na v2.

Remover trabalho concluído:

Tamanho do sistema de arquivos usado% de uso disponível montado em
/ dev / sda3 417G 227G 164G 58% /

buildserver está inativo devido à migração (para que tenhamos um estado consistente no backup do novo buildserver)

https://build.libelektra.org/jenkins/ está começando novamente

A carga no servidor de construção foi 200 devido a erros de kernel durante um backup, o servidor não reagiu mais e precisou ser reiniciado.

As mensagens de registro foram (exemplos):

[87400.120008]  [<ffffffff810be6a8>] ? find_get_page+0x1a/0x5f

[87372.120005]  [<ffffffff81357f52>] ? system_call_fastpath+0x16/0x1b
[87372.120005] Code: f6 87 d1 04 00 00 01 0f 95 c0 c3 50 e8 d7 36 29 00 65 48 8b 3c 25 c0 b4 00 00 e8 d0 ff ff ff 83 f8 01 19 c0 f7 d0 83 e0 fc 5a c3 <48> 8d 4f 1c 8b 57 1c eb 02 89 c2 85 d2 74 16 8d 72 01 89 d0 f0
[87372.120005] Call Trace:
[87372.120005]  [<ffffffff810be6cc>] ? find_get_page+0x3e/0x5f
[87372.120005]  [<ffffffffa016962f>] ? lock_metapage+0xc2/0xc2 [jfs]

[87400.110012] BUG: soft lockup - CPU#0 stuck for 22s! [cp:15356]

Esperançosamente, podemos migrar logo no início da próxima semana ( @Mistreated ?)

O servidor atualmente faz uma ressincronização do raid, então espere que seja muito lento.

As compilações do Jenkins não são mais realizadas, consulte # 3035

Jenkins começou novamente. Repita os trabalhos de criação do Jenkins.

Parece que v2-debian-buster está offline:

Abrindo conexão SSH com a7.complang.tuwien.ac.at:22221.
Conexão recusada (conexão recusada)

.

Obrigado, entrei em contato com nosso administrador, mas infelizmente ele já deve estar ausente.

Herbert já reiniciou a v2 ontem. Ele desativou o "multithreading simultâneo".

Se um servidor (v2, i7, a7) travar novamente, entre em contato diretamente com nosso administrador via "herbert em complang.tuwien.ac.at". Por favor, relate também aqui, para evitar vários e-mails.

Acho que há algo errado com o repositório Git para o branch master em v2-debian-buster :

git fetch --tags --progress https://github.com/ElektraInitiative/libelektra.git +refs/heads/master:refs/remotes/origin/master +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
fatal: loose object 9c0bc3ca6fcbc610abd845aeff5f666938d24117 (stored in .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117) is corrupt
fatal: the remote end hung up unexpectedly

. Já reiniciei o build três vezes, mas o Jenkins sempre falha com o mesmo erro.

Infelizmente, a v2 tem btrfs que às vezes parece corromper os arquivos. Um problema semelhante que já tivemos com uma falha de docker pull . No caso atual, o arquivo 0bc3ca6fcbc610abd845aeff5f666938d24117 parece estar corrompido. Ao executar md5sum nas ocorrências deste arquivo, obtenho:

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

Agora removi todo o diretório do master e reiniciei a compilação. Veja também # 3054

Como não estou disponível por alguns dias, entre em contato com "herbert em complang.tuwien.ac.at" sobre questões relacionadas a a7 / i7 / v2 inacessível. @Mistreated será responsável por tudo que não esteja relacionado à reinicialização dos servidores. (Esperamos obter um novo agente de compilação em breve.)

Também informe sempre aqui, para evitar vários e-mails e para que todos tenham uma boa visão geral do que está acontecendo.

O servidor de compilação está com defeito no momento?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

O servidor de compilação está com defeito no momento?

Parece que o servidor principal de compilação do Jenkins não consegue conectar i7 . Eu marquei o nó como temporariamente offline.

A compilação falha em casos arbitrários:
Aqui foi interrompido sem motivo
Aqui, um caso de teste falha que não está relacionado ao meu PR (acabei de adicionar uma decisão de design sem tocar em nenhum código)

Aqui foi interrompido sem motivo

Recebi o mesmo código de interrupção 143 para dois PRs e ainda não posso explicá-los. Eu reiniciei a compilação e espero que funcione agora.

Aqui, um caso de teste falha que não está relacionado ao meu PR

Isso deve ser corrigido graças a @sanssecours com # 3103. Por favor, rebase para master.

O novo nó do Jenkins hetzner-jenkins1 não parece funcionar corretamente . Eu marquei o nó como temporariamente offline.

Eu atualizei o docker no i7 e reiniciei a máquina. Espero que isso resolva o problema. O agente está online novamente. Por favor, reporte problemas aqui (e / ou desative o agente).

Atualmente, um trabalho de # 3065 está sendo executado no i7.

@Mistreated, você pode depurar o hetzner-jenkins1, por favor?

Existe a possibilidade de desligar facilmente uma verificação de link por algum tempo?

Isso vem acontecendo o dia todo:

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

Outros PRs (mais recentemente # 3115, # 3113) também são afetados. De acordo com downforeveryoneorjustme, os links realmente não estão disponíveis.

ATUALIZAÇÃO: O site ainda está offline. Fiz um PR para este # 3117.

Existe a possibilidade de desligar facilmente uma verificação de link por algum tempo?

Você pode desativar links individuais adicionando-os a tests / linkchecker.whitelist (como você já descobriu)

Não consigo reexecutar compilações com falha do Cirrus. Consulte https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

O botão não faz nada. Existe um truque de mágica para fazê-lo funcionar?

editar: ou alguém mudou algo ou a x`ésima tentativa finalmente funcionou. A compilação está em execução novamente! :)

Parece que o agente de compilação a7-debian-buster não consegue reiniciar:

…
[10/28/19 06:02:59] [SSH] Starting slave process: cd "/home/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout

.

editar: ou alguém mudou algo ou a x`ésima tentativa finalmente funcionou. A compilação está em execução novamente! :)

Depois de ver seu comentário, pressionei o botão “Reiniciar trabalhos de compilação com falha” também. Pelo que eu posso dizer, pressionar o botão realmente reiniciou os trabalhos de compilação com falha.

Depois de ver seu comentário, pressionei o botão “Reiniciar trabalhos de compilação com falha” também. Pelo que eu posso dizer, pressionar o botão realmente reiniciou os trabalhos de compilação com falha.

Não funcionou para mim, porém, vou fornecer alguns gif da próxima vez!

Vou reiniciar o servidor de compilação e seus nós. Os trabalhos de construção de # 3121 e # 3099 precisam ser reiniciados, pois eles tinham trabalhos em agentes inativos.

Não funcionou para mim, porém, vou fornecer alguns gif da próxima vez!

Você não precisa fornecer um GIF, pois já acredito em você 😊.

Parece que Jenkins tem problemas para parar, espero um pouco antes de matar todos os processos Java à força.

Eu também atualizei o docker em todos os agentes (no i7 ele já estava atualizado).

Jenkins está ativo novamente com o intervalo de pulsação sugerido em # 2984. Todos os nós estão conectados.

Reinicie todos os trabalhos conforme necessário e relate quaisquer problemas aqui.

v2 está fora do ar, pedi ao nosso administrador para reiniciar.

Eu habilitei a v2 novamente, uma vez que ela parece estar ativa e nosso backlog de build está do tamanho adequado.

Existe um problema com a compilação novamente ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

Existe um problema com a compilação novamente ( hetzner-jenkins1 )?

Sim . Desativei o nó.

Apenas a cota de disco foi excedida, eu não queria sobrecarregá-la com memória. Eu limpei agora. Está de volta.

Nó atualizado.

Aumentei hetzner-jenkins1 para 4 compilações paralelas. Esta é apenas uma medida temporária, desde que nada mais esteja sendo executado lá.

Eu diminuí temporariamente o número de executores em hetzner-jenkins1 de 4 para 2, pois o tempo limite do conjunto de testes está se esgotando. Acho que isso acontece quando muitos trabalhos são compilados enquanto os testes estão em execução. Podemos precisar limitar os recursos disponíveis para um único contêiner, mas isso não interfere muito em outros trabalhos.

Sinta-se à vontade para corrigi-lo se achar que essa foi a abordagem errada.

EDIT: diminuiu para 1 porque os testes ainda estão expirando e constantemente reconstruindo desperdícios ainda mais recursos.

@mpranj Obrigado por consertar isso!

@mistreated talvez você atribuiu apenas uma única CPU ou similar? Você pode atribuir mais e aumentar o número de executores? O hardware deve ser mais forte como v2.

Desativei i7-debian-buster porque não há espaço em disco restante, o que leva à falha de todas as compilações. Se alguém tiver acesso, limpe algo e reative-o.

@mpranj obrigado por desativar!

Desculpe, onde estou atualmente o ssh está bloqueado (alguns aplicativos de firewall, e o ssh em outras portas não funciona). Portanto, não posso conceder acesso ou fazer qualquer limpeza agora.

Como i7 é o mais fraco dos agentes, pode não ser um grande problema de qualquer maneira.

@Mistreated talvez você atribuiu apenas uma única CPU ou similar? Você pode atribuir mais e aumentar o número de executores? O hardware deve ser mais forte como v2.

Não tenho ideia de quão forte é v2.
Atualmente jenkins1 usa 4 CPUs com 8 de memória e 16 de swap. Posso aumentá-lo facilmente, só não sei até que ponto você quer que eu aumente.

Uma nota para as futuras decisões de hardware: a phoronix parece fazer testes de compilação em seus artigos de CPU (por exemplo, Ryzen 7 3700X, teste Ryzen 9 3900X, no final do artigo ).

Parece que a hetzner adicionou recentemente o AMD Ryzen 7 3700X aos seus servidores baseados em AMD.

Não tenho ideia de quão forte é v2.

@ingwinlu escreveu sobre isso em sua tese (a ser encontrado em abgaben repo lukas_winkler)

Atualmente jenkins1 usa 4 CPUs com 8 de memória e 16 de swap. Posso aumentá-lo facilmente, só não sei até que ponto você quer que eu aumente.

Enquanto não tivermos mais nada em execução no servidor, você pode alocar todos os recursos. Mais tarde ainda podemos descer (quando movemos Jenkins).

Eu atualizei o hetzner-jenkins1.
O erro com o front-end em que fica sem memória foi corrigido.
Agora ele executa 2 compilações paralelas.

Parece que não há mais espaço em v2-debian-buster :

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

Obrigado, também marquei offline, até que alguém tenha acesso para limpar.

hetzner-jenkins1 falhou em meus 3 PRs porque a cota de disco foi excedida. Aqui está a saída:

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on hetzner-jenkins1
/home/jenkins/workspace/libelektra_PR-3106-LB35J55FSRLFKFEU2WP6AWVLM3IH4JWI6C5B57NWB6DDARN4JDUA@tmp/ff803792-a127-4b8f-8588-439af982c8a4: Disk quota exceeded

Marcado hetzner-jenkins1 como offline porque a cota de disco foi excedida.

Eu limpei i7 e v2 (removendo / home / jenkins / workspace / * e executando docker system prune ). Agora temos:

• i7: / dev / mapper / i7 - vg-home 199G 152G 37G 81% / home
• v2: / dev / sda3 417G 255G 147G 64% /

Então reiniciei os agentes.

@Mtratado, você pode consertar # 3160 para que isso não volte a ocorrer tão rápido. Corrija também hetzner-jenkins1. Existem muitos recursos nesta máquina, não é realmente necessário que ela atinja um limite de recursos todos os dias.

Não sei se existe uma maneira legal de redimensionar o disco. É por isso que não estou dando ao nó tudo de uma vez .. hetzner está de volta.

v2 estava novamente sem espaço, eu limpei: / dev / sda3 417G 315G 102G 76% /

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log não inicia

Eu acho que o sistema de compilação está completamente travado, PRs não estão sendo construídos.

Obrigado por relatar, vou reiniciar o Jenkins e limpar alguns arquivos, pois o disco está cheio.

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log não inicia

Agente conectado com sucesso e online

Presumo que está tudo bem agora com hetnzer-jenkins1?

Muito obrigado! Parece que o Jenkins ainda não está reagindo às compilações. v2 e i7 agora ambos falhar com: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins está ativo novamente, reinicie os trabalhos.

java.io.IOException: Não foi possível copiar slave.jar em '/ home / jenkins' no escravo.

fixo (também estava sem espaço)

@Mistreated, por favor, conserte o jenkins-daily, pois isso torna as tarefas de limpeza que agora sempre precisamos fazer manualmente!

@Mistreated "jenkins build libelektra please" ainda está quebrado, isso está relacionado às mudanças dos webhooks?

Talvez tente hoje mudar para o novo Jenkins, mas se você não conseguir fazer isso, faça com que a instância antiga funcione novamente!

Eu acionei uma varredura de repositório, agora o "jenkins build libelektra, por favor" parece funcionar novamente.

Parece que o disco está cheio por v2-debian-buster

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

Infelizmente. Marquei v2 como offline até que seja resolvido.

Obrigado por relatar!

@mpranj Dei acesso a você, pode tentar

Obrigado! Parece-me que há uma abundância de recursos desperdiçados por imagens antigas do docker espalhadas por aí. Além disso, parece que o btrfs + docker tem bugs. O Docker cria subvolumes btrfs para cada contêiner e não os limpa adequadamente depois. O comando docker system prune -f também não libera espaço.

Eu retirei v2 e a7 para manutenção para liberar os recursos e equilibrar o btrfs.

login do docker falhou

Crie imagens do docker que não podem ser puxadas. Algo acontecendo com o docker hub?

Sim, desculpe, com a7 também tirei o hub do docker. Vou postar uma mensagem aqui quando estiver no ar novamente.

a7 incluindo docker hub está ativo novamente. Deixei v2 off-line porque não é possível fazer login no hub para obter imagens?!? Não sei o que há de errado aí, não mudei nenhuma credencial ou então e os outros nós podem fazer o login. Alguma ideia?

O Btrfs ainda está se equilibrando em segundo plano, a7 pode ficar mais lento por mais uma hora ou mais.

@mpranj obrigado por consertar isso! Quais comandos foram necessários para o reequilíbrio do btrfs?

Infelizmente, não sei as credenciais, espero que @ingwinlu possa nos ajudar.

Os comandos que usei para reequilibrar foram:

Corrija um bug talvez com btrfs:

btrfs balance start -dusage=0 -musage=0 /mountpoint

Realmente reequilibre o fs, isso leva muito, muito tempo. O parâmetro de uso pode / deve ser ajustado, é o que funcionou hoje:

btrfs balance start -dusage=80 /

As credenciais podem ser alteradas facilmente, mas teríamos que fazer login em todos os agentes jenkins que se conectam ao hub do docker novamente com as novas credenciais.

O maior problema era que alguns contêineres docker ainda estavam em execução e a remoção do sistema docker não fazia muito. Portanto, derrubei os agentes e liberei tudo enquanto ele estava inativo. Havia TONELADAS de contêineres espalhados.

Sim, infelizmente os contêineres são recriados rapidamente. Espero que @Mistreated consiga corrigir o trabalho libelektra-daily em breve (ele executa docker system prune ).

Também fiz análises forenses digitais bastante complexas e roubei as credenciais do hub. :rindo:

v2 está funcionando novamente.

Muito obrigado! : 100: Por favor, envie-nos as credenciais.

Enviei. A propósito, acho que a7 provavelmente está lento apenas por causa da baixa velocidade do disco, mas é bom que tenha espaço suficiente para o hub do docker. Parece que a maior parte do tempo a CPU não está fazendo nada lá.

Outro pensamento: talvez possamos fazer as tarefas de limpeza críticas adicionalmente por cronjob para evitar situações como as que tivemos agora.

Envie-nos as credenciais.

@mpranj Acho que estava nesse grupo de "nós". Eu não estava em algum CC ou algo assim?

@Mtratado desculpe, enviei para markus e não tinha seu e-mail. Em a7 você encontrará CREDENTIALS.txt em sua casa.

Preciso do nó hetzner-jenkins1 para testar o novo servidor jenkins. Vou desligar no servidor antigo até amanhã de manhã.

Você pode criar facilmente um segundo hetzner-jenkins2 para testes. Se for apenas por esta noite, deve estar tudo bem.

Outro pensamento: talvez possamos fazer as tarefas de limpeza críticas adicionalmente por cronjob para evitar situações como as que tivemos agora.

libelektra-daily faz esses trabalhos de limpeza, mas agora falha: # 3160. Se você tem ideias para melhorar este trabalho, por favor, diga-nos.

Acho que estava neste grupo de "nós". Eu não estava em algum CC ou algo assim?

Sim, desculpe, esqueci de dizer a mpranj que "nós" se refere a você.

Espero que esteja tudo bem manter hetzner-jenkins1 por um tempo, todas as compilações estão boas agora, acho que posso deixar o servidor totalmente funcionando esta noite.

v2 está inacessível, entrei em contato com o administrador.

Espero que esteja tudo bem manter hetzner-jenkins1 por um tempo, todas as compilações estão boas agora, acho que posso deixar o servidor totalmente funcionando esta noite.

Isso seria ótimo!

v2 está inacessível, entrei em contato com o administrador.

Obrigado, mas infelizmente ele não responderá antes de segunda-feira.

A v2 obtém um novo kernel (simplesmente travou).

i7 também será reiniciado.

Todos os 3 servidores (v2, a7, i7) agora têm "Linux v2 5.2.0-0.bpo.2-amd64 # 1 SMP Debian 5.2.9-2 ~ bpo10 + 1 (2019-08-25) x86_64 GNU / Linux "

Eles estão ativos e online, reinicie os trabalhos se necessário.

Apenas uma nota:
Eu fiz a varredura do repositório novamente com o novo servidor. Isso pode causar alguns erros no antigo.

Parece que o master [1] também foi construído no novo servidor. Não foi bem sucedido. Ao clicar no status, uma página de login aparece [2]. Reconfigure o Jenkins para que tudo possa ser visualizado sem estar conectado.

Esperançosamente, podemos mudar para o novo Jenkins em breve. Ver os erros de dois Jenkins diferentes não torna a situação mais fácil: wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 : 8080 / login? From =% 2Fjob% 2Flibelektra% 2Fjob% 2Fmaster% 2F1% 2Fdisplay% 2Fredirect

@ markus2330 pode o a7 / v2 ser reiniciado remotamente após uma atualização ou existem algumas armadilhas?

Normalmente funciona, mas se não for urgente, é melhor esperar até que o administrador esteja lá. Posso reiniciar na terça-feira, se estiver bom para você?

Obrigado! Nada urgente, apenas uma questão geral. Ele surgiu porque o Debian 10.2 acabou de ser lançado. Vou esperar um pouco com as atualizações.

Mesmo assim, você pode fazer a atualização (apenas sem reinicializar). Então, em caso de travamento, já teremos o kernel 10.2 quando o administrador apertar o botão reset: wink:

@mpranj, você pode adicionar um cronjob que limpa os instantâneos antigos? Ou isso não é possível sem parar o docker?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ recomenda também rebalancear btrnfs em um cronjob.

você pode adicionar um cronjob que elimina os instantâneos antigos? Ou isso não é possível sem parar o docker?

Posso adicionar um cronjob sem parar todos os contêineres do docker. Isso pode não limpar tudo, mas podemos tentar. Como eu disse, às vezes os contêineres continuam funcionando para sempre / até que a máquina trave. A limpeza completa requer que desabilitemos temporariamente o agente de compilação, então podemos forçar a parada de todos os contêineres.

Também posso adicionar o rebalanceamento como um cronjob.

Obrigado, vamos tentar.

Mestre está sem memória. Eu queria executar o Scan Repository no antigo Jenkins porque a7 e i7 obtêm o seguinte erro ao extrair imagens do docker:

login do docker falhou

Eu tenho v2 e hetzner-jenkins1 em execução no novo servidor agora.

Mestre está sem memória.

Obrigado por relatar. Removi alguns dados de cobertura antigos e habilitei o nó mestre novamente. Para todos com solicitações pull abertas: reinicie suas compilações do Jenkins com jenkins build libelektra please . Desculpe pela inconveniência.

Em # 3234 @ raphi011 sugeriu:

imo isso é realmente urgente, a fragilidade e lentidão dos testes tornam difícil, senão impossível, fazer quaisquer alterações se você tiver que esperar tanto tempo para verificá-las.

Eu concordo que é muito urgente, mas @Mistreated já faz o que pode.

Portanto, talvez possamos usar o servidor de compilação com mais moderação e apenas compilar se realmente acharmos que o PR será mesclado em breve. As compilações desnecessárias devem ser canceladas.

Ou que tal (temporariamente) interromper a construção automática de PRs no envio de alterações (para que a construção comece apenas com jenkins build libelektra please )? @Mistreated você sabe como reconfigurar o Jenkins para fazer isso (não achei a opção)?

Também tenho a sensação de que jenkins build libelektra please não funciona no momento, pelo menos não funcionou para esta compilação: https://github.com/ElektraInitiative/libelektra/pull/3073 eu tive que empurrar um commit vazio para iniciar o pipeline.

Cronjob de limpeza implementado e kernel de backport atualizado em a7 e v2. Há um changelog bastante para o kernel, ele estará ativo na próxima reinicialização.

Muito obrigado! O kernel backport "antigo" ainda está instalado de forma que tenhamos um fallback se ele não inicializar?

Sim, ele pode ser removido após uma inicialização bem-sucedida no novo kernel.

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on i7-debian-buster

docker login failed

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3244/1/pipeline

Desativei i7 para uma limpeza manual, atualização de kernel e docker. Alguém ativou i7 enquanto eu estava trabalhando nisso. Tudo está instalado e funcionando novamente.

@Piankero Eu reiniciei sua compilação agora.

Também tenho a sensação de que jenkins build libelektra please não funciona no momento, pelo menos não funcionou para esta compilação: # 3073 eu tive que enviar um commit vazio para iniciar o pipeline.

funciona agora

@Mistreated você sabe como reconfigurar o Jenkins para fazer isso (não achei a opção)?

Eu adicionei o seguinte à configuração do Jenkins:

Suprimir o acionamento automático de SCM

Nota para todos: o uso de "jenkins build libelektra please" agora é obrigatório, os trabalhos de construção não começam simplesmente pressionando. Avisaremos aqui, quando revertermos esta configuração.

@Mtratado obrigado! Vamos ver se isso é suficiente. Espero que os comandos para masterizar ainda acionem as compilações master.

Ter o nó hetzner seria muito bom, no entanto. Há algum problema se o nó for usado por dois servidores de construção ao mesmo tempo? Ou se for um problema: não é muito fácil simplesmente clonar o TC?

@Mtratado obrigado! Vamos ver se isso é suficiente. Espero que os comandos para masterizar ainda acionem as compilações master.

branch master agora é uma exceção à seguinte regra:

Suprimir o acionamento automático de SCM

Quanto a

Ter o nó hetzner seria muito bom, no entanto. Há algum problema se o nó for usado por dois servidores de construção ao mesmo tempo? Ou se for um problema: não é muito fácil simplesmente clonar o TC?

Eu adicionei um novo CT (hetzner-jenkinsNode3).

não foi possível clonar o repo: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

talvez isso tenha algo a ver com o novo nó? (Palpite ousado)

talvez isso tenha algo a ver com o novo nó? (Palpite ousado)

este erro está em a7

este erro está em a7

muuuuito .. tentar novamente?

muuuuito .. tentar novamente?

sim, eu não acho que isso vai acontecer de novo ..

Vou executá-lo novamente para você.

@Mistreated Acho que podemos começar as compilações automáticas novamente. Mas, por favor, olhe primeiro para # 3160.

alguma ideia de por que isso iria falhar?

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

alguma ideia de por que isso iria falhar?

Parece que foi um problema temporário, a URL está atualmente acessível a partir dos agentes de compilação.

No longo prazo, seria ótimo configurar esse tipo de dependências nas imagens do docker, para evitar baixá-las para cada construção repetidamente. Isso também deve evitar falhas de construção devido a pacotes temporariamente indisponíveis, como você mencionou acima.

Bem, então .. jenkins build libelektra please o terceiro

Sim, temos todas as dependências diretamente nas imagens do docker exatamente por esse motivo. Eu criei # 3251

Coloquei v2 e a7 offline para reinicializar.

@ markus2330 se você tiver uma chance, habilite o hyperthreading em a7 .

v2 está ativo novamente, em a7 ainda há um buildjob.

Peguei os nós e os adicionei ao novo servidor. Eu vou deixar correr durante a noite. Amanhã retornarei os nós se houver mais erros no novo servidor Jenkins.

hetzner-jenkinsNode3 ainda funcionará no antigo Jenkins.

Amanhã retornarei os nós se houver mais erros no novo servidor Jenkins.

Pequenos erros de compilação não são motivo para voltar atrás. Em algum ponto, precisamos corrigir os erros, o ir e vir é muito demorado.

O que pode ser um obstáculo, no entanto, é que o novo servidor não está acessível. (Nenhum
http://95.217.75.163:8066 nem ssh). Pressionei o botão liga / desliga, vamos ver se a máquina reinicia. Devemos investigar qual era o problema, no entanto.

http://95.217.75.163 : 8066

Se houver tempo, habilite o TLS usando letsencrypt, para não vazar credenciais e nos expor a vários outros problemas.

Obrigado pela contribuição! Eu sugiro que façamos isso imediatamente quando mudarmos build.libelektra.org. Caso contrário, temos esforços dobrados.

Este erro é conhecido? Caught the following exception: null

Parece que a verificação de formatação falhou e as outras compilações foram encerradas.

você tem razão. Que mensagem de erro horrível: P

@Mistreated pode, por favor, ativar novamente para que os PRs sejam criados automaticamente? Devido aos muitos agentes, o servidor agora está hibernando na maior parte do tempo.

@Mistreated pode, por favor, ativar novamente para que os PRs sejam criados automaticamente? Devido aos muitos agentes, o servidor agora está hibernando na maior parte do tempo.

Feito.

Vou pegar hetzner-jenkins1 e v2 emprestados novamente para o novo servidor.

Você não precisa devolver, espero que possamos fazer a troca hoje.

Dica: ao fazer esse tipo de troca, é bom diminuir o TTL da entrada DNS para algo anormalmente baixo (por exemplo, 60 em vez de 21599 atualmente para build.libelektra.org). Depois que a alteração for propagada, devemos trocar a entrada DNS em um minuto, em vez de horas. Se for tarde demais, pode ajudar a limpar os caches DNS do google e do opendns, mas algumas pessoas inevitavelmente verão o recurso antigo até que as entradas em cache expirem globalmente.

EDITAR: após a alteração, o TTL deve obviamente ser revertido para algum valor lógico para colocar menos carga no DNS.

Mesmo que agora seja tarde demais, eu troquei $TTL 3600 (se precisarmos de várias alterações até que tudo funcione).

www-new e build-new já existem apontando para o novo servidor.

Agora mudei doc.libelektra.org. @Mistreated irá consertar a publicação. Vou dar uma olhada em www-new.libelektra.org

https://build-new.libelektra.org/ e https://www-new.libelektra.org/home deve funcionar agora.

Vou mudar todas as entradas DNS agora.

Todas as entradas DNS são alteradas.

Infelizmente, certbot falha porque parece falar com o servidor antigo, mas isso parece afetar apenas o download e a comunidade (URLs menos usados).

Portanto, esperançosamente, durante / após o fim de semana, todos verão os nomes DNS atualizados.

@Mistreated atualize a publicação de todos os artefatos: também para o site. Crie um PR para se certificar de que tudo está funcionando corretamente.

O servidor de compilação antigo agora está encerrado.

Eu preciso reiniciar o novo servidor (novo kernel e ponte de rede adicionados).

O servidor está ativo novamente com Linux pve 5.0.21-5-pve.

Agendei uma nova varredura de todos os PRs.

servidor offline devido a configuração incorreta / bug no pve (/ etc / network / interfaces foi excluído pela GUI?).

O bug era que a renomeação dos dispositivos de rede (que foi causada pela minha ação na GUI) levava a um OOPS do kernel:

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

O servidor deve estar instalado e funcionando novamente.

No entanto, os problemas anteriores permanecem (frase não funciona # 3268)

@Mistreated master também não parece mais construir automaticamente, eu o

Estou coletando erros urgentes em # 3268. Seria bom se você também pudesse testar se tudo funciona conforme descrito em doc / BUILDSERVER.md.

Jenkins não constrói sem um motivo dado:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Outro erro de compilação: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

Obrigado por relatar!

@Mistreated, você poderia instalar o Naginator + Plugin # 2967 como já foi discutido várias vezes? (Faça um instantâneo antes de fazer alterações no Jenkins.)

hetzner-jenkins1 : cota de disco excedida

@Mistreated, você poderia instalar o Naginator + Plugin # 2967 como já foi discutido várias vezes? (Faça um instantâneo antes de fazer alterações no Jenkins.)

Vou fazer isso hoje

hetzner-jenkins1: cota de disco excedida

@mpranj Eu adicionei o novo VM como um agente de compilação enquanto hetzner-jenkins1 está inativo.

Limpei algum espaço em hetzner-jenkins1 executando docker system prune -a e habilitei-o novamente.

Parece que há novamente um problema de que muitas coisas não são limpas por docker system prune -f . Desta vez, o driver de armazenamento não era btrfs mas vfs . :confuso:

Eu adicionei a nova VM como um agente de construção enquanto hetzner-jenkins1 está inativo.

A ideia agora é que não usemos mais o contêiner, mas apenas a VM.

Limpei algum espaço em hetzner-jenkins1 executando docker system prune -a e o habilitei novamente.

Muito obrigado! Você também pode fazer um cronjob lá? (na VM, não no contêiner).

fazer um cronjob lá?

Feito.

@Mistreated, você poderia instalar o Naginator + Plugin # 2967 como já foi discutido várias vezes? (Faça um instantâneo antes de fazer alterações no Jenkins.)

Temos que passar do pipeline para o trabalho de estilo livre, se quisermos o plugin naginator. Vou procurar alternativas.

As compilações na VM jenkinsNode3VM falham atualmente. Eles são incapazes de puxar o docker:

unexpected EOF
script returned exit code 1

Desativei por enquanto até que alguém consiga resolver o problema.

[cronjob] Feito.

Obrigado!

Temos que passar do pipeline para o trabalho de estilo livre, se quisermos o plugin naginator. Vou procurar alternativas.

Sim, boa ideia. Talvez seja melhor simplesmente codificar isso em nosso Jenkinsfile. Portanto, se uma tarefa / estágio de construção problemático falhar, é feita uma nova tentativa. Que esses puxões docker sejam tentados pelo menos duas vezes, pois esse é um dos problemas mais frequentes.

As compilações na VM jenkinsNode3VM falham atualmente. Eles são incapazes de puxar o docker:

@Mistreated, por favor, corrija isso.

As compilações na VM jenkinsNode3VM falham atualmente. Eles são incapazes de puxar

Consertei a imagem do docker que não podia ser puxada.

Muito obrigado! É sempre útil se você escrever o que estava errado e como você corrigiu.

Não tenho ideia do que estava errado, construí a imagem manualmente no agente. Já que o agente não conseguiu puxá-lo.

Quanto ao Dockerfile, (scripts/docker/debian/stretch) my Visual Code diz que tem 2 linhas vazias no final, mas vim diz que é apenas uma. Não sei se tem a ver com o erro acima, talvez seja apenas meu VS .

Parece que temos problemas com o registro do docker (# 3316 docker pull falha com unexpected EOF ).

Uma vez que a poeira depois do lançamento baixou e não há compilações em andamento, sugiro interromper tudo e tentar limpar o registro completamente. Depois disso, todas as imagens devem ser reconstruídas de forma limpa e esperançosa. Gostaria de fazer backup dos dados de registro antes de começar, apenas para ter certeza, mas espero que um início limpo elimine alguns erros que estávamos tendo.

Vou esperar para comentar se há algo contra isso antes de começar.

Eu acho que é um problema no

(scripts / docker / debian / stretch)

imagem, uma vez que é a única a falhar.

Eu o construí manualmente novamente, mas certamente há algo errado com a imagem no registro.

Relatórios Jenkins: jenkinsNode3VM (offline)

@Mistreated seria ótimo se você pudesse configurar alguma forma de monitoramento.

a7 (e portanto v2 e i7 ) estão em baixa. Entrei em contato com o administrador.

EDITAR markus2330: para cima novamente

Por causa de uma queda de energia planejada em 08.07.2020 na TU Wien, nosso administrador planeja desligar todos os servidores de construção no dia anterior (terça-feira, 7.7). As compilações serão muito lentas durante esse período, portanto, empurre nesse dia apenas em casos urgentes.

Os servidores estão online novamente, exceto o i7. Eu notifiquei o administrador.

Houve outra queda de energia (não planejada) ontem à noite, portanto, todos os servidores de compilação estão desligados agora. O administrador está trabalhando nisso.

EDITAR 30 min depois: tudo, incluindo i7, está de volta: foguete:

@ markus2330 parece que v2 e i7 perderam o acesso à Internet recentemente (possivelmente durante a queda de energia?). Você está ciente de quaisquer alterações de configuração que deveríamos ter feito, uma vez que as interfaces são configuradas estaticamente?

Não sei de nenhuma mudança, apenas de que os computadores foram ligados novamente após essas duas quedas de energia (uma planejada, outra não planejada).

Mas tens razão, também vejo que estes dois (mas não a7) já não têm ligação à Internet, embora sejam alcançáveis. Eu perguntei ao nosso administrador sobre isso.

Talvez possamos desconectá-los do Jenkins até que o problema seja corrigido?

Obrigado por entrar em contato com o administrador! Eu desconectei o i7 e v2 até que o problema seja resolvido. (As compilações não funcionam de qualquer maneira porque não podem extrair imagens do docker)

Alguém mudou algo no roteador há cerca de uma semana. A pessoa foi notificada e esperamos que conserte isso em breve.

Vamos mantê-los desconectados por enquanto.

O problema da Internet está resolvido agora e também instalei as atualizações de segurança nessas máquinas.

@mpranj você pode ligá-los novamente?

Obrigado @ markus2330.

Todos os nós estão online novamente.

Reiniciei o servidor de compilação para o kernel PVE mais recente. Jenkins deve levantar em breve.

Eu me mudei

• [] tornar o envio de e-mails se a compilação falhar mais confiável
• [] Imagem Docker sem usuário Jenkins
• [] imagens centOS / fedora / arch docker
• [] pacotes centOS
• [] agentes de compilação freebsd / openbsd / solaris

para # 3519 e vinculado ao # 3519 acima.

@robaerd agora também tem acesso a a7 / v2 / i7 e pode contatar o administrador em caso de problemas.

Apenas um relatório rápido dos tempos de construção (pipeline principal libelektra ):

• com a7 habilitado: 2h 29m 24s
• com a7 desativado: 1h 35m 45s

Por que o Jenkins mostra que foi encerrado? Seria bom sempre ler aqui com antecedência: wink:

O Jenkins será encerrado por causa de um backup completo do sistema e reformatação dos sistemas de arquivos de btrfs para ext4.

Jenkins está de pé de novo

Jenkins CI estará offline para manutenção por volta das 11:15 CET de hoje.

Vamos realizar algumas tarefas de backup e limpeza e tentar melhorar o desempenho de a7 .

Você será notificado novamente quando a manutenção terminar.

Jenkins CI e todos os servidores de compilação estão ativados novamente. a7 deve ter um desempenho muito melhor agora, mas tem menos capacidade de armazenamento.

Por favor, relate se você tiver algum erro.

Jenkins CI e os agentes de construção ficarão offline para uma curta manutenção / atualizações.

EDITAR: as atualizações estão feitas.

O servidor está fora do ar, eu investigo.

O servidor está ativo novamente.

Declaração oficial sobre a causa: "Houve um problema com o PSU no servidor adjacente que fez com que o servidor fosse encerrado; agora foi corrigido."

O ssd em a7 está cheio, fazendo com que todas as compilações nele falhem.

Vou tentar liberar algum espaço. É seguro desconectar o agente de compilação a7 do Jenkins por enquanto?

Obrigado por investigar isso!

Vou tentar liberar algum espaço. É seguro desconectar o agente de compilação a7 de Jenkins por enquanto?

Claro. Ao contrário, não seria seguro mantê-lo conectado se isso fizesse todas as compilações falharem.

A execução de docker system prune -a limpou aproximadamente 50% do espaço novamente. Talvez seja necessário adaptar o cronjob existente para adicionar a sinalização -a ?

A casa dos Jenkins também está usando muito espaço.

As compilações principais (pipeline completo com pacotes deb e construção de site) de alguma forma ainda estão falhando, embora tudo pareça verde. Alguma ideia?

O upload dos pacotes deb focais para community falha no arquivo elektra_0.9.3.orig.tar.gz . Provavelmente é um problema de permissão no arquivo. Vou removê-lo do diretório por enquanto e deixá-lo ser recriado na próxima execução.

De alguma forma, o sshPublisher, se falhar, não define o cenário para vermelho.

Talvez seja necessário adaptar o cronjob existente para adicionar o sinalizador -a?

Houve alguma razão pela qual você não fez assim? Caso contrário, parece uma boa ideia.

Jenkins CI e o registro em a7 ficarão offline para a migração da imagem da torre de vigia para uma nova versão. Deve levar apenas alguns minutos.

EDITAR: as atualizações estão feitas e o Jenkins CI está ativo novamente

Jenkins e os agentes descerão brevemente para uma atualização.

EDITAR: tudo foi atualizado e está funcionando novamente. Eu precisava corrigir um problema em que a7 estava usando pacotes Debian stretch docker em vez de buster. Eu também limpei algum espaço.

As compilações estão falhando porque não há espaço em a7 .

A infraestrutura de construção ficará indisponível por alguns minutos para manutenção.

A infraestrutura de construção está disponível novamente.