Libelektra: Construir cosas de servidor

@ markus2330

Acabo de publicar algunas correcciones relacionadas con el sistema de compilación. Pero también necesita arreglar algunos paquetes en su máquina estable de Debian:

• Instale qtdeclarative5-dev desde wheezy-backports (puede eliminar /opt/Qt5.3.0 después)
• Instale java8 como paquete:
  
  
  
  • Utilice este método: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • Deje que cmake encuentre 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 + reinicia el proceso local de Java de Jenkins. De lo contrario, todas las compilaciones fallarán.
  
  
  • Opcional: eliminar jdk7
  
  

Se ve bien, gracias por solucionar esos problemas.

También hice esos pasos en el agente estable de Debian.

Para otras máquinas, la instalación de qtdeclarative5-dev no fue posible, porque entra en conflicto con qdbus, que es necesario para kde4. Así que restauré el script anterior configure-debian-wheezy como configure-debian-wheezy-local.

También agregué los pasos de instalación que mencionaste como notas en el archivo README.md porque podrían ser de interés para otros.

¡Gracias por actualizar los agentes!

Cosas que faltan en el establo

1.) látex (+ creo que también se necesita texlive-latex-recommended)
ver 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.) ¿Puedes instalar clang (para elektra-clang, clang of wheezy no funcionará)?
3.) ¿Puede instalar mingw + wine para elektra-gcc-configure-mingw?

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

¿Por qué necesitas vino?

Por cierto, debes cambiar i586-mingw32msvc-X a i686-w64-mingw32-X en Toolchain-mingw32.cmake . En este momento, esto no funcionará en inestable.

¡Gracias por docu!

Wine es necesario para ejecutar los binarios de Windows compilados de forma cruzada (por ejemplo, exporterrors.exe)

Creo que instaló el mingw que se compila para w64. En el paquete mingw32, todavía hay un /usr/bin/i586-mingw32msvc-c++ .

No obstante, se agradece un nuevo archivo de cadena de herramientas para w64.

Instalé gcc-mingw-w64-i686 que es la compilación x64 de mingw con i686 como objetivo.
El paquete mingw32-binutils está obsoleto y ya no está disponible en inestable.

Vino instalado en ambos contenedores.

En realidad, la compilación de mingw está destinada a ser estable, por lo que eso no debería ser un problema.

MinGW-w64 es una bifurcación en mingw y es un objetivo bastante diferente. Nadie lo probó hasta ahora.

gracias por instalar vino

Mingw-w64 parece superior. Quizás es hora de seguir adelante :-)

Contribuciones bienvenidas;) No tengo ninguna máquina para probarlo.

Me temo que obtuviste el vino equivocado, debería ser apt-get install wine32

ver también http://build.libelektra.org : 8080 / job / elektra-gcc-configure-mingw / 218 / console

No.

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

ok, dpkg --add-architecture i386 resolverá esto. ¿Pero no puede simplemente fijar el trabajo mingw / wine a su máquina de construcción? La configuración de mingw es bastante especial.

Editar: Veré si puedo obtener elektra build con mingw-w64, por lo que no necesito instalar toneladas de libs i686.

El problema es que no tengo una máquina jessie de repuesto y el mingw de wheezy no conoce C ++ 11.

Me las arreglé para que mingw-w64 funcionara. Sin embargo, std :: mutex no está disponible porque no hay glibc en Windows y std :: mutex depende de pthreads. ¿Algunas ideas?

¡Wow gracias!

¿Da lugar a un error de compilación? Std :: mutex no se usa para internos
funcionalidad, pero solo en un archivo de encabezado para ser incluido por un usuario. Esta usado
aunque en casos de prueba.

Una solución para los problemas de compilación es proporcionar un std :: mutex en mingw
errores del sistema de lanzamiento de casos en cada intento de bloquear / desbloquear. De hecho, lo haría
esperar que la gente de Mingw al menos proporcione algo así (por ejemplo, cuando
alguna macro está configurada, similar a -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads podría ser otra forma. Pero eso es
lo más probable es que solo sea útil si todos los casos de prueba, excepto los que involucran std :: mutex
ya corro.

Básicamente, esta es solo una instancia de C ++ 11 que no está disponible correctamente.

estado de mingw ahora mismo:

• agregó dlfcn-win32 como proyecto externo a libloader. de esta manera cmake comprueba + compila la biblioteca como un paso de compilación adicional. Estoy vinculando el archivo para evitar dll deps adicionales.
• se agregó la dependencia winsock2.h / ws2_32.dll a cpp11_benchmark_thread. requerido por gethostname () - llamar

Ahora mismo estoy construyendo con -static-libgcc + -static-libstdc++ . De lo contrario, el vino no puede encontrar los dlls. El mutex adicional tampoco se compila. Probé mingw-std-threads. acabo de recibir más errores de compilación :-)

Si cambio de x86_64-w64-mingw32-X a x86_64-w64-mingw32-X-posix std :: mutex se compila bien, porque pthread está definido. Sin embargo, obtengo una dependencia adicional a libwinpthread-1.dll, que Wine no puede encontrar.

Sin embargo, creo que nuestra mejor opción es usar x86_64-w64-mingw32-X-posix .

Nuevamente, me sorprende que incluso tenga este problema. Hasta ahora estábamos felices cuando obtuvimos un libelektra.dll.

No puedo decir nada sobre esta decisión x86_64-w64-mingw32-X-posix , porque no la uso y no conozco las implicaciones. Me pregunto si existe tal posix-lib, pensé que el enfoque de posix-layer es cygwin y no mingw.

¿Esta decisión tiene algún efecto sobre libelektra.dll? Si es solo para los casos de prueba, a nadie le importará (siempre que el servidor de compilación pueda ejecutarlo). Si los casos de prueba se ejecutan, será un gran beneficio. (Vea el n. ° 270 donde las pruebas unitarias revelaron algunos errores extraños en Mac OS X)

Parece que se pueden descargar libwinpthread-1.dll , aunque no sé si funcionan con vino. ¿También puede agregarlo como proyecto externo como se hizo con dlfcn-win32 (para que todos los dlls se manejen de la misma manera)? De lo contrario, si necesita descargar 1 o 3 dlls para las pruebas, es posible que no importe (de nuevo, no soy un usuario y no entiendo el concepto de implementación, si lo hay, de los dlls de Windows).

@beku ¿Qué opinas? ¿Tiene tiempo para probar nuestra última versión 0.8.13 mingw-w64 en Windows junto con oyranos?

¿Las pruebas suelen estar habilitadas para el trabajo de compilación mingw? Ayer todos estaban discapacitados.

Sí, estaban discapacitados. Pero también se deshabilitaron los ejemplos / puntos de referencia afaik como cpp11_benchmark_thread . Así que pensé que lo había cambiado y compilado más de lo que se hizo anteriormente.

Compilé todo el repositorio con C ++ 11 habilitado. Nada mas.

Pero los ejecutables como bin / basename.exe compilados con -posix funcionan bien siempre que copie los archivos DLL necesarios en el directorio bin (gracias, Windows, por no tener RPATH). No he encontrado una manera de a) dejar que cmake encuentre el directorio dll + b) apuntar wine al directorio dll.
Pensé que la vinculación estática funcionaría, pero luego la compilación falla con símbolos duplicados durante la vinculación de elektra dll. Porque el dll ya tiene los símbolos incluidos.

@ markus2330 Me las arreglé para que elektra compilara con mingw + ejecutándose con wine sin copiar ningún dlls. El truco consiste en habilitar siempre la vinculación estática para los objetos ejecutables Y compartidos ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ").

Para solucionar los símbolos duplicados, he añadido versiones de scripts para libelektra y libelektratools. De esta manera solo se exportan nuestros símbolos.

Esto funciona muy bien. p.ej

$ 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

Incluso funciona bin / cpp11_benchmark_thread.exe.

Otras cosas simplemente fallan:

$ 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)
[...]

En este momento, simplemente agregué las cosas del script de versión sin pensar en otros compiladores. ¿Continuaré con mi trabajo o no me interesa?

se bloquea en src / plugins / wresolver / wresolver.c porque pk-> filename es NULL

pk es de tipo resolverHandles.user

Traté de echar un vistazo al complemento pero no entiendo el ciclo for en elektraWresolverOpen . El bucle llama a elektraWresolveFileName -> elektraResolve{Spec,Dir,User,System} que todos malloc resolverHandle->filename y por lo tanto filtran memoria.

¡Gracias por señalar eso! El código está obviamente roto desde la introducción en c87ae8e87a716b02b2c7ed790ad56a89d95547a9
Solo durante el bucle y siempre, se inicializó el identificador del sistema. Esto provoca bloqueos cuando se utiliza otro espacio de nombres.

Lo arreglé en
edb4d50856bb5331749220de5a83fa2062624a9d

Acerca del trabajo continuo: Por un lado, sería bueno si el material compilado también se ejecuta. Por otro lado, el lanzamiento debería ocurrir este fin de semana, por lo que una solicitud de extracción sería importante pronto (debería haber al menos la posibilidad de un círculo de retroalimentación corto, por ejemplo, lo que realmente hacen los scripts de versión)

Pero en mi humilde opinión, es suficiente si solo funciona una variante (la compilación estática). ¡Es genial ver la herramienta kdb en ejecución!

¿Dónde puedo encontrar edb4d50856bb5331749220de5a83fa2062624a9d?

edb4d50856bb5331749220de5a83fa2062624a9d se envió un poco más tarde.

¿Qué versiones de gcc están instaladas en debian-unstable-mm?

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

dice que no hay gcc-5.2

¿Puede instalar tantos compiladores como sea posible, por favor?

En algún número o PR, he dicho que eliminé todos los compiladores excepto el último.
Editar: gcc 4.9 en estable, 4.9 + 5.x (predeterminado) en inestable

Realice este tipo de pruebas (las encuentro muy innecesarias de todos modos) en sus propios contenedores. El mío no se quedará para siempre de todos modos.

No he leído eso. Tienen tal vez 50 MB cada uno. ¿Podrías instalarlos de nuevo y responder la primera pregunta?

Quizás te lo dije en nuestra reunión. Pero definitivamente te lo dije.

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

El binario específico de la versión se llama gcc-5. Ya no hay un paquete separado para versiones menores. Entonces, su multiconfig-gcc con este nivel de detalle está algo obsoleto. Recomiendo eliminar gcc 4.7 y reemplazar gcc-5.2 con gcc-5 y listo.

El único compilador adicional disponible que no he instalado es gcc-4.8. Y gcc-4.8 ya ha sido etiquetado para su eliminación.

Gracias por la info! Parece que los días de gloria de muchos compiladores disponibles han terminado.

Arreglé multiconfig-instable.

Cerraré por ahora, gracias por la excelente configuración del agente.

Hola, jessie (estable) necesita algunos paquetes más. ¿Podrías instalar:

• [] fakeroot
• [] gpg (+ crear clave para Autobuilder [email protected])
• [] reprepro (tal vez ya esté instalado, el script no llegó tan lejos)

fakeroot instalado, gpg + repropro ya está instalado.
¿Me pueden enviar su clave gpg ya existente? Entonces, ambas máquinas de construcción tienen el mismo

Está bien tener diferentes claves gpg. No estoy seguro de si la configuración actual los usa, así que primero espere si http://build.libelektra.org : 8080 / job / elektra-git-buildpackage-jessie / 2 / falla.

• debhelper + libsystemd-journal-dev instalado
• python-dev es una dependencia incorrecta. debería ser python2.7-dev o python3-dev o ambos
• ¿Por qué necesitamos soporte para Python?

¡Gracias por la instalación!

python-dev está disponible para Jessie, y python-support también. Instálelos.

Lo probé localmente, cuando se instalan estos paquetes, se compila para jessie.

Claro, está disponible, pero es una dependencia incorrecta. python-dev depende de python2.7-dev, que _no_ es suficiente. En su lugar, se requiere python2.7-dev + python3-dev.

Python-support no se requiere en absoluto en mi humilde opinión.

No sé por qué se eligieron las dependencias de esta manera, la mayor parte del empaque fue realizado por @iandonnelly durante gsoc.

Sí, los paquetes también deben actualizarse para crear enlaces de python3. Actualmente, simplemente no está hecho. Sin embargo, puede instalar python3-dev, para que la compilación no se rompa (cuando se agregan enlaces + complementos de python3 al paquete debian).

Eso no significa que sean correctos :-) - Estoy bastante seguro sobre los departamentos de python-dev.
¿Puede reemplazarlos y eliminar el depósito de soporte de python?

python3-dev y python2.7-dev ya están instalados. De lo contrario, no se construiría ningún enlace.

Por cierto. el paquete oficial de Debian de @pinotree compila solo python3. Sería una pérdida de tiempo arreglar lo que hay en nuestra rama "debian", el trabajo de @pinotree es superior de todos modos.

Cuando tenga tiempo, actualizaré nuestra rama "debian" a lo que @pinotree ha hecho en el paquete oficial. Él ya nos permitió hacerlo. Esperaré la actualización de qt-gui, actualmente no hay prisa por cambiar. Y tener soporte para python2 sería importante para una instalación (donde se usa cheetah, que no funcionará con python3).

Nunca dije que eliminaría los paquetes de python2. Todo lo que digo es que python-dev es una dependencia inexacta. Requerimos versiones explícitas. Entonces, pythonX-dev es la depuradora correcta para usar.

Con suerte, Pinotree resolvió la dependencia correctamente.

Por cierto, el guepardo está muerto. No lo use.

Ok, lo reemplazó. Revierta b7c266b36b0ab0fad9120e67a457b580c7c44690 e instale python-support si es necesario después de todo.

Estoy seguro de que Pinotree lo hizo correctamente;)

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

instalado

python-dev es una dependencia incorrecta. debería ser python2.7-dev o python3-dev o ambos

• python-dev instala el paquete de desarrollo para la versión predeterminada de Python 2; desde Wheezy, esto es Python 2.7
• python3-dev instala el paquete de desarrollo para la versión predeterminada de Python 3; Python 3.2 en Wheezy, 3.4 en Jessie y hasta ahora 3.4 en Stretch (supongo que pronto será 3.5)

Por lo tanto, si desea compilar contra la versión predeterminada de Python 2/3, use respectivamente python-dev / python3-dev , no las versiones pythonX.Y-dev (que debe usar cuando explícitamente quiere una versión precisa de Python instalada, incluso si no es la única instalada en el sistema, y ​​no la predeterminada). Usar cualquiera es lo que recomiendo.

desde python-dev descripción:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

De acuerdo con este texto, python-dev seguramente puede depender de python3 pronto

Más aún: nunca habrá otra versión de python2. Entonces, python2.7-dev será el último paquete de desarrollo de python2.

Dependiendo de python3-dev es lo que dije.

Ahora solo falta la clave:

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

hecho

¡Gracias!

Exporte / home / jenkins / repository a través de http.

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

→ http://194.117.254.29/elektra-stable/

@manuelm ¿Podrías instalar ronn en los agentes? (necesario para generar páginas de manual)

apt-get install ruby-ronn

hecho

Gracias, los paquetes de jessie se compilan de nuevo y ahora se incluyen las páginas de manual.

Instale musl, es decir

apt-get install musl musl-dev musl-tools

¡Gracias!

musl instalado y agends actualizados

Dos cosas importantes sobre el servidor de compilación:

1. No cree nuevos trabajos vacíos, sino que los duplique, tienen la configuración correcta (excepto lo mencionado en el número 2).
2. Deberíamos usar clones de referencia (en / home / jenkins / libelektra) o preferir clones superficiales para cada trabajo de compilación (actualmente solo se hace para algunos, por ejemplo, elektra-clang). Actualmente, el tráfico es> 300 MB en confirmaciones debido a la gran cantidad de reclones innecesarios.

@mpranj Sería genial si pudieras arreglar 2.

@ markus2330 solo para asegurarme: debería aplicar el mismo comportamiento de clonación a todos los trabajos de compilación como en elektra-clang ?

Clones superficiales aplicados a todos los trabajos de construcción excepto :

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-wheezy
• [] elektra-multiconfig-gcc-stable
• [] elektra-multiconfig-gcc-inestable
• [] prueba-paquete-fuente-elektra

Estos trabajos se extraen de algún subdirectorio. No estaba seguro de lo que querías allí, así que los dejaré como están por ahora.

¡Gracias! Sí, necesitan un historial completo y ramas, los clones superficiales no tienen sentido, pero el repositorio de clones de referencia sería útil.

Jenkins se actualizó a 1.651.2. También se actualizaron todos los complementos.

Mantendré el problema abierto para los repositorios de clones de referencia. También deberíamos tener "trabajos cron" que actualicen los repositorios de vez en cuando, idealmente usando jenkins.

Jenkins dejó de construir algunos trabajos (aparentemente desde la actualización). Falla con
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Gracias por la info. Intento degradar el generador de solicitudes de github de 1.31 a 1.14.

Ahora parece atascado al establecer el estado de compilación para la confirmación de Github. Advierte que esto está obsoleto en la configuración.

También intenté degradar cada complemento con *git* en su nombre, pero luego todavía había errores (error extraño relacionado con el complemento Mailer, la degradación del complemento Mailer no ayudó). Así que volví a actualizar todo a las versiones recientes. El problema parece ser un problema conocido aguas arriba:

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

Espero que lo arreglen pronto.

Otra pregunta: ¿Alguien sabe cómo ejecutar varios trabajos para cada RP? (Me gustaría ejecutar tanto elektra-mergerequests-stable como elektra-mergerequests-instable)

El trabajo elektra-test-bindings funciona bien con compilaciones parametrizadas (como también se describe en el ticket ascendente). ¿No podríamos simplemente cambiarlo a compilaciones parametrizadas? El error se ha informado en sentido ascendente durante un tiempo, no veo que se solucione pronto.

Buena idea, podríamos cambiar todos los trabajos de relaciones públicas a compilaciones parametrizadas, en realidad solo tiene ventajas. También nos permite ejecutar los trabajos manualmente especificando una rama. Y también se puede utilizar para trabajos de construcción habituales.

Idealmente, todos los trabajos también podrían ser ejecutados por github PR. (Excepto aquellas específicamente para tareas no relacionadas con relaciones públicas que actualizan la documentación o la cobertura de la sucursal maestra)

Una desventaja de la configuración de elektra-test-bindings es que solo realiza sondeos y tarda bastante en comenzar a compilarse (hasta 5 minutos). Sin embargo, no quiero activar "Usar ganchos de github para activar la compilación" para no romper el trabajo de compilación.

Por cierto. ¿Estás seguro de que la opción "clonación superficial" está bien para los trabajos del generador de solicitudes de extracción de github?

Me pregunto cómo elige github el trabajo de compilación que usa para los nuevos RP. ¿Por qué las solicitudes elektra-test-bindings y elektra-ini-mergerequests nunca se seleccionan para un nuevo PR? ¿Por qué a veces es elektra-mergerequests-inestable y otras veces elektra-mergerequests (-stable)?

@manuelm tienes alguna idea?

Por cierto. de alguna manera, la comunicación de los trabajos de compilación terminados y github se ve gravemente afectada (incluso para elektra-test-bindings). Ahora dice en casi todas las compilaciones "Algunas comprobaciones aún no se han completado".

Una desventaja de la configuración de elektra-test-bindings es que solo realiza sondeos y tarda bastante en comenzar a compilarse (hasta 5 minutos).

¿Y esto es un problema porque? De todos modos, las pruebas tardan más de 5 minutos.

¿Por qué las solicitudes elektra-test-bindings y elektra-ini-mergerequests nunca se seleccionan para un nuevo PR?

¿Por qué debería hacerlo? elektra-test-bindings se activa solo con la "Frase de activación". No tengo idea de lo que es elektra-ini-mergerequests .

¿Por qué a veces es elektra-mergerequests-inestable y otras veces elektra-mergerequests-estable?

Los -estables / -instables son nuevos? No estoy seguro de que sea posible activar varios trabajos por nuevo RP. Haría trabajos secundarios.

Por cierto, ya he dicho esto varias veces, pero creo que la cantidad de trabajos se está volviendo ridícula y una señal de una configuración desordenada. Pero criticar siempre es más fácil que resolver algo.

Los 5 minutos son un problema cuando desea depurar el servidor de compilación. Y todavía espero que obtengamos una primera prueba rápida en algún momento, que demorará unos 5 minutos.

Ahh, ok, me perdí la opción "Usar solo frase de activación para la activación de compilación". La configuración para el generador de solicitudes de github es realmente un desastre.

Alguien habló sobre proyectos de github en los que tienen varios trabajos en ejecución para cada RP. (Mostrado individualmente)

¿Qué es un subtrabajo? ¿Te refieres a multitarea ?

Alguien habló sobre proyectos de github en los que tienen varios trabajos en ejecución para cada RP. (Mostrado individualmente)

Tendrá que agregar dos servicios en github.

¿Qué es un subtrabajo? ¿Te refieres a multitarea?

Sí, multitarea.

por cierto, ¿qué pasa con https://docs.travis-ci.com/ ? Travis tiene soporte para OSX.

Sé que no reemplazará a jenkins, pero podría reemplazar el PR / en cada compilación de confirmación. Jenkins todavía puede hacer las pruebas de múltiples compiladores / etc.
Editar: Travis incluso tiene gcc + clang.

De acuerdo, sería interesante usar la energía / electricidad de su CPU de forma gratuita, ya que elektra es de código abierto.

Es probable que la conexión entre github y jenkins sea en realidad 1: 1. En el servicio de github ingresé http://build.libelektra.org : 8080 / github-webhook / y no encontré una manera de crear otra URL en jenkins. (Solo encontré una forma de especificar una anulación, pero esto no creó una nueva URL).

En https://github.com/janinko/ghprb/issues/142 discuten que debería "simplemente funcionar". (Sin agregar múltiples servicios)

Sin embargo, el problema sha1 debería resolverse ahora. Se rompió porque Jenkins introdujo una nueva medida de seguridad que elimina las variables de entorno desconocidas. Me fijo como sugeridas (añadido -Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit, ghprbActualCommitAuthor, ghprbActualCommitAuthorEmail, ghprbAuthorRepoGitUrl, ghprbCommentBody, ghprbCredentialsId, ghprbGhRepository, ghprbPullAuthorEmail, ghprbPullAuthorLogin, ghprbPullAuthorLoginMention, ghprbPullDescription, ghprbPullId, ghprbPullLink, ghprbPullLongDescription, ghprbPullTitle, ghprbSourceBranch, ghprbTargetBranch, ghprbTriggerAuthor, ghprbTriggerAuthorEmail, ghprbTriggerAuthorLogin, ghprbTriggerAuthorLoginMention, GIT_BRANCH, sha1 a / etc / default / jenkins).

Acerca del uso de servidores de compilación adicionales: Sí, adelante. También resuelve el problema de múltiples trabajos de compilación para un solo PR;) Nunca usé travis-ci, así que no puedo decir nada al respecto. Le di permiso para que Travis tenga acceso a ElektraInitiative.

Primera compilación de travis: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Creo que necesitamos un archivo yaml para que Travis sepa qué hacer.

Y descubrí cómo hacer varios trabajos de Jenkins por RP, se necesitaba un contexto diferente para cada trabajo de construcción. En la próxima reunión discutiremos lo que deberían hacer los trabajos de construcción "rápidos" y otros.

Estoy trabajando en Travis (o comprobando algunas cosas)

Divertirse. Travis también agregó un servicio github, así que supongo que también se creará un PR con travis.

Ya estoy jurando en voz alta

- NO se pudo encontrar JNI (falta: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
- Excluir el complemento jni porque no se encontró jni

No puedo configurar correctamente el complemento de Java. Sin embargo, los enlaces de Java funcionan. En debian inestable. ¿Algunas ideas? Mirar el módulo cmake no ayuda mucho.

Editar: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h y /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h están en su lugar

Edición 2: Entendido. JAVA_HOME = / usr / lib / jvm / java-1.8.0-openjdk-amd64 / ....

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

Debian inestable construido dentro de un contenedor docker. Pero construir lleva años.
¿Alguna buena idea?

clang es a menudo más rápido con respecto al tiempo de compilación, pero creo que la instalación de las dependencias es lo que lleva una gran cantidad de tiempo

¿No hay una imagen de la ventana acoplable de Debian más mínima que la que se usa? Parece que se instalan muchos paquetes que no deberían ser necesarios.

@sirblackheart ¿Qué te hace pensar eso? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm probablemente el dist-upgrade. se actualizan muchos paquetes que son específicos de escritorio como wayland

No. La actualización de dist es corta. tal vez un minuto. aproximadamente el 50% del tiempo se toma instalando los departamentos de construcción.

Estoy enviando la imagen de compilación a hub.docker.com ahora mismo. Espero que eso acelere las cosas. Pero la imagen tiene 1,9 gb

Tiempo transcurrido 14 min 8 seg

No estoy seguro si podemos hacerlo mucho mejor

como dije, el clang tal vez nos lleve 2-3 minutos. al menos lo hace para el proyecto aseprite
https://travis-ci.org/aseprite/aseprite

Sería útil tener ambos compiladores de todos modos.

Acabo de tener una idea mientras preparaba el trabajo: ¿Qué pasa si extraemos las rutas de todas las confirmaciones en la solicitud de inserción y construimos enlaces / complementos solo si se ven afectados? p.ej

• el cambio en cmake / * activa todo (complementos + enlaces)
• cambio en src / bindings / foo desencadena el enlace foo
• cambio en src / plugins / foo desencadena el plugin foo
• el cambio en todo no compila complementos + enlaces

Todavía tenemos la versión completa diaria / dos veces al día de jenkins.

@manuelm buena idea, @ tom-wa escribiría un script de este tipo, ¿puedes crear un nuevo problema para esto?

@mpranj : Recordatorio: agregue compilaciones de Mac OS X a travis y agregue compilaciones de mingw a PR. (* BSD parece ser más esfuerzo)

@ markus2330 ahora entiendo el enfoque de @manuelm docker, travis no admitirá ubuntu 16.04 hasta el próximo año, por lo que se necesita docker para obtener todas las dependencias que ubuntu 14.04 no tiene = swig3.0 libsystemd-devel.

Lamento no haber podido asistir a la reunión de hoy. En el trabajo, todavía estamos preparando una gran implementación de software hoy, así que no puedo salir de la oficina. Pero en un breve lapso puedo responder correos electrónicos.

Comencé a agregar compilaciones de OS X para travis hace 2 días: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
La compilación está aquí: https://travis-ci.org/manuelm/libelektra/builds/130898079
Abra las cosas aquí:

• [] cryto_openssl no se puede compilar
• [] las pruebas de enlaces fallan
• [] no java

Estoy feliz si alguien asume mi trabajo desde aquí. No tengo OS X y esperar a que Travis inspeccione el sistema OSX se resume muy rápido.

re: docker: Sí, la versión predeterminada de ubuntu de travis no funciona bien. Incluso cmake es demasiado viejo.
Obtener la imagen de la ventana acoplable cargada solo lleva unos 3 minutos. Y agregar más imágenes es una obviedad. Así que creo que es una buena manera de solucionar cualquier problema que tenga el entorno predeterminado de travis linux (o que pueda tener después de una actualización).

No he descubierto una buena manera de integrar las diferentes fases de compilación y prueba de libelektra (cmake + make + make test) con docker (build + run) + travis (before_install, before_script, script). Los contenedores de Docker salen después de que se completa el comando. Dado que los contenedores de la ventana acoplable están destinados a ser desechados, no puede reanudarlos después. Por lo tanto, su estado de disco / compilación desaparece, a menos que monte un directorio local en el contenedor. Continuará trabajando en Docker la próxima semana.

@manuelm Genial, llegaste más lejos de lo que pensamos. Mac OS X para relaciones públicas y por compromiso sería realmente genial. Mucha gente está usando Mac OS X ahora y no quiero romper la compilación una y otra vez. En la reunión de hoy @mpranj dijo que recogería tu trabajo. ¿Quieres crear un PR con el archivo travis?

No, ya que el archivo travis aún debe modificarse posteriormente. De lo contrario, solo compilará OS X. Preferiría que @mpranj tomara mi archivo travis y solucionara los problemas restantes relacionados con OSX. Luego tomaré su archivo travis, lo convertiré en una compilación de matriz e integraré las compilaciones de linux / docker + # 730 (si está disponible para entonces)

PD: haga las pruebas de Travis en un repositorio con espacio de nombre de usuario. Harás muchos empujones :-)

mingw64 se basa en PR agregado, debería funcionar. Pido disculpas por la demora. ¡Examinaré a Travis hoy!

¿Existe una desventaja de permitir que los trabajos de compilación se activen con una frase en un PR (con el constructor de PR de Github)?

Me gustaría configurar los trabajos desde el n. ° 745 para poder probar si lo arreglé, pero puedo aplicarlo a la mayoría / (todos) los trabajos de compilación.

EDITAR: Preferiría no iniciar automáticamente todos los trabajos, ya tenemos bastantes.

Creo que es una buena idea si podemos configurar cada trabajo para que se active con una frase. Creo que hay una pequeña desventaja (al menos para elektra-test-bindings): tienes que ingresar para qué rama quieres construir y no puedes simplemente presionar "construir trabajo ahora". Sería genial si encuentra una solución para eso.

Y tiene razón en que deberíamos reducir los trabajos automáticos.

De hecho, existe una solución muy sencilla. Estamos usando la variable (env) sha1 para construir PR. Las compilaciones parametrizadas le solicitan el valor, ya sea que se establezca un valor predeterminado o no.

Solución: establezca la variable env sha1 en master (en la propia configuración de jenkins) y deshabilite las compilaciones parametrizadas. Si no hay ninguna objeción a configurar la variable, esto resolvería exactamente lo que mencionó anteriormente @ markus2330.

Ya lo configuré, por lo que puede presionar ese botón de compilación en, por ejemplo, elektra-mergerequests y comenzará a compilar master.

Sí, esta es una muy buena solución, me gusta. También nos permitiría construir una rama de lanzamiento con un solo conmutador (si lo necesitamos en el futuro). Hasta entonces, "maestro" es siempre la elección correcta si no se ejecuta desde dentro de un PR.

Creo que también resolvería el problema de la variable de entorno filtrada, que teníamos antes.

Entonces también podemos pensar en reducir los trabajos de construcción (sin duplicación para trabajos bulid -mergerequest) y un nuevo esquema de nomenclatura consistente. (Se pueden hacer sugerencias aquí.) Puede que haya un problema abierto: actualmente creamos coberturas, documentos, .. tanto para RP como para master y los copiamos en lugares separados. Si fusionamos los trabajos de construcción, necesitamos una forma de distinguir dentro del trabajo maestro / PR-trabajos para copiar la cobertura, docu en diferentes lugares.

Ya casi terminé de aplicar esto a todos los trabajos (pero el servidor se volvió muy lento).
No se aplicó a trabajos que crean comodines ** (doc y algunos otros, pero muy pocos)

Siempre puede detener la creación de trabajos cuando desee trabajar en ellos si los reinicia más tarde (excepto en el tiempo de lanzamiento). Por lo general, Jenkins es el motivo de la desaceleración de la máquina. Por el momento, un rsync de una copia de seguridad puede ser el problema, pero es urgente.

Sí, no hay problema en absoluto, debería hacerse, pero haré algunas últimas comprobaciones.

Las noticias @ ElektraInitiative / elektradevelopers:

• como se mencionó, casi _todo_ se puede construir ahora desde los RP y / o presionando solo el botón de construcción
• las frases de activación son siempre el nombre del trabajo sin el prefijo elektra- . (por ejemplo, Elektra-clang: Jenkins acumulación sonido metálico por favor) No cambié jenkins build please y otras frases de edad por razones de compatibilidad
• el mensaje de estado de compilación de github es siempre exactamente el nombre del trabajo de compilación

¡Gracias, bien hecho! Actualice doc / GIT.md para que todos sepan qué frases funcionan ahora.

(Espero que @mention funcione para un solo mensaje y que no todos lean todos los mensajes que escribimos aquí)

Mac OS X para la compilación xcode 6.1 parece estar roto:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

Activé una reconstrucción para ese, pero me parece una falla temporal de Travis.

¿Puede documentar cómo reactivar una compilación para un PR? No sabía que era posible.

Directamente en travis-ci.org, usando su enlace de arriba:

Dudo que esto sea digno de un documento, pero puedo hacerlo de todos modos.
La compilación todavía no funciona únicamente debido a git checkout. No creo que esto sea culpa nuestra.

Ah. Creo que lo fusionó antes de que se activara / iniciara la compilación en primer lugar.
Cuando reconstruyo otros RP previamente exitosos, también se rompe.

Este es más un problema de Travis que cualquier otra cosa.

Ok, gracias por investigar.

@manuelm debian-stable-mm parece inalcanzable (tanto para jenkins como para mí desde la red TU). ¿Podrías 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 alguien detuvo el contenedor. Lo he comenzado de nuevo.

Por cierto, a partir de mañana por la mañana estaré fuera de casa hasta el 1 de agosto. Todavía estoy disponible por correo electrónico, pero espero un pequeño retraso.

¡Gracias por la solución rápida! Así que supongo que tampoco estarás aquí para las próximas reuniones.

sí

Algunos trabajos tienen el error:

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 ejemplo, http://community.markus-raab.org : 8080 / job / elektra-icheck / lastFailedBuild / console http://community.markus-raab.org : 8080 / job / elektra-doc / lastFailedBuild / console

¿Puede ser causado por una actualización de jenkins o @KurtMi creando la kdb_import_man ?

Nota para mí: es necesario instalar cppcms.

Lo siento por la sucursal, me enojé con un PR directo en la página de github.

¿Es más fácil crear relaciones públicas de esta manera? ¿No ofrece github eliminar la rama después de fusionarla?

El cambio fue tan mínimo, así que me volví perezoso. Para arreglos muy pequeños, sí, pero aparentemente la rama no se eliminará después. No he visto ninguna rama de eliminación después de la fusión.

Creo que la construcción inestable está rota:

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

Registro completo

@KurtMi trabajo inestable de nuevo (entre la mayoría de las compilaciones), pero el error Walk persiste en algunas de las tareas de compilación más simples. Parece que la rama todavía está disponible en algún lugar, ¿tal vez en un caché en los servidores de compilación?

 > 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 Tal vez deberíamos agregar más scripts en la fuente, esto permitiría actualizaciones más fáciles para cada trabajo de compilación. En # 806 encontramos otro error con espacios en el directorio de compilación, por lo que deberíamos agregar globalmente (para cada trabajo de compilación) agregar espacios en el directorio de compilación. Preferiría si pudiéramos agregar un script jenkins-setup que exporte algunas variables útiles (como export HOME="$WORKSPACE/user space ) y no

mkdir "build space"
cd "build space"

Además, deberíamos crear trabajos de construcción que actualicen un repositorio global. Tareas individuales ver arriba.

El repositorio global definitivamente podría ayudar a reducir el ancho de banda. La compilación de scripts en el código fuente también podría ser una buena idea, al menos git los rastrearía.

No soy fanático de los espacios en los caminos, pero seguro.

construcción rápida en passwd roto?

El trabajo de compilación rápida es molesto, trato de eliminar kdberrors.h en cada compilación y veo si funciona mejor en ese momento. A largo plazo, la propuesta de @manuelm en el n. ° 730 es la mejor solución: simplemente debemos verificar cómo se actualizó la fuente y, en base a esto, tomar las medidas adecuadas.

Creo que el # 894 también corrige la compilación rápida, comentaré la línea que elimina kdberrors.h.

Algunos trabajos no funcionan, por ejemplo, el trabajo de documento html.

@mpranj ¿Tienes tiempo para mirarlo?

@ markus2330 Hecho. Las fallas de compilación restantes no parecen estar relacionadas con el sistema de compilación.

@mpranj ¡ Gracias! ¿Qué hiciste para arreglarlo? Creo que sería útil recopilar aquí también soluciones para crear problemas de servidor.

Cambié en "Administración de código fuente"> "Git"
"Especificador de rama" valor "**" a "$ {sha1}"

Esto es lo que usamos también en los otros trabajos. Esto permite activar la compilación por botón (la rama predeterminada es maestra) o por el constructor de relaciones públicas de github (sha1 de confirmación).

Recuerdo haber configurado la variable ENV "sha1" en "maestro" una vez. Parece que falta ahora, pero los trabajos funcionan bien, así que ignorémoslo.

Creo que podríamos acelerar las compilaciones mucho más si usamos Bibliotecas de objetos con más frecuencia. Muchos archivos de objetos se compilan varias veces. Solo tendríamos que asegurarnos de que los indicadores de compilación sean los mismos para todos los lugares en los que usamos las bibliotecas de objetos, pero supongo que esto debería ser fácilmente posible.

En mi opinión, un ejemplo en el que podría marcar una gran diferencia es KDB.

@Namoshek Por favor, publique solo cosas de compilación de _servidor_ aquí, no sobre el sistema de compilación en general. Las bibliotecas de objetos ya se utilizan para complementos, pero para diferentes variantes se necesitan, sin embargo, diferentes bibliotecas de objetos (debido a las diferentes marcas del compilador). Pero, por favor, informe las sugerencias concretas como un tema aparte (¿se refiere a herramientas kdb?).

Jenkins se actualizó a 2.7, todos los complementos se actualizaron, se agregaron los complementos recomendados:

• Pipeline (¿la instalación parece haber fallado?)
• Complemento de carpeta de organización de GitHub

y algunos complementos desinstalados:

• API de sucursal
• CVS / SVN (parece que ya no es esencial)

Además, se instaló ruby-dev en todos los agentes.

Actualicé los "Problemas actuales" en la publicación superior. Sería importante que Elektra también compile sin ninguna dependencia instalada, por lo que deberíamos verificar esto con agentes de servidor de compilación que no tengan ninguna dependencia instalada (excepto cmake y build-essential). Los agentes de compilación FreeBSD y OpenBSD, sin embargo, también son importantes;)

@mpranj ¿Tiene alguna idea de lo que está mal con elektra-multiconfig-gcc47-cmake-options? Tienen errores "fatal: la referencia no es un árbol:" por todas partes. ¿El trabajo tiene "sha1" en su configuración?

Hice que el multiconfig fuera independiente de los compiladores concretos (hay suficientes otros trabajos de compilación para compiladores específicos), por lo que deberían poder ejecutarse en cualquier agente.

@ markus2330 No

• activó manualmente una compilación desde el maestro
• desencadenó una compilación desde github

Ambas construcciones pudieron ver el árbol y comenzar a construir.
Entonces: no puedo reproducirlo.

Una idea: Travis tenía problemas cuando había un PR y lo fusiona antes de que Travis pudiera hacer el clon. Tal vez sucedió algo similar con elektra-multiconfig-gcc47-cmake-options ya que una compilación allí toma ~ 3 horas.

Enviar artefactos a doc.libelektra.org funciona nuevamente, Jenkins y los complementos se actualizaron.

Actualicé la nueva URL del servidor de compilación https://build.libelektra.org en los Webhooks de github. Por tanto, es de esperar que los próximos RP se vuelvan a construir.

La casa de Jenkins está casi llena. Tampoco parece estar construyendo relaciones públicas.

La casa de Jenkins está casi llena.

Gracias, lo cambié de tamaño.

Tampoco parece estar construyendo relaciones públicas.

¿Tiene alguna idea de lo que podría estar mal aquí? ¿El disparo manual parece funcionar?

Publicando documento en doc.libelektra. org: 12025 falló para las compilaciones. Reinicié el servidor ssh (en el agente de la página de inicio de compilación) y parece funcionar de nuevo.

El vserver para * .libelektra.org parece no ser accesible. Lo informé en Hetzner.

La razón para cerrar la conexión de red desde el contenedor fue que libelektra.org está comprometido. Consulte el n. ° 1505 para obtener más información.

Sería genial si pudiéramos agregar un paquete git-build-package para stretch, cada vez aparecen más lugares donde necesitaríamos paquetes de Debian construidos para stretch.

@BernhardDenner, ¿ @mpranj deba considerar al mejorar los trabajos de creación de servidores en el futuro?

Según lo solicitado por @sanssecours , @KurtMi

jenkins construye gcc-configure-debian-optimizations por favor

@KurtMi Si necesita cambios en lo que hace el trabajo de compilación, simplemente modifique los scripts / configure-debian-optimizations

@sanssecours ahora también tiene acceso al servidor de compilación.

Por cierto. puede cancelar trabajos si son reemplazados por otros trabajos de todos modos (actualmente hay una carga pesada). Solo tenga cuidado de no abortar trabajos para relaciones públicas activas, de lo contrario, las relaciones públicas no se volverán ecológicas. (A menos que los reinicie con la frase "compilación de jenkins ... por favor").

@sanssecours Jenkins se reinició (la segunda vez). ¿Podría documentar aquí si instala nuevos complementos? (No es necesario documentar las actualizaciones).

Las solicitudes de reinicios también se pueden realizar aquí.

Cambié "Quiet period" de 2 a 5 para dar más tiempo para fusionar múltiples PR y / o impulsar diferentes confirmaciones sin reconstruir repetidamente.

Además, abrí el número 1689 que describe los tiempos de espera en las compilaciones (no lo agregué aquí debido a los largos mensajes de error).

También moví algunas tareas obsoletas arriba en la nueva sección "Problemas obsoletos / irrelevantes [motivo]:".

Actualicé los complementos en el servidor de compilación. Con suerte, las actualizaciones solucionan los problemas que tenemos en PR # 1698 y PR # 1692.

@ markus2330 ¿Puede reiniciar el servidor de compilación?

Actualicé Jenkins de 2.73.2 a 2.73.3 y reinicié Jenkins.

Con suerte, las actualizaciones solucionan los problemas que tenemos en PR # 1698 y PR # 1692.

¿Podría ser un problema general no relacionado con estos dos RP? Ojalá esté arreglado ahora.

Parece que JENKINS_HOME está casi lleno 😢.

@ markus2330 👋 ¿Podrías por favor?

• limpiar el directorio de inicio o decirme cómo puedo hacerlo,
• actualizar Jenkins y todos los complementos obsoletos?

¡Gracias por enviarme un ping!

Parece que un complemento tenía una "vulnerabilidad de lectura de archivo arbitrario", a saber, el "Complemento de seguridad de secuencia de comandos 1.35".

Actualicé todos los complementos y también actualicé jenkins de 2.73.3 a 2.89.1.

Además, cambié el tamaño del disco de 20 GB a 50 GB.

Deberíamos reiniciar el servidor pronto, hay algunos procesos no reiniciados que podrían verse afectados por las actualizaciones de la biblioteca, que podrían ser inseguros en este momento (aunque no relacionados con jenkins). @BernhardDenner ¿Puede reiniciar (y hacer las correcciones si algo no se inicia)?

Por favor, no dude en reportar cualquier falla que tenga durante estas actualizaciones.

El servidor tenía una carga de 20 y apenas respondió. Debemos tener cuidado con "jenkins build all please" y, a largo plazo, deberíamos alejar a los agentes del servidor principal.

Actualicé a Jenkins 2.89.2 y reinicié el servidor. Informaré cuando todo vuelva a funcionar.

Parece que todos los agentes están ahora desconectados con el error "La devolución de llamada del verificador no aceptó la clave de host del servidor".

@BernhardDenner Vi que la aplicación de títeres se estaba ejecutando, ¿estás trabajando actualmente en la configuración?

Intenté degradar a 2.89.1 y 2.73.3 sin éxito: la conexión con los agentes aún no funciona.

Un gran agradecimiento a @BernhardDenner que solucionó el problema de ssh.

Deberíamos dejar de actualizar Jenkins sin leer las notas de la versión, parece que incluso las actualizaciones estables rompen demasiadas cosas. (¡Que ni siquiera son revertibles al degradar!)

Tengo que informar de un cuello de botella importante en el servidor de compilación.
elektra-multiconfig-gcc47-cmake-options tarda 14 horas y el
elektra-multiconfig-gcc-stable tarda 4h.
No estoy seguro de si ese es un comportamiento nuevo y soy consciente de que estos trabajos no son un solo trabajo de construcción, pero este cuello de botella no debe pasar desapercibido.

Gracias por informar. La idea era distribuir subtareas de estos trabajos al hardware ryzen, desafortunadamente nadie tuvo tiempo para la configuración. Si alguien está interesado, por favor contácteme.

a7.complang.tuwien.ac.at (ryzen) parece haberse bloqueado. Informé del problema. Es de esperar que nuestro administrador reinicie la computadora el lunes.

Inhabilité temporalmente el incremental (error extraño, ver # 1784), el administrador reinició el servidor ryzen y luego reinicié jenkins (porque Jenkins no se pudo conectar a ryzen y había una gran acumulación de compilaciones ryzen).

Ryzen ahora funciona de nuevo y crea el trabajo pendiente.

La idea era distribuir subtareas de estos trabajos al hardware ryzen

@ markus2330 He notado que hay una opción llamada Run each configuration sequentially en la configuración de la matriz de configuración del trabajo multiconfig. Tal vez se distribuya automáticamente si simplemente desmarcamos esto para que compile varias opciones de configuración a la vez, ¿o ya lo ha intentado?

No, no lo he probado, por favor pruébalo.

@ markus2330 a juzgar por la cola del servidor de compilación, esto parece funcionar, lo aplicaré a gcc-stable además después de que funcione para gcc-stable-multiconfig

Sin embargo, noté que el Ryzen no parece manejar esos trabajos. Creo que esto se debe a que está configurado para manejar solo trabajos que coincidan con sus etiquetas y las compilaciones multiconfig no parecen establecer esas etiquetas de manera adecuada a primera vista. Por lo tanto, deberíamos hacer que ryzen ejecute todo lo que sea posible o establecer más etiquetas en los trabajos de compilación. Parece que Ryzen no maneja trabajos que no tienen ninguna etiqueta establecida.

Lo aplicaré a gcc-stable además después de que funcione para gcc-stable-multiconfig

¡Gracias!

Sin embargo, noté que el Ryzen no parece manejar esos trabajos.

No, no lo hace, pero ya ejecuta un montón de otros trabajos. ¿Pero tal vez podamos hacer v2 para hacerlo?

lo aplicaré a gcc-stable adicionalmente

hecho

¿Pero tal vez podamos hacer v2 para hacerlo?

He configurado la v2 y ahora solo espero a que se fusione el # 1806 PR para poder permitir más compilaciones que una. Pensé que 8 trabajos deberían estar bien para él, ya que es un 8-core, con -j 2 para utilizar el SMT también.

Para reiniciar el contenedor build-v2 en caso de que v2 se bloquee o se reinicie, simplemente escriba. Tenga en cuenta que esto solo se puede hacer si el contenedor ya se ha creado; siga doc / docker / jenkinsnode / README.md para obtener estas instrucciones. Luego, use este comando para reiniciar después de que se creó el contenedor pero se detuvo:

docker start build-v2

Además, para reenviar la conexión ssh del nuevo nodo de compilación desde la v2 a través de la a7 al mundo exterior, configuré el siguiente túnel ssh en la a7 (el contenedor de la ventana acoplable asigna su puerto ssh a 22222 en la v2):

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

Además, la clave ssh pública del contenedor de la ventana acoplable cambia en cada reconstrucción de imagen y, por lo tanto, también debe ajustarse en el servidor de compilación. Esto no es necesario si el contenedor solo se reinicia. Para averiguarlo, ingrese lo siguiente en la 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>

Solo copie las dos primeras cosas, por lo que el algoritmo de clave y la clave en sí, ¡no copie esta información de usuario al final de la configuración de ryzen-v2 en jenkins para la clave ssh!

v2 está inactivo, le informé al administrador. Es bastante extraño: a7 y v2 son hardware completamente nuevo y los incidentes son bastante frecuentes.

v2 parece haber vuelto y he reiniciado el contenedor de compilación allí. Así que, con suerte, ahora volvemos a tener compilaciones más rápidas. Además, he agregado elektra-haskell a "jenkins build all please", ya que quiero tener compilaciones haskell estables para mi comprobador de tipos, por lo que las pruebas son una buena adición.

Además, quiero dejar una nota aquí que, además, queremos crear otro nodo de compilación que se encargue de las compilaciones mm, que ahora también parecen ser el nuevo cuello de botella en la v2.

Por último, @ markus2330 creo que el comprobador de bashism de ejecución de puntos ya está hecho, ya que esta es una de nuestras pruebas habituales /testscr_check_bashisms.sh .

Todos los nodos de la etiqueta debian-jessie-homepage||homepage y el agente de compilación debian-wheezy-mr están actualmente fuera de línea. Reiniciar los agentes de compilación no funciona. Sería muy bueno si alguien con SSH o acceso físico a estos nodos pudiera investigar este problema.

Reinicié los vservers pero reiniciar los agentes dentro de jenkins no funcionó con el error "No se incluyó ninguna miga válida en la solicitud". @BernhardDenner ¿Tienes una idea?

Parece que la v2 también está inactiva. Entonces tenemos 3 agentes no funcionales 😢

v2 está de vuelta, pero me pregunto por qué siempre baja. ¿Podría estar relacionado con nuestro proceso de construcción?

Con respecto a la "migaja no válida", también vi eso cuando intenté reiniciar el agente en la v2, pero cuando simplemente lo intenté de nuevo, funcionó.

v2 está de vuelta, pero me pregunto por qué siempre baja. ¿Podría estar relacionado con nuestro proceso de construcción?

Parece ser una falla del kernel / hardware (ni siquiera sysreq funciona cuando la computadora se cuelga). Nuestro uso puede desencadenar el error. La computadora estuvo funcionando sin errores durante varios meses y desde que la usamos ya la fallamos tres veces.

Actualicé el kernel y purgué el servidor X.

Con respecto a la "migaja no válida", también vi eso cuando intenté reiniciar el agente en la v2, pero cuando simplemente lo intenté de nuevo, funcionó.

¡Gracias! Ahora pude volver a iniciar el agente de la página de inicio.

Además, desactivé el agente debian-jessie-minimal y su trabajo de compilación. Deberíamos crear contenedores docker para trabajos mínimos, agregué esto como tarea.

Como nos sorprendió ayer, el servidor de la comunidad estaba caído porque se bloqueó y una caché ARP incorrecta redirigió nuestras IP a otros servidores. Después de reiniciar, todo funcionó de nuevo, pero la sincronización de la incursión aún está en curso. (Puede que sea muy lento debido a la alta carga).

El servidor de la comunidad tiene una carga casi constante de 10. En este momento es 13,20 11,29 9,35. Realmente deberíamos reducir los trabajos que se ejecutan directamente en el servidor de la comunidad y mover la carga a v1. ¿Algun voluntario?

Hay una actualización de Jenkins de 2.89.2 a 2.89.4. Desafortunadamente, no encontré una manera fácil de ver el registro de cambios ( apt-get changelog falla porque es un paquete no oficial). ¿Alguna razón para no hacer esta actualización?

El registro de cambios ascendente está en https://jenkins.io/changelog-stable/
Aparentemente, 2.89.4 contiene correcciones de seguridad.

¡Gracias por buscarlo!

Actualicé a Jenkins 2.89.4 y todo está funcionando nuevamente.

elektrahomepage no se inició de forma predeterminada después de reiniciar, cambié eso (/ etc / vservers / elektrahomepage / apps / init / mark = default).

También activé el trabajo de compilación test-docker.

v2 está inactivo, de nuevo: llorar:

Pero al menos a7 parece estar estable ahora.

Instalé clang-format-5.0 en a7 y en el nodo stretch (debian-stretch-mr).

Para los próximos PR, vuelva a formatear de acuerdo con clang-format-5.0.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ se deshabilitó temporalmente.

Actualmente estamos investigando v2. UEFI es de 6.6.17. Parece que los accidentes siempre ocurrieron los fines de semana, ¿tal vez hay una carga más alta en ese momento? Intentaré replicar la configuración v1 en v2.

v1 y v2 están funcionando con el mismo kernel.

@ e1528532 parece que su puente ssh no se inició y el comando en doc / docker / jenkinsnode / README.md falla con "no se puede preparar el contexto: no se pueden evaluar los enlaces simbólicos en la ruta de Dockerfile: lstat / root / Dockerfile: no existe ese archivo o directorio "y luego" No se puede encontrar la imagen 'buildelektra- stretch: latest ' localmente ". Esto significa que v2 no está disponible en este momento.

@ markus2330 escribió: movió el problema a # 1829

Creo que una de las últimas actualizaciones del servidor de compilación rompió elektra-gcc-configure-debian-stretch , que ya no puede conectarse al repositorio:

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

.

Creo que el problema con elektra-gcc-configure-debian-stretch es el servidor de compilación ryzen , que no puede conectarse a GitHub. Cambié la etiqueta para el trabajo de construcción de debian a debian-stretch-mr consecuencia. Ahora el trabajo de construcción parece funcionar de nuevo .

Ryzen, que no puede conectarse a GitHub

Parece que la corrección de NetworkManager de nuestro administrador con "manged = true" no funcionó de manera confiable. Después de reiniciar, "/etc/resolv.conf" volvió a ser un enlace simbólico colgando. Lo arreglé de nuevo, GitHub debería ser accesible desde ryzen. Lamentablemente, rzyen v2 todavía no es accesible (falta el puente ssh).

Finalmente se lanza Elektra 0.8.22. Agregaré el enlace al n. ° 676 una vez que se haya creado el sitio web, la creación del sitio web lleva más de una hora. Tal vez podamos mover la compilación de la página de inicio a una máquina más rápida y solo copiar el sitio web resultante en su ubicación.

Creo que tenemos que hacer algo con el servidor que aloja http://build.libelektra.org. Es insoportablemente lento y no responde 😢. Personalmente, no me importa si una compilación completa de todas las pruebas lleva mucho tiempo. Sin embargo, tal como está actualmente, toma unos minutos incluso conectarse al servidor, si es que podemos conectarnos al 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>

.

Sí, no solo Jenkins se ve afectado, sino todo lo demás que se ejecuta en este servidor. Para mí, la situación a menudo también es inaceptable. Parece que hay muy poca RAM. (Se utiliza intercambio 2GiG)

Jenkins podría ser la razón, hay docenas de procesos Java que lideran la lista en htop. Durante mucho tiempo tuvimos suficiente RAM y el intercambio apenas se usó, y no cambiamos mucho (excepto actualizar Jenkins y aumentar la cantidad de trabajos de compilación).

Sugiero dejar de usar el servidor de la comunidad como agente. Para esto, necesitaríamos volver a v2, pero @ e1528532 parece estar ocupado. También podríamos alquilar un servidor mejor, pero luego necesitaríamos a alguien que tenga tiempo para la migración.

@ markus2330 ¿Puede reiniciar el servidor de compilación? Actualmente, incluso los trabajos simples como elektra-todo fallan.

Reinicié la v2 el domingo, pero aparentemente ya está inactiva de nuevo, por lo que primero deberíamos estabilizar la v2 antes de pensar en ponerle otras cosas.

Reinicié Jenkins y v2. Jenkins parece estar funcionando sin problemas de nuevo.

@ e1528532 Parece que el túnel ssh todavía no funciona. Incluso después de reiniciar a7, no es posible conectarse a v2.

por lo que primero deberíamos tener v2 estable antes de pensar en ponerle otras cosas.

El principal tiempo de inactividad fue causado por el puente ssh. Si v2 tenía problemas, generalmente se reiniciaba en un día.
Ahora eliminé el resto del servidor X, así que espero que v2 ahora también sea estable. Para a7, este parecía ser el truco (no fue necesario reiniciar durante bastante tiempo). Sin carga en v2 (que requiere el puente ssh), sin embargo, no sabremos con certeza si es estable.

¿Qué hay de dividir las discusiones sobre hardware (reinicios) y software (actualizaciones de Jenkins)?

Parece haber un problema de conectividad de red entre a7 y v2. v2 está en funcionamiento, pero todavía obtengo "Sin ruta al host". Parece que no puedo arreglarlo hoy.

La red de la v2 estaba inactiva porque la desinstalación de GNOME también desinstaló network-manager. Ahora arreglamos la red (usando / etc / network / interfaces) y actualizamos a la última BIOS / UEFI. Así que, con suerte, ahora todo está estable.

Por cierto. hay un hardware más que podríamos usar a través de un puente ssh ... (PCS)

Parece que el túnel ssh todavía no funciona. Incluso después de reiniciar a7, no es posible conectarse a v2.

Sí, esto no fue automático. Ahora me he encargado de todo. El contenedor de la ventana acoplable debería reiniciarse automáticamente ahora si la máquina se reinicia. Al menos he configurado el indicador --restart en "siempre" de acuerdo con https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode # 37618747

Además, he creado un nuevo usuario llamado "ssh-tunnel-a7-v2" que no tiene una contraseña configurada tanto en a7 como en v2 (por lo tanto, desactiva la autenticación de contraseña para ese). Creé un certificado ssh para el usuario en el a7 y agregué la clave pública a los hosts conocidos en v2. Luego agregué un servicio systemd a /etc/systemd/system/ssh-tunnel-a7-v2.service que abre el túnel ssh automáticamente como un servicio systemd de acuerdo con https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service. Por lo tanto, también debería funcionar cuando el servidor se reinicia o la conexión ssh falla y ya no depende de mí ni de mi usuario. Debido al uso de un certificado, no es necesario utilizar contraseñas para las conexiones.

Además de eso, v2 se reinicia, por supuesto, con esta nueva configuración automatizada activa. Ojalá sobreviva al próximo accidente (si lo hay), teóricamente debería, pero ya veremos.

El trabajo de compilación test-docker siempre falla, si Jenkins ejecuta el trabajo en 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

. Quería restringir el trabajo a nodos que no sean ryzen v2 , pero parece que falta la opción para este paso en la página de configuración de test-docker . ¿Podría alguien echar un vistazo y solucionar este problema?

¡Gracias por investigarlo! ¿No es posible asignar múltiples etiquetas a los agentes? Luego, podría asignar una etiqueta única a ryzen v2 y vincularle el trabajo.

Afortunadamente, pronto obtendremos soporte para nuestro servidor de compilación: +1:

¿No es posible asignar múltiples etiquetas a los agentes?

Hasta donde yo sé, sí, es posible asignar múltiples etiquetas a un agente.

Luego, podría asignar una etiqueta única a ryzen v2 y vincularle el trabajo.

Como ya dije antes [[1]], la opción "Restringir dónde se puede ejecutar este proyecto" parece faltar:

Quería restringir el trabajo a nodos que no sean ryzen v2 , pero parece que falta la opción para este paso en la página de configuración de test-docker .

.

Ahh, entendí mal tu declaración como: "No hay forma de escribir una expresión booleana que me permita decir (estable &&! Ryzenv2)", no es que no haya ninguna opción para la restricción de agentes.

Quizás esto se pueda hacer con el DSL. Le preguntaré a Lukas si sabe qué hacer.

Hola,

como señaló @sanssecours , ryzen v2 no tiene la ventana acoplable instalada pero tiene la etiqueta de la ventana acoplable.
Las ejecuciones de test-docker requieren que los nodos tengan la etiqueta de Docker.

Las posibles soluciones son instalar la ventana acoplable en el nodo o eliminar la etiqueta del nodo en jenkins

Las posibles soluciones son instalar la ventana acoplable en el nodo o eliminar la etiqueta del nodo en jenkins

Gracias por brindar una solución al problema. Acabo de eliminar la etiqueta docker de ryzen v2 . Por lo que puedo decir, todo parece funcionar ahora.

Actualicé la descripción del nodo 'ryzen v2' para reflejar que en realidad es 'solo' un contenedor docker que se ejecuta en v2. De ahí por qué Docker no estaba disponible a pesar de que está instalado en v2.

También se agregó un complemento a jenkins que permite una visualización de datos de compilación más fácil (sin tener que hacer clic en cada compilación)

v2 está caído de nuevo, lo informé.

Reinicié v2 pero no pude volver a conectar el agente.

Al menos, finalmente recibimos mensajes de error de lo que sucedió antes del bloqueo (por supuesto, no hay garantía de que los mensajes de error tengan algo que ver con el bloqueo):

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

Extraño, parece que mi maquinaria de reinicio funcionó, tanto el túnel ssh como los nodos de la ventana acoplable se reiniciaron y puedo conectarme a a7.complang.tuwien.ac.at -p 22222, lo que significa que todo debería estar abierto. Sin embargo, de alguna manera Jenkins solo me mostró una rueca infinita por alguna razón, sin tiempo de espera, sin nada.

Probé mi puente ssh manual como lo habíamos hecho antes, lo mismo. Reinició el contenedor de la ventana acoplable una vez más, lo mismo. Entonces, honestamente, no estoy seguro de qué es exactamente lo que está mal ahora sin un mensaje de error, lo único que encontré es un tipo que aparentemente tiene un error similar (rueda giratoria pero sin mensaje) pero no hay solución para eso aparte de reiniciar todo el maestro jenkins. nodo (que no he probado): https://issues.jenkins-ci.org/browse/JENKINS-19465

EDITAR: probé una de las soluciones sugeridas (restablecer la configuración del nombre de host a algo que no existe, volver a conectar, luego jenkins se da cuenta de que el nombre de host es incorrecto, volver al nombre de host real, luego de repente funcionó sin más problemas). Así que supongo que este error sucedió en lugar de algo con mi configuración de reinicio, pero esperemos el próximo bloqueo para estar seguros de eso;)

@ markus2330 apuesto a que ya lo descubrió usted mismo, pero una búsqueda rápida me mostró que esto podría estar relacionado con la configuración del estado c: https://bugzilla.kernel.org/show_bug.cgi?id=196683 , hay algunos sugeridos soluciones para eso

Parece que el servidor de compilación ryzen no puede conectarse a nuestro repositorio :

No se pudo recuperar de https://github.com/ElektraInitiative/libelektra.git

.

la configuración de dns estaba colgando de nuevo. Ya que no entiendo completamente por qué es
configuré la forma en que está actualmente, solo restauré la configuración del servidor de nombres y
reinició el trabajo de compilación de Docker.

El 12 de marzo de 2018 a las 17:03, René Schwaiger [email protected] escribió:

Parece que el servidor de compilación ryzen no puede conectarse a nuestro repositorio
https://build.libelektra.org/jenkins/job/test-docker/162/console :

No se pudo recuperar de https://github.com/ElektraInitiative/libelektra.git

.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

Como no entiendo completamente por qué está configurado como está actualmente

Me temo que nadie lo entiende. Es posible que el servidor DNS esté mal configurado y no proporcione la información adecuada sobre el servidor de nombres. Para v2 desinstalamos el administrador de red y parece que resolv.conf ahora es estable allí. Entonces, una opción es desinstalar el administrador de red en a7 también. (y use / etc / network / interfaces) No hay ninguna razón por la que v2 y a7 tengan configuraciones divergentes, es solo por una administración descuidada.

Idealmente (a largo plazo), manejamos ambos usando Puppet.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , hay algunas soluciones sugeridas para eso

C6 debería estar desactivado pero continuaremos con la investigación.

El nuevo agente de compilación "ryzen v2 docker" no parece tener un demonio D-Bus ejecutándose como "debian-stable-mm" .

¿Alguien puede instalarlo / iniciarlo o decirme qué script configura las compilaciones multiconfig-gcc47-cmake-options para que pueda agregar un fragmento para asegurarme de que se inicie?

@ markus2330 Sospecho que, dado que tanto ifupdown como networkmanager están habilitados, ambos se meten en el pelo. deshabilitar uno de los dos ciertamente ayudaría.

Bien, eliminé gnome y network-manager en a7 para ser consistente con v2.

El nuevo agente de compilación "ryzen v2 docker" no parece tener un demonio D-Bus ejecutándose como "debian-stable-mm".

El agente de compilación vive dentro de un contenedor docker, con suerte @ingwinlu o @ e1528532 pueden ayudarlo a iniciar el demonio dbus allí.

Gracias. Debería ser bastante fácil. Lo inicio en el contenedor de la ventana acoplable (Ubuntu 17.10 artful construido desde docs/docker/Dockerfile ) con los siguientes comandos:

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

El servidor de compilación ryzen no puede volver

Disculpa, mi error. Parece que detener el administrador de red fue suficiente para romper el sistema.

Debería arreglarse ahora. No dude en informarnos de cualquier otro problema.

@ markus2330 bastante seguro de que se habría roto de nuevo en el próximo reinicio

Me tomé la libertad de rehacer el archivo / etc / network / interfaces (y mover la configuración de las interfaces a /etc/network/interfaces.d)
que combinado con la desinstalación del administrador de red debería mantenerlo estable

por favor revise la configuración y tal vez active un reinicio para ver si funcionó

@ingwinlu Gracias por la solución, el reinicio funcionó bien.

Descubrí que eliminé demasiados paquetes, así que volví a instalar Java (openjdk 9 sin cabeza y por defecto-jre): smile:

@ingwinlu ¿Podría hacer que dbus se ejecute en el agente v2? Lo ideal sería reubicar también "/ home / armin / buildelektra-stretch / Dockerfile" a algún destino que no sea específico del usuario.

@ markus2330 mi propuesta sobre cómo proceder con el entorno de compilación en realidad prevé la eliminación del nodo dockercontainer-on-v2 actual y reemplazarlo con uno capaz de docker (es decir, ya no apunta a un contenedor docker en v2 sino que apunta directamente a v2) .

Luego, podemos configurar la canalización de compilación para compilar la imagen en sí a partir de Dockerfiles registrados en el repositorio para proporcionar los diferentes entornos necesarios para las pruebas.

Puedo priorizar el despliegue de una imagen de la ventana acoplable compatible con dbus cuando llegue a ella, pero no me gustaría hacer un trabajo que pronto será irrelevante si no tengo que hacerlo.

¡Sí, eso tiene sentido!

El objetivo a largo plazo de v2 es que tenemos que compartirlo con algunos otros contenedores de la ventana acoplable (no para Elektra), por lo que sería bueno si todas nuestras partes están virtualizadas de una manera que no puedan influir en los otros contenedores de la ventana acoplable. (¿Quizás Docker recursivo o Xen?) Podríamos / deberíamos hacer lo mismo para que a7 tenga configuraciones idénticas.

Seguiremos teniendo acceso directamente a las máquinas, pero debemos reducir cualquier riesgo de que Jenkins pueda matar las máquinas Docker con las que no tiene nada que ver.

Para algunos agentes, ya tenemos una configuración de Puppet. Sería genial si no lo omitimos o incluso mejor: extender esta configuración para a7 y v2. Espero que @BernhardDenner pueda darte más información sobre eso pronto.

El servidor de compilación está inactivo nuevamente 🙌.

Por cierto, podríamos mover la discusión sobre el estado del servidor de compilación a una discusión del equipo de GitHub , ya que este tema podría no ser interesante para todas las personas suscritas a este problema.

Sí, todo el servidor está inactivo, incluido el servidor de compilación: cry: Y v2 también está inactivo (independientemente). Reinicié v2 y cambié la opción C-States en UEFI. Pero parece que hay un problema importante con nuestro servidor. Esperemos que lo reemplacemos por un mejor hardware con más memoria: cross_fingers:

Discusión del equipo de GitHub

¿No se notifica a todos los miembros de ElektraDevelopers si escribimos algo en la discusión del equipo de GitHub? Aquí en este número todos pueden decidir si quieren suscribirse.

Para mí, una pregunta aún abierta es si deberíamos dividir este problema en dos: relacionados con el hardware y relacionados con Jenkins.

¿No se notifica a todos los miembros de ElektraDevelopers si escribimos algo en la discusión del equipo de GitHub?

Por lo que puedo decir, sí.

Aquí en este número todos pueden decidir si quieren suscribirse.

Eso también es

El servidor de compilación está activo de nuevo. Configuración modificada:

• xms y xmx para reducir la cantidad de recolección de basura cuando hay muchas compilaciones en cola
• noté que usamos scm polling. Reduje el sondeo a 4 sondeos simultáneos a nivel mundial a la vez para, con suerte, reducir un poco los picos que el servidor está obteniendo actualmente.

EDITAR:

* Establezca el número de compilación para mantenerlo en 30 para todas las canalizaciones, ya que de acuerdo con varias fuentes, estas se leen al acceder a webui y, por lo tanto, una gran cantidad de compilaciones antiguas ralentiza las solicitudes

Actualice Jenkins a la versión. 2.107.1

• Actualizar el archivo war de jenkins
• Deshabilite la configuración de seguridad del complemento Use browser for metadata download ya que no permitiría actualizar los complementos
• Actualice los complementos a las últimas versiones disponibles

EDITAR 2018-03-18:

• Se agregó un segundo ejecutor a todos los nodos que se ejecutan en mm.

* despriorizó a todos los agentes que se ejecutan en mr

Master debería ser mucho más receptivo ahora bajo carga. Construir todo debería estar más cerca de 2h como de 4h + de antes.

EDITAR 2018-03-24:
perdón por los retrasos, semana ocupada ...

• Se agregó un nuevo trabajo al servidor jenkins (elektra-jenkinsfile) que ejecutará el archivo Jenkins que se encuentra en el repositorio (una vez que exista)

EDITAR 2018-03-28:

• Rehizo el archivo de la unidad del túnel, ahora analiza los archivos del entorno y, por lo tanto, se puede ajustar para que apunte a varios objetivos.
• Se agregó el servidor v2 como esclavo capaz de ejecutar Docker
  
  
  
  • agregó usuario de jenkins en v2
  
  
  • instalado openjdk-9 en v2
  
  

EDITAR 2018-03-29:

• Corregir la configuración de ulimit en jenkins master

Aunque estoy bastante seguro de que @ingwinlu o alguien ya está en esto: parece que ryzen v2 está mal configurado:

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 / consola pero sucedió en múltiples ocasiones.

Ups, lo siento. No tiene deps instalados y solo debería actuar como un host de la ventana acoplable. Eliminaré las banderas adicionales.
// EDITAR: debe hacerse. con suerte eso fue suficiente
// EDIT2: También deshabilité test-docker por ahora, ya que obviamente no puede encontrar las imágenes de compilación necesarias para ejecutar las pruebas.

Pero maldita sea, la cosa es rápida si realmente consigue algo que pueda construir.
// EDIT3: se ha vuelto a activar test-docker para que solo se ejecute en nodos con la etiqueta docker-prefab y se le haya dado esa etiqueta a ryzen

Lamentablemente, el problema parece ser mayor de lo que se esperaba originalmente.

Algunos trabajos tienen sus nodos codificados. Algunas etiquetas están desactualizadas (estables en los nodos de jessie). Algunos trabajos no requirieron los nodos correctos y solo se ejecutaron en el correcto porque se ejecutó allí una vez antes y se construyó con éxito.

La introducción de un nuevo nodo (ryzen v2 nativo) cambió un poco la asignación aunque no debería haberlo hecho.

Espere algún comportamiento inesperado hasta que todo vuelva a funcionar donde estaba.

Registro de cambios:

• nodos renombrados, <os>-<hostname>-<buildenv>
• discapacitado elektra-multiconfig-gcc47-cmake-options
  en realidad, no se ha estado ejecutando en esclavos gcc47 desde hace bastante tiempo, con una combinación de construcción gcc49 o gcc63 dependiendo de dónde se programó. Si se vuelve a activar, probablemente debería ir al dockercontainer habilitado para gcc63 en v2
• volvió a etiquetar un montón de trabajos (podría haber perdido algunos de ellos)
  
  
  
  • elektra-todo requería stable , pero no todos los nodos estables tenían sloccount instalados
  
  
  • muchos más casos similares
  
  

A7 parece estar caído

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

Aunque estoy bastante seguro de que @ingwinlu https://github.com/ingwinlu o
alguien ya está en esto: parece que ryzen v2 está mal configurado:

FATAL: No se pudo aplicar la etiqueta jenkins-BUILD_FULL = ON, BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON-185
hudson.plugins.git.GitException: El comando "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" devolvió el código de estado 128 :
stdout:
stderr:
* Por favor dime quien eres

Correr

git config --global user.email " [email protected] "
git config --global user.name "Su nombre"

para configurar la identidad predeterminada de su cuenta.
Omita --global para establecer la identidad solo en este repositorio.

fatal: nombre de identificación vacío (para [email protected] ) no permitido

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 / consola
pero sucedió en múltiples ocasiones.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

¿Quieres trabajar en ello? Podría reiniciarlo hoy. Como alternativa, nuestro administrador o yo podríamos reiniciarlo el martes.

Si no es demasiado complicado. De lo contrario, no puedo trabajar en mi PR sobre el
fin de semana

markus2330 [email protected] schrieb am Sa., 31 de marzo de 2018, 14:33:

¿Quieres trabajar en ello? Podría reiniciarlo hoy. Como alternativa nuestro
admin o podría reiniciarlo el martes.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

Bien, lo reinicié y también deshabilité el estado C6 en el BIOS / UEFI (estaba habilitado). También eliminé gnome / xorg (¿pensé que ya lo había hecho?).

Por cierto. la pantalla estaba completamente negra, por lo que solo podemos adivinar cuál fue la causa.

estos han estado apareciendo en a7 cada 10 minutos más o menos:

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)

Esas pueden ser las razones del tiempo de inactividad de a7, así como algunos de los comportamientos extraños de compilación en a7 latelty

Sección de valgrind deshabilitada en elektra-ini-mergerequests como se ejecutó a través de make run_memcheck

estos han estado apareciendo en a7 cada 10 minutos más o menos

Sí, ya los vimos. Cuando se compró la computadora, alguien realmente verificó si ECC funcionaba y no ocurrieron tales errores en ese entonces. ¿La frecuencia de estos errores depende de alguna manera de la carga del sistema?

Se desactivó la sección valgrind en elektra-ini-mergerequests ya que se ejecutó a través de make run_memcheck

Gracias por limpiar esto.

Tengo tomas descartadas aleatorias (los contenedores se bloquean, las compilaciones se detienen en el medio, se desconectan, ...) en a7 sin ningún registro 'real' nuevamente. sólo las correcciones de memoria ya mencionadas.

Gracias, parece que algo anda muy mal. Y ahora también tenemos errores incorregibles:

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

ahí va a7 de nuevo.

en un frente más productivo: instalé la interfaz de océano azul en jenkins. Avance

ahí va a7 de nuevo.

Es realmente frustrante. Reinicié la máquina y volví a conectar a los agentes. Le pediré a nuestro administrador que reemplace la RAM mañana, así que espere tiempos de inactividad mañana.

en un frente más productivo: instalé la interfaz de océano azul en jenkins. Avance

¡Se ve muy bien! ¿Quizás puedas mostrárnoslo en la próxima reunión?

Nuestro administrador ya está en el fin de semana. Reiniciaré a7 y restableceré el BIOS / UEFI a los valores predeterminados de fábrica. Si los errores continúan durante el fin de semana, es de esperar que cambie la RAM.

EDITAR: No se estaba ejecutando ningún trabajo de compilación, por lo que no se canceló ningún trabajo de compilación.

EDITAR: Todo ha vuelto a funcionar. Hasta ahora no hay errores de memoria.

Luciendo mucho mejor. ¿Alguien vio demasiados consejos técnicos de linus y overclockeó el servidor?

Lo siento, tuve que detener a Jenkins por algún tiempo. El servidor tenía una carga de 20 y las cosas que necesitaba hacer ya no eran posibles (> 1h de tiempo de espera, luego me di por vencido y detuve a Jenkins).

¿Es posible que incluso los trabajos de construcción no iniciados necesiten RAM? (la lista de espera era muy larga) De lo contrario, los trabajos de construcción locales son los mejores candidatos para estos problemas. (Se estaban ejecutando 3 trabajos de construcción locales)

@ingwinlu Idealmente, no construimos nada en ese servidor. Además, ¿podemos hacer que los trabajos de construcción dependan de la carga en un servidor? (¿No iniciar trabajos en un servidor con carga> 5?).

Empecé todo de nuevo, pero espero que encontremos una solución rápida para eso.

Bombeé VERSION y CMPVERSION en la configuración del sistema Jenkins.

@ingwinlu Sería genial si tuviéramos estas configuraciones también dentro de Jenkinsfile.

@ markus2330 vea 8de9272051fe903a7df08f0abdf18879701f7ac9 para ver un ejemplo sobre cómo lograr esto en un archivo Jenkins

Se eliminó make run_memcheck de los siguientes objetivos debido a que fallaron desde hace algún tiempo y finalmente aparecieron en el sistema de compilación gracias a # 1882

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

restringir elektra-gcc-configure-debian-stretch para que se ejecute en los nodos: stretch && !mr

Actualice jenkins master a ver. 2.107.2 + actualice todos los complementos

Intenté agregar allowMembersOfWhitelistedOrgsAsAdmin a todos los trabajos de compilación hoy, pero parece que todavía no puedo activar una compilación completa (ver # 1863) correctamente y solo se ejecutan algunos trabajos

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

Puede alguien por favor

• reparar
• deshabilitar, o
• (incluso mejor) eliminar

elektra-clang-asan por favor 🙏. Actualmente, el trabajo de compilación falla, aunque todas las pruebas que fallan:

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

funciona bien en Travis .

No prueban lo mismo que (por ejemplo) usan diferentes versiones de clang ...

Dado que este hilo es absolutamente imposible de rastrear para informes de errores o discusiones más largas, abriré nuevos problemas para clang y clang-asan tan pronto como llegue a él.

No prueban lo mismo que (por ejemplo) usan diferentes versiones de clang ...

Estoy de acuerdo, mientras que Travis usa el clang 5.0.0 obsoleto, la versión de Clang en elektra-clang-asan es antigua ( 3.8.1 ). No veo el valor de un trabajo de compilación habilitado para ASAN para un compilador tan antiguo.

Creé el # 1919 para la prueba fallida "testlib_notification" en "elektra-clang-asan".

Probé una compilación con todos los agentes mr deshabilitados y el maestro respondió perfectamente, mientras que una compilación con todos los agentes mr habilitados en realidad agotó el tiempo de algunas de las compilaciones. Por lo tanto, el número 1866 definitivamente proporcionará una mejora si podemos deshacernos de todos los agentes del Sr.

Más pruebas muestran que es prácticamente solo el trabajo de compilación de la página de inicio. Lo eliminé de build all por ahora, por lo que solo se ejecuta explícitamente.

Será reemplazado por una solución en contenedor.

v2 está en línea nuevamente con la última BIOS.

Informe aquí cualquier error de segmento (la CPU puede tener errores).

a7 parece estar caído?

El 4 de mayo de 2018 a las 11:10, markus2330 [email protected] escribió:

v2 está en línea nuevamente con la última BIOS.

Informe aquí cualquier error de segmento (la CPU puede tener errores).

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 está de nuevo con la última BIOS

a7 abajo de nuevo?

Sí, se había estrellado. Mostró el indicador de inicio de sesión sin ningún mensaje de error y sin ninguna reacción a ninguna entrada (incluido sys-req). Solo ayudó el restablecimiento completo.

Si tiene alguna idea de cuál podría ser el problema, dígaselo.

lamentablemente, no se configura ningún diario persistente en a7, por lo que no hay registros

¿Cuándo podemos esperar que a7 y v2 vuelvan a estar disponibles?

Ohh, no sabía que estaban caídos. Le pediré a nuestro administrador que reinicie y, si no puede, lo haré alrededor de las 17:00.

Editar: Dijo que los restablecerá ahora mismo.

Editar: Ambos están levantados de nuevo.

reinicié a7 y v2 manualmente hoy. parece que ya no se puede acceder a la v2. ¿Puede por favor que se esté ejecutando?

// EDITAR: resuelto arreglando la configuración de red en ambas máquinas

aparentemente a7 ha vuelto a bajar.

Ok, la reiniciaré. De lo contrario, nunca terminaremos este lanzamiento.

alguna indicación de la causa? ¿Solo problemas de red o la máquina no respondió de nuevo?

Todo debería estar listo y funcionando ahora.

Lo obtuve en el momento adecuado, hubo algunos registros hasta que finalmente se congeló por completo.

Los registros fueron:

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

Eso podría ser cualquier cosa. de la CPU Ryzen defectuosa a una fuente de alimentación defectuosa :(

El 12 de mayo de 2018 a las 14:33, markus2330 [email protected] escribió:

Todo debería estar listo y funcionando ahora.

Lo acabo de recibir en el momento adecuado, hubo algunos registros hasta que finalmente
completamente congelado.

Los registros fueron:

INFO: rcu_sched detectó bloqueos en CPU / tareas:
...
rcu_sched kthread murió de hambre durante 7770 jiffies
perro guardián: BUG soft lockup - ¡CPU # 2 atascada durante 22 segundos! [docker-gen]
... (muchas repeticiones)
Watchdog NMI: Watchdog detectó un BLOQUEO duro en la cpu 2

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

Acerca de # 1993

@ingwinlu Desactive los trabajos si actualmente no tienen éxito (o al menos no los active de forma predeterminada ni con "jenkins build all please"). Debe tener una alta prioridad que no fallemos en trabajos en relaciones públicas donde en realidad todo está bien. (asan fallar durante bastante tiempo no era una buena situación)

Si fallan debido a alguna acción de Jenkins que hiciste, reiniciar los trabajos sería bueno: corazón: Decirlo aquí en el n. ° 160 también está bien.

v2 ha vuelto a funcionar, ¡con una nueva CPU!

Envíe muchos trabajos para pruebas de estrés: sonrisa:

a7 parece estar caído de nuevo.

Gracias, todo ha vuelto a funcionar.

Reinicié a7 de nuevo.

Tener un circuito que reinicia a7 cada hora probablemente aumentaría la disponibilidad.

¿Cuándo podemos esperar que a7 vuelva a estar en línea?

a7 está de nuevo en línea

v2 está de vuelta en línea

La fuente de alimentación de v2 se cambiará en aproximadamente 1h.

@ingwinlu ¿ puede deshabilitar los agentes y volver a habilitarlos después? (Si actualmente está trabajando en ello).

Los agentes v2 están deshabilitados por ahora

v2 se está ejecutando de nuevo. Tiene una nueva fuente de alimentación. Envíe muchos trabajos para realizar una prueba de esfuerzo de la máquina.

Actualicé los complementos de jenkins. El reinicio resultante restauró parcialmente los nodos jenkins antiguos (antes de que se les cambiara el nombre), lo que resultó en compilaciones rotas en todas partes ya que los repositorios de git se estropearon.

Limpié los repositorios afectados y limpié los contenedores de la ventana acoplable en caché solo para estar seguro.

a7 está inactivo nuevamente y, como tal, las compilaciones basadas en Docker no están disponibles nuevamente.

También voy a revertir la actualización de xunit ya que viola las restricciones de seguridad.

Reinicié a7 y volví a conectar a todos los agentes.

Las compilaciones de Docker no están disponibles ya que a7 está inactivo nuevamente.

Reinicié el servidor y volví a conectar a los agentes.

Creo que reemplazar a7 es la mejor manera de avanzar, ver # 2020

Creo que está caído de nuevo, mi última confirmación resultó en No se puede contactar a a7-debian-stretch: java.lang.InterruptedException

@ e1528532 ¡ Gracias por escribirlo aquí! Si quieres, también puedes votar en # 2020

Reinicié a7 y volví a conectar a los agentes.
Esperemos lo mejor que no ocurran problemas durante el fin de semana.

a7 está abajo de nuevo: llorar: Sorprende que casi funcionó todo el fin de semana. Podría ser el récord de tiempo de actividad de la semana. Sin embargo, el # 2020 no recibió muchos comentarios.

Reinicié a7 (reaccionó a sysctl) y alguien más inició jenkins. Todo está funcionando de nuevo.

a7 acaba de bajar de nuevo.

¡Gracias por la información! Reinicié a7 y volví a conectar a los agentes.

¿Tiene sentido que tengamos el agente "debian-jessie-minimal"? Creo que puede eliminarlo de forma segura una vez que esté integrado en Docker. (y parece que ya lo es)

EDITAR:
En https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
y https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
hay advertencias:

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)

malas noticias. v2 también bajó.

EDITAR: pero parece que puedo conectarme a él a través de ssh ...
EDIT2: emití un reinicio en v2 pero ahora ya no puedo conectarme. aunque todavía se puede hacer ping desde a7 ...

EDIT3: ahora a7 también está abajo.

¡Gracias por informar! Reinicié a7 y v2. Deberíamos reconsiderar el # 2020.

Creo que v2 está caído de nuevo:

No se puede contactar con v2-debian-stretch: java.lang.InterruptedException

Con v2 todo estaba bien, pero a7 volvió a bajar. Todos los agentes están ahora en línea nuevamente.

v2 parece volver a ser semi-insensible. se puede hacer ping desde a7 pero no hay acción ssh en absoluto. deberían ser los problemas de btrfs solo de los síntomas. ¿Puedes reiniciar todo antes de ir a casa el fin de semana?

@ingwinlu Gracias, @waht y yo reiniciamos v2 con éxito pero no puedo conectar los agentes ("Conexión rechazada (Conexión rechazada)"). ¿Alguna idea de lo que está mal aquí? (el inicio de sesión interactivo ssh funciona)

ssh solo funcionaba cuando no se conectaba a través del puente.

después de reiniciar el servicio de puente, se podría establecer la conexión.

Parece que el túnel ssh terminó en un estado indefinido extraño y no se suicidó. No estoy seguro de por qué no se suicidó (serveraliveinterval está activado).

También necesitaba limpiar manualmente todos los espacios de trabajo en v2 ya que el fs estaba dañado y todos los trabajos de compilación fallaron.

a7 parece estar caído. No estoy seguro de poder reiniciarlo antes del lunes.

Reinicié a7 y v2. (v2 porque hubo mensajes de error en a7 de que no se puede crear el puente ssh a v2. Pero también después de reiniciar v2 aparecieron los mismos mensajes de error. Sin embargo, el puente ssh parece funcionar. Tal vez falta alguna dependencia (¿red?) en los scripts de arranque de a7?)

Tal vez falta alguna dependencia (¿red?) En los scripts de arranque de a7

No, está ahí.

no puede crear el puente ssh a v2

Creo que este comportamiento ocurre cuando el kernel v2 comienza a no responder (y por lo tanto no se pueden establecer conexiones de red entrantes). En el pasado, mencionó registros que indicaban errores de btrfs en v2.

Preparo el servidor de compilación para que se apague y luego reemplace la CPU.

a7 y v2 están de vuelta nuevamente (a7 con nueva CPU, v2 con su sistema de archivos raíz verificado)

mientras se mantuvo durante el día (con construcción consistente), parece que a7 simplemente volvió a bajar.

Sí, lo reiniciaré mañana por la mañana.

Deberíamos discutir nuevamente el # 2020.

Reinicié a7. De nuevo fue un bloqueo de la CPU.

a7 está abajo de nuevo.

Gracias, lo reinicié. Todos los agentes están nuevamente en línea.

Parece que algunos de los nodos de Debian están inactivos y, por lo tanto, algunos PRS están esperando durante mucho tiempo para que comience la ejecución de la prueba. ¿Es eso intencionado?

Parece que algunos de los nodos de Debian están inactivos y, por lo tanto, algunos PRS están esperando durante mucho tiempo para que comience la ejecución de la prueba. ¿Es eso intencionado?

Durante una actualización en el nodo mm-debian-unstable, la máquina dejó de responder y no hemos podido conectarnos a ella desde entonces. Dado que el propietario no responde a nuestros correos electrónicos, probablemente desaparecerá para siempre.

Si bien hemos transferido una buena cantidad de trabajos de compilación al nuevo sistema, los que faltan son los que están actualmente en la cola.

Inhabilité los trabajos afectados y los marqué como para ser reemplazados + eliminados de los documentos

@ingwinlu ¡ Gracias por encargarte de esto!

Leer las pruebas xdg es muy importante si alguien quiere trabajar en el resolutor. Lo agregué en la publicación superior aquí. ¿Puede actualizar lo que ya ha logrado en la lista de verificación anterior?

Esta vez v2 es el afortunado ganador.

@ markus2330 limpié el poste superior.

¡Gracias por la limpieza! Reiniciaré v2 (y tal vez a7, veamos) mañana por la mañana.

Lo reinicié. No hubo reacción ni mensaje. Ver # 2020

Reinicie a7 y v2.

Reinicié a7. No encontré ningún problema con v2, ¿debería reiniciarlo de todos modos?

i7 ahora está disponible en 192.168.173.96. ¿Puede crear un puente a través de a7?

Necesita crear un usuario ssh-tunnel-a7-v2 en la máquina o crear una cuenta para mí.

Agregamos un esclavo de compilación adicional i7-debian-stretch que ayudará con libelektra buildjobs.

v2-docker-buildelektra-stretch (offline) ya que no hay más trabajos de construcción programados allí. El ssh-bridge en a7 que expuso al agente también ha sido deshabilitado.

Hola @ingwinlu ,
como se discutió en la última reunión, necesitaría el punto de acceso.
¿Podría enviarme la información por correo electrónico? Mi correo electrónico está en AUTHORS.md .
Por cierto. no pudo encontrar su correo electrónico en ninguna parte, tal vez debería agregarse a este archivo.

Nuestro servidor de compilación v2 estará fuera de línea hasta el 31.07 09:00 ya que estamos ejecutando evaluaciones comparativas en él. Espere tiempos de construcción más largos.

Lo siento por los inconvenientes ocasionados.

// EDITAR: tiempo de inactividad extendido en 2 horas

Parece que la extensión ahora también pasó. Sería bueno tener de vuelta las construcciones rápidas después del almuerzo (alrededor de las 13:00). :sonrisa:

mm-debian-unstable se actualizó y vuelve a estar en línea. ¿Hay trabajos que podamos reactivar y anclar al servidor?

Parece que el disco de i7 está lleno. Mis trabajos fallan con No space left on device ( Trabajo y Trabajo )

Me gusta mucho la nueva interfaz de compilación (dockerization & jenkinsfile) por cierto. Muy útil para reproducir errores de compilación.

¡Gracias por informar!

Desafortunadamente, el cambio de tamaño requeriría un reinicio (rootfs debe hacerse más pequeño antes de que el otro pueda extenderse) y solo traerá 20G. Eliminé las carpetas de compilación de Jenkins, pero eran pequeñas, por lo que todavía estamos al 99%.

Entonces, limpiar _docker sería más efectivo:
@ingwinlu parece que tanto _docker / overlay2 es enorme. ¿Alguna idea de por qué se recogieron todas estas cosas allí?

Obligo a limpiar los artefactos de la ventana acoplable con docker system prune -fa . Esta
limpió alrededor de 190 GB de espacio utilizado en las imágenes de la ventana acoplable.

El lunes 13 de agosto de 2018 a las 07:54, markus2330 [email protected] escribió:

¡Gracias por informar!

Desafortunadamente, el cambio de tamaño requeriría un reinicio (es necesario hacer rootfs
más pequeño antes de que el otro pudiera extenderse) y solo traería 20G. I
eliminó las carpetas de compilación de Jenkins, pero eran pequeñas, por lo que todavía estamos en
99%.

Entonces, limpiar _docker sería más efectivo:
@ingwinlu https://github.com/ingwinlu parece tanto _docker / overlay2
es enorme. ¿Alguna idea de por qué se recogieron todas estas cosas allí?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

¡Gracias!

¿Podemos poner esto en libelektra-daily o en un cronjob?

Daily hace algo similar pero menos agresivo. Tendré que tomar otro
mira cuando vuelva a Viena.

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

¡Gracias!

¿Podemos poner esto en libelektra-daily o en un cronjob?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Como habrás notado, el servidor de compilación no funcionaba por la mañana (quizás por la noche). La unidad de fuente de alimentación se dañó y ahora se reemplazó.

Además, es posible que a7 o v2 se desconecten para realizar evaluaciones comparativas durante períodos breves durante la próxima semana. Verá el "punto de referencia" del mensaje fuera de línea si anton inicia los puntos de referencia. Si la computadora permanece fuera de línea durante demasiado tiempo (por ejemplo, más de un día), comuníquese con nosotros. (Entonces es posible que se haya olvidado volver a cambiarlo a en línea).

Se resolvió un problema con nuestra imagen sid.

testkdb_allplugins segmentado en nuestra imagen sid durante las pruebas debian-unstable-full-clang pero solo cuando se ejecuta en v2. Actualicé manualmente la imagen para usar los últimos paquetes disponibles y la inserté en nuestro registro.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ aprobado, pero lo vigilaré.

El problema se ha mencionado en los números 2216 y 2215 ( @mpranj @sanssecours).

Implementé el acceso público a nuestro registro de Docker. Consulte aquí para obtener documentación sobre cómo acceder a él.

Avísame si algo no funciona como se esperaba.

// EDITAR parece que presionar no funciona aunque el inicio de sesión sea exitoso.
// El acceso público de EDIT2 se vuelve a deshabilitar. https://github.com/moby/moby/issues/18569. funcionalidad restaurada para construir el sistema
// EDIT3: el repositorio público está activo nuevamente en hub-public.libelektra.org

Anton quiere reemplazar la placa base de la computadora donde el Hyper-Threading está desactivado el próximo martes o miércoles (podemos elegir). ¿Alguien necesita el servidor de compilación en uno de estos dos días?

Reinicié el registro de Docker y ejecuté una limpieza manualmente. Con suerte, eso resolvió cualquier problema de compilación con la imagen del sitio web.

@ingwinlu ¡ gracias por el trabajo de mantenimiento!

Desafortunadamente, la etapa de WebUI falla de manera bastante confiable, por ejemplo, 321 o 320 (¿fallaron incluso antes, pero también al extraer WebUI?).

Cada vez estoy más convencido de que cancelar trabajos en máster es una mala idea. Casi no tenemos compilaciones exitosas en el maestro porque las compilaciones se cancelan o fallan debido a problemas de red. En el historial de confirmaciones es difícil saber qué sucedió porque de cualquier manera simplemente se muestran como fallas.

Como solución, desactivé las etapas no confiables en c3b59ecef95287ffc33b094b37e03d0ec6b5710f, ¡pero espero que podamos habilitarlas pronto nuevamente!

¿Debería a7-debian-stretch seguir sin conexión para los puntos de referencia? (desconectado desde el 21 de febrero de 2019 a las 10:47:56 a.m.)

¡Gracias por informar! Parece que Anton se olvidó de reactivar. Activé el nodo nuevamente y también eliminé los nodos antiguos (excepto mm, ya que todavía se están ejecutando).

Hubo un tiempo de inactividad de nuestro servidor por la mañana. Todo vuelve a funcionar, pero nos ofrecieron que cambiarían el hardware. Así que lo más probable es que hoy tengamos otro tiempo de inactividad de aproximadamente una hora.

El servidor vuelve a funcionar. Desafortunadamente, tenemos el mismo hardware. Si alguien tiene tiempo para la instalación / configuración, podemos actualizar el hardware.

Parece que las compilaciones de Jenkins son bastante lentas (varias horas para una compilación completa). Por lo que puedo decir, solo a7-debian-stretch y i7-debian están ejecutando pruebas, mientras que todos los demás nodos están inactivos. ¿Es este el comportamiento esperado?

¡Gracias por reportar este problema!

No, este no es el comportamiento esperado. Parece que v2 no funciona. Lo reiniciaré lo antes posible.

v2 ahora debería estar activo de nuevo

v2 está inactivo y me temo que seguirá así hasta el lunes. Las compilaciones serán muy lentas hasta entonces.

v2 está de nuevo con una nueva placa base

Actualizaré los 3 agentes de compilación (i7, v2, a7, en ese orden) a Buster para evitar el # 2852

Intentaré mantener el tiempo de inactividad lo más mínimo posible. Los trabajos de compilación pueden fallar, reinícielos (después de que los agentes vuelvan a estar activos).

i7-debian-buster, el antiguo i7-debian-stretch está en línea nuevamente

v2 es el siguiente

v2-debian-buster y a7-debian buster también están en línea nuevamente

Reinicié el trabajo de compilación exitoso anterior en el maestro para ver si todo funciona nuevamente:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

Además, agregué el PR https://github.com/ElektraInitiative/libelektra/pull/2876 para habilitar los trabajos de construcción de buster.

v2 parece estar inactivo (también falla la conexión ssh), desafortunadamente no estoy en Viena. Espero que nuestro administrador de sistemas lo solucione mañana.

a7 ahora también está abajo y con él i7 (que está conectado a través de un puente sobre a7).

Por lo que actualmente no se pueden realizar compilaciones. Me comuniqué con el administrador.

Todos los servidores vuelven a funcionar. Reinicie las compilaciones enviando nuevas confirmaciones o escribiendo "jenkins build libelektra please" como comentario para su PR.

Nota técnica: a7 se cayó debido a un "bloqueo suave de error de perro guardián". Intenté agregar "nomodeset nmi_watchdog = 0". Esperemos que no vuelvan a ser tan inestables como ya lo han sido.

a7 (y también v2 e i7 porque están conectados a través de un puente sobre a7) están inactivos. Me comuniqué con nuestro administrador. Intente evitar comenzar las compilaciones ahora, ya que solo hará una cola larga.

a7 está de nuevo en línea (ya estaba ayer), la v2 no se vio afectada

Según la página de estado del servidor de compilación, los servidores:

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

están abajo. El directorio de datos de Jenkins también parece estar bastante lleno. Y ya que estamos en eso: sería genial si pudiéramos actualizar Jenkins y sus complementos. Estoy interesado en solucionar estos problemas. Sin embargo, hay dos problemas.

1. No tengo mucha (o realmente ninguna) experiencia en la administración de servidores.
2. Probablemente necesitaría acceso físico a las máquinas, ya que parecen ser bastante inestables.

a7 es un puente a i7 y v2, por lo que con a7 inactivo no sabemos si i7 y v2.

El acceso no es problema, te lo puedo dar. Pero debe tener en cuenta que actualizar Jenkins es una operación grande, ya que generalmente requiere reconfigurar Jenkins (de acuerdo con las notas de la versión, que son muchas, ya que no actualizamos desde hace un tiempo) y reparar el archivo Jenkins (de acuerdo con los cambios de API de los complementos ). Envíeme un correo electrónico si desea acceder.

a7 (y todos los demás) están activos nuevamente.

a7 está caído de nuevo, me comuniqué con el administrador.

Nota técnica: a7 se cayó debido a un "bloqueo suave de error de perro guardián".

Una búsqueda rápida sugiere que esto podría ser un problema de BIOS. ¿Alguien comprobó si hay actualizaciones de BIOS disponibles?

a7 es un puente a i7 y v2, por lo que con a7 inactivo no sabemos si i7 y v2.

Parece un mal diseño. ¿No hay forma de evitar eso?

Una búsqueda rápida sugiere que esto podría ser un problema de BIOS. ¿Alguien comprobó si hay actualizaciones de BIOS disponibles?

Instalamos un nuevo BIOS, reemplazamos la CPU y actualizamos el kernel (vea los mensajes arriba). El sistema se mantuvo estable desde entonces. Ahora, después de actualizar a Debian buster, vuelve a ser inestable.

Sin embargo, le pregunté al administrador si hay una nueva BIOS disponible.

Parece un mal diseño. ¿No hay forma de evitar eso?

i7 y v2 están en una red privada porque no hay suficientes direcciones IPv4. Le pregunté a nuestro administrador si tal vez sería posible una configuración de IPv6.

Le pregunté a nuestro administrador si tal vez sería posible una configuración de IPv6.

Realmente no necesitamos IPv6, sería suficiente usar otro servidor más estable como puente.

Lo más probable es que v2 sea tan inestable como a7 (solo hubo un bloqueo, pero esto no dice mucho porque inmediatamente cuando a7 muere, toma la carga de v2). Podríamos usar i7 como puente. Pero si v2 y a7 fallan, i7 tampoco es de mucha utilidad, tomaría muchas horas terminar un trabajo de construcción. Además, i7 no tiene suficiente espacio para el registro de la ventana acoplable.

Por tanto, este cambio supondría un gran esfuerzo con poca ganancia.

Arreglar el problema real de a7 y v2 es mucho más prometedor.

Además, i7 no tiene suficiente espacio para el registro de la ventana acoplable.

En ese caso, la única solución es arreglar a7.

Desafortunadamente, a7 está abajo de nuevo: llorar:

Intenté arrancar con el kernel antiguo, pero esto no ayudó.

Para BIOS, hay algunas otras versiones disponibles, pero de acuerdo con sus notas de lanzamiento, hay pocas esperanzas de que solucionen este problema y no hay forma de degradar nuevamente si empeora ...

El BIOS para a7 está actualizado actualmente. Además, intentaremos usar un kernel más nuevo de los backports.

Es de esperar que a7 vuelva a estar activo pronto.

El nuevo BIOS no ayudó, ahora a7 se bloqueó en minutos.

a7 está caído de nuevo, me comuniqué con el administrador. El kernel más nuevo de los backports se probará en el próximo reinicio.

a7 está de nuevo con el kernel 5.2

Creo que se estrelló de nuevo ...

¿Seguimos recibiendo los mismos mensajes de error o hay al menos algún cambio?

Sí, a7 abajo de nuevo, le informé al administrador. Nos informará de los mensajes al reiniciar.

¿Alguien tiene otra idea? (Ya actualizamos BIOS y Kernel).

Algunas fuentes sugieren problemas con el controlador de gráficos nouveau y que deberíamos probar nouveau.modeset=0 (de alguna manera esto es diferente a nomodeset ). También se sugirió deshabilitar los "estados C" en el BIOS.

Sí, a7 abajo de nuevo, le informé al administrador. Nos informará de los mensajes al reiniciar.

¿Alguien tiene otra idea? (Ya actualizamos BIOS y Kernel).

tal vez deshabilite a7 como esclavo de jenkins para determinar si solo ocurre cuando la carga 'real' está en la máquina.

@ingwinlu gracias, buena idea. Reduje ahora a un trabajo de construcción un a7 (era 2). Durante el fin de semana (una vez que el administrador haya salido de la oficina), inhabilitaré al agente por completo.

@kodebach : gracias,

¿Hay alguna línea de tiempo para cuándo volverá a estar activo a7?

a7 está activo de nuevo, con hyperthreading desactivado y solo un trabajo de compilación simultáneo.

También podríamos quitar parte de la carga de a7, moviendo las compilaciones alpine y ubuntu-xenial a Cirrus. Ambos son ejecuciones simples de "compilación y prueba". No están haciendo nada especial como informar la cobertura.

Cirrus permite 8 compilaciones simultáneas de Linux por usuario . Actualmente, la compilación linkchecker es la única compilación de Linux en Cirrus.

De hecho, ubuntu-xenial es un poco redundante, ya que nuestras compilaciones de Travis se ejecutan en Ubuntu Xenial.

Gracias por los consejos, pero no planeamos descargar ninguna compilación de Linux de Jenkins. Por el contrario, @Mistreated trabajará para mejorar nuestra infraestructura de Jenkins para que esté aún más actualizada y sea más útil (por ejemplo, creando más paquetes). Las ventajas de nuestros Jenkins son:

1. lo tenemos completamente bajo nuestro control
2. podemos escalarlo fácilmente (solo se requiere Java + Docker en los agentes de compilación)
3. el Jenkinsfile es muy ordenado y (en la mayoría de las partes) bastante fácilmente extensible

Pero, por supuesto, todos pueden ampliar también Cirrus (o cualquier otro sistema de compilación adicional que se ofrezca de forma gratuita, consulte el n. ° 1540).

Solo se pensó como una solución temporal, para contrarrestar la desactivación del hyperthreading y la limitación a 1 trabajo simultáneo en a7.

a7 solo construye una pequeña parte (aproximadamente 2/5), por lo que la reducción a la mitad debería ser apenas perceptible. ¿O hay algún problema específico ahora? (Por el momento, por supuesto, se necesita tiempo para ponerse al día con los muchos trabajos del tiempo de inactividad).

a7 solo construye una pequeña parte (aproximadamente 2/5)

2/5 es 40%. No consideraría eso una pequeña parte.

¿O hay algún problema específico ahora?

No, de hecho parece funcionar mejor que antes.

Lo siento, quise decir alrededor de 2/6 (1/6 es i7, 3/6 es v2). Y esta parte no se elimina, solo se reduce.

No, de hecho parece funcionar mejor que antes.

¡Perfecto!

Parece que a7 ha vuelto a bajar 😭.

¡Gracias! Lo informé.

En el futuro sería excelente si el que detecta primero puede informarlo directamente a

herbert en complang.tuwien.ac.at

Basta decir que "a7 ist leider nicht erreichbar".

Y luego infórmalo aquí, para que herbert no reciba varios correos electrónicos.

Seguramente hay una manera de hacer que el servidor maestro de Jenkins envíe un correo electrónico de este tipo automáticamente y tal vez también publique en este problema de GitHub. Sería muy extraño, si no hubiera un complemento de Jenkins para una tarea tan simple ...

Sí, existe https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin pero no estoy seguro de que haga exactamente lo que queremos. También puede enviar correos electrónicos cuando alguien desanime al agente a propósito. Y es mucho más probable que el administrador maneje un correo electrónico personal más rápido.

Si automatizamos algo, entonces directamente el reinicio de las PC si son inalcanzables (¿tal vez incluso tengan algún tipo de perro guardián incorporado?)

a7 se ha reiniciado y el "control global C-State" está desactivado.

Sin embargo, no está en línea como agente de compilación.

Veamos si también se bloquea sin carga. v2 e i7 funcionan de nuevo.

El administrador (Herbert) no está disponible mañana, así que dejo a7 como agente de compilación por ahora.

Mi plan (si no hay protestas o a7 se bloquea antes) es activar a7 como agente de compilación mañana. Si a7 se bloquea de nuevo, Herbert puede reiniciar a7 el viernes. ¿Esta bien?

Si la cola no es demasiado larga, creo que deberíamos mantener el agente de compilación en a7 desactivado durante un poco más de tiempo. El último accidente ocurrió después de 3 días. Si lo habilitamos mañana, no sabremos si el agente de compilación causó el bloqueo o no, a menos que falle antes de esa fecha.

Bien, entonces veamos cómo se ve el tamaño de la cola.

Espero que el "control global C-State" finalmente solucione el problema y creo que necesitamos una gran carga para probarlo.

La cola era muy larga y las compilaciones maestras estaban todas colgadas, ya que necesitaban a7 para la implementación del sitio web.

Así que volví a poner en marcha el agente a7.

Algunos de los trabajos de compilación recientes de Jenkins se cancelaron debido a que faltaba espacio en disco en el servidor de compilación principal. Liberé algo de espacio eliminando registros de trabajos de construcción antiguos. Tenga en cuenta que es posible que también haya eliminado algunos archivos de registro de nuevos trabajos de compilación. En algunos casos, la compilación de Jenkins para su última confirmación puede haber fallado y ahora solo ve un mensaje junto a un error 404. En ese caso, por favor solo

• use jenkins build libelektra please en un comentario debajo del PR para reiniciar la compilación de Jenkins, o
• reescribe la última confirmación sin cambios (por ejemplo, usando git commit --amend ) y haz un empuje forzado

. Lo siento por los inconvenientes ocasionados.

¡Gracias por mantenerlo!

Marqué el nodo v2-debian-buster como temporalmente fuera de línea , ya que no parece funcionar correctamente. Para obtener más información, consulte el número 2995 (y el número 2994).

¡Gracias por buscar la infraestructura!

v2 se quedó sin espacio en disco. Ejecuté docker system prune Espacio total recuperado: 58.37GB

Luego reinicié v2 e hice que el agente se conectara nuevamente.

Ahora ejecuté du -h | sort -h para buscar otros archivos que eliminar.

Comencé v2 nuevamente con una nueva versión de Docker. Informe las compilaciones defectuosas de inmediato.

Reinstalé Docker, purgué todas las configuraciones y eliminé / var / lib / docker. Ojalá esto lo solucione.

v2 se incluirá de nuevo. Informe las compilaciones defectuosas de inmediato.

Como se sugirió aquí , ahora ejecuté

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

y también reinicié i7 (había muchas interfaces de red docker, ahora se han ido)

docker-ce ahora está en todas partes 5:19.03.1~3-0~debian-buster

Informe las compilaciones defectuosas de inmediato.

Parece que la compilación master falló nuevamente , debido a problemas de conexión con v2-debian-buster (ver también el número 2995).

Le pedí a nuestro administrador que mirara el cambio entre a7 / v2 / i7. Desactivé v2 e i7 por ahora.

Reinicié libelektra / master y libelektra-daily.

Cambiamos los puertos de las 3 PC.

Luego eliminé jenkins homedir en v2 / i7 y reinicié el agente v2 / i7.

Parece que no hay más espacio disponible en v2-debian-buster :

ApplyLayer exit status 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: no queda espacio en el dispositivo

.

Gracias por informar, hice (mucho) más espacio en la v2.

Eliminar trabajo terminado:

Tamaño del sistema de archivos utilizado% de uso disponible montado en
/ dev / sda3 417G 227G 164G 58% /

buildserver está inactivo debido a la migración (para que obtengamos un estado consistente en la copia de seguridad del nuevo buildserver)

https://build.libelektra.org/jenkins/ está comenzando de nuevo

La carga en el servidor de compilación fue de 200 debido a errores del kernel durante una copia de seguridad, el servidor ya no reaccionó y fue necesario reiniciarlo.

Los mensajes de registro fueron (ejemplos):

[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]

Ojalá podamos migrar pronto a principios de la próxima semana (¿ @Mistreated ?)

Actualmente, el servidor realiza una resincronización de la incursión, así que espere que sea muy lento.

Las compilaciones de Jenkins ya no se realizan, consulte # 3035

Jenkins ahora comenzó de nuevo. Repita los trabajos de construcción de Jenkins.

Parece que v2-debian-buster está conectado:

Abriendo la conexión SSH a a7.complang.tuwien.ac.at:22221.
Conexión rechazada (Conexión rechazada)

.

Gracias, me comuniqué con nuestro administrador, pero me temo que ya estará fuera de la oficina.

Herbert ya reinició v2 ayer. Inhabilitó el "multiproceso simultáneo".

Si un servidor (v2, i7, a7) vuelve a fallar, comuníquese también directamente con nuestro administrador a través de "herbert at complang.tuwien.ac.at". Informe también aquí para evitar varios correos electrónicos.

Creo que hay algo mal con el repositorio de Git para la rama master en 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

. Ya reinicié la compilación tres veces, pero Jenkins siempre falla con el mismo error.

Desafortunadamente, v2 tiene btrfs que a veces parece dañar los archivos. Un problema similar que ya tuvimos con un error docker pull . En el caso actual, el archivo 0bc3ca6fcbc610abd845aeff5f666938d24117 parece estar dañado. Al ejecutar md5sum en las apariciones de este archivo, obtengo:

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

Ahora eliminé todo el directorio del maestro y reinicié la compilación. Véase también # 3054

Como ahora no estaré disponible durante unos días, comuníquese con "herbert en complang.tuwien.ac.at" sobre problemas relacionados con a7 / i7 / v2 inalcanzables. @Mistreated será responsable de todo lo que no esté relacionado con el reinicio de los servidores. (Con suerte, pronto tendremos un nuevo agente de compilación).

También informe siempre aquí, para evitar múltiples correos electrónicos y para que todos tengan una buena visión general de lo que está sucediendo.

¿El servidor de compilación tiene actualmente un mal funcionamiento?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

¿El servidor de compilación tiene actualmente un mal funcionamiento?

Parece que el servidor de compilación principal de Jenkins no puede conectarse i7 . Marqué el nodo como temporalmente fuera de línea.

La compilación falla en casos arbitrarios:
Aquí fue interrumpido sin motivo alguno
Aquí falla un caso de prueba que no está relacionado con mi PR (acabo de agregar una decisión de diseño sin tocar ningún código)

Aquí fue interrumpido sin motivo alguno

Obtuve el mismo código de interrupción 143 para dos RP y aún no puedo explicarlos. Reinicié la compilación y espero que funcione ahora.

Aquí falla un caso de prueba que no está relacionado con mi PR

Esto debería arreglarse gracias a @sanssecours con # 3103. Por favor, cambie a master.

El nuevo nodo de Jenkins hetzner-jenkins1 no parece funcionar correctamente . Marqué el nodo como temporalmente fuera de línea.

Actualicé la ventana acoplable en i7 y reinicié la máquina. Espero que esto solucione el problema. El agente está en línea nuevamente. Informe los problemas aquí (y / o desactive el agente).

Actualmente se está ejecutando un trabajo de # 3065 en i7.

@Mistreated, ¿puedes depurar hetzner-jenkins1 por favor?

¿Existe la posibilidad de desactivar fácilmente una verificación de enlace durante algún tiempo?

Esto ha estado sucediendo durante todo el día:

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

Otros RP (más recientemente # 3115, # 3113) también se ven afectados. De acuerdo con downforeveryoneorjustme, los enlaces realmente no están disponibles.

ACTUALIZACIÓN: El sitio web todavía está desconectado. Hice un PR para este # 3117.

¿Existe la posibilidad de desactivar fácilmente una verificación de enlace durante algún tiempo?

Puede desactivar enlaces individuales agregándolos a tests / linkchecker.whitelist (como ya descubrió)

No puedo volver a ejecutar compilaciones fallidas de Cirrus. Ver https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

El botón no hace nada. ¿Existe algún truco de magia para que funcione?

editar: o alguien cambió algo o el x`th intento finalmente funcionó. ¡La compilación se está ejecutando de nuevo! :)

Parece que el agente de compilación a7-debian-buster no puede reiniciarse:

…
[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: o alguien cambió algo o el x`th intento finalmente funcionó. ¡La compilación se está ejecutando de nuevo! :)

Después de ver su comentario, también presioné el botón "Reiniciar trabajos de compilación fallidos". Por lo que puedo decir, presionar el botón reinició los trabajos de compilación fallidos.

Después de ver su comentario, también presioné el botón "Reiniciar trabajos de compilación fallidos". Por lo que puedo decir, presionar el botón reinició los trabajos de compilación fallidos.

Sin embargo, no funcionó para mí, ¡te daré un gif la próxima vez!

Reiniciaré el servidor de compilación y sus nodos. Los trabajos de compilación de # 3121 y # 3099 deben reiniciarse ya que tenían trabajos en agentes inactivos.

Sin embargo, no funcionó para mí, ¡te daré un gif la próxima vez!

No es necesario que proporciones un GIF, ya que ya te creo 😊.

Parece que jenkins tiene problemas para detenerse, espero un poco antes de matar a la fuerza todos los procesos de Java.

También actualicé Docker en todos los agentes (en i7 ya estaba actualizado).

Jenkins está de nuevo con el intervalo de latidos como se sugiere en el # 2984. Todos los nodos están conectados.

Reinicie todos los trabajos según sea necesario e informe cualquier problema aquí.

v2 está inactivo, le pedí a nuestro administrador que reiniciara.

Volví a habilitar v2, ya que parece estar activo y nuestra acumulación de compilación tiene el tamaño adecuado.

¿Hay algún problema con la compilación nuevamente ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

'

¿Hay algún problema con la compilación nuevamente ( hetzner-jenkins1 )?

Sí . Inhabilité el nodo.

Solo se superó la cuota de disco, no quería saturarla con memoria. Lo limpié ahora. Está arriba de nuevo.

Nodo actualizado.

Aumenté hetzner-jenkins1 a 4 compilaciones paralelas. Esta es solo una medida temporal siempre que no se esté ejecutando nada más allí.

Disminuí temporalmente el número de ejecutores en hetzner-jenkins1 de 4 a 2, ya que se agota el tiempo de espera del conjunto de pruebas. Creo que esto sucede cuando se compilan demasiados trabajos mientras se ejecutan las pruebas. Es posible que necesitemos limitar los recursos disponibles a un solo contenedor para que no interfiera demasiado con otros trabajos.

Siéntase libre de corregirlo si cree que este fue el enfoque incorrecto.

EDITAR: se redujo a 1 ya que las pruebas aún se agotan y la reconstrucción constante desperdicia aún más recursos.

@mpranj ¡ Gracias por arreglarlo!

@mistreated , ¿quizás solo asignó una sola CPU o similar? ¿Puede asignar más y aumentar el número de ejecutores? El hardware debería ser más fuerte que v2.

Inhabilité i7-debian-buster porque no queda espacio en el disco, lo que provoca que todas las compilaciones fallen. Si alguien tiene acceso, limpie algo y vuelva a habilitarlo.

@mpranj gracias por inhabilitar!

Lo siento, donde estoy actualmente ssh está bloqueado (algunas aplicaciones de firewall, también ssh en otros puertos no funcionan). Entonces no puedo dar acceso ni hacer ninguna limpieza ahora.

Como i7 es el más débil de los agentes, puede que no sea gran cosa de todos modos.

@Mistreated , ¿tal vez solo asignó una sola CPU o similar? ¿Puede asignar más y aumentar el número de ejecutores? El hardware debería ser más fuerte que v2.

No tengo idea de lo fuerte que es v2.
Actualmente jenkins1 usa 4 CPU con 8 de memoria y 16 de intercambio. Puedo aumentarlo fácilmente, pero no sé hasta qué punto quieres que lo aumente.

Una nota para las futuras decisiones de hardware: phoronix parece hacer pruebas de compilación en sus artículos de CPU (por ejemplo, Ryzen 7 3700X, prueba de Ryzen 9 3900X, hacia el final del artículo ).

Parece que hetzner agregó recientemente AMD Ryzen 7 3700X a sus servidores basados ​​en AMD.

No tengo idea de lo fuerte que es v2.

@ingwinlu escribió sobre esto en su tesis (que se encuentra en abgaben repo lukas_winkler)

Actualmente jenkins1 usa 4 CPU con 8 de memoria y 16 de intercambio. Puedo aumentarlo fácilmente, pero no sé hasta qué punto quieres que lo aumente.

Siempre que no tengamos nada más ejecutándose en el servidor, puede asignar todos los recursos. Más tarde todavía podemos bajar (cuando movemos a Jenkins).

Actualicé el archivo hetzner-jenkins1.
Se corrige el error con el frontend donde se queda sin memoria.
Ahora ejecuta 2 compilaciones paralelas.

Parece que no queda espacio en v2-debian-buster :

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

.

Gracias, también lo marqué sin conexión, hasta que alguien tenga acceso para limpiarlo.

hetzner-jenkins1 acaba de fallar mis 3 PR porque se superó la cuota de disco. Aquí está en la salida:

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

Se marcó hetzner-jenkins1 como fuera de línea porque se superó la cuota de disco.

Limpié i7 y v2 (eliminando / home / jenkins / workspace / * y ejecutando docker system prune ). Ahora tenemos:

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

Luego reinicié a los agentes.

@ Maltratado , ¿puedes arreglar # 3160 para que esto no vuelva a ocurrir tan rápido? Por favor, corrija también hetzner-jenkins1. Hay muchos recursos en esta máquina, realmente no es necesario que alcance un límite de recursos todos los días.

No sé si hay una buena manera de reducir el tamaño del disco. Es por eso que no le voy a dar todo al nodo de una vez ... Hetzner está activo de nuevo.

v2 estaba nuevamente sin espacio, limpié: / dev / sda3 417G 315G 102G 76% /

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log no se inicia

Creo que el sistema de compilación está completamente atascado actualmente, los RP no se están construyendo.

Gracias por informar, reiniciaré Jenkins y limpiaré algunos archivos cuando el disco esté lleno.

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log no se inicia

Agente conectado con éxito y en línea

Supongo que todo está bien ahora con hetnzer-jenkins1.

¡Muchas gracias! Parece que Jenkins todavía no reacciona a las compilaciones. v2 y i7 ahora los dos falla con: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins está activo nuevamente, reinicie los trabajos.

java.io.IOException: no se pudo copiar slave.jar en '/ home / jenkins' en slave.

fijo (también se quedó sin espacio)

@Mistreated, por favor corrija el jenkins-daily, ya que esto hace que las tareas de limpieza que ahora siempre necesitamos hacer manualmente.

@Mistreated "jenkins build libelektra please" todavía está roto, ¿esto está relacionado con los cambios de los webhooks?

Tal vez intente hoy cambiar al nuevo Jenkins, pero si no puede hacerlo, ¡haga que la instancia anterior funcione nuevamente!

Activé un escaneo del repositorio, ahora el "jenkins build libelektra please" parece funcionar de nuevo.

Parece que el disco está lleno por v2-debian-buster

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

Desafortunadamente. Marqué v2 como fuera de línea hasta que se resuelva.

¡Gracias por informar!

@mpranj Te di acceso, ¿puedes intentar limpiar, por favor?

¡Gracias! Me parece que hay una gran cantidad de recursos desperdiciados por imágenes antiguas de Docker por ahí. Además, parece que btrfs + docker tienen errores. Docker crea subvolúmenes btrfs para cada contenedor y no los limpia correctamente después. El comando docker system prune -f tampoco libera espacio.

Tomé v2 y a7 por mantenimiento para liberar los recursos y equilibrar los btrfs.

error de inicio de sesión de Docker

Construya imágenes de Docker que no pueden extraer. ¿Algo está sucediendo con Docker Hub?

Sí, lo siento, con a7 también eliminé el concentrador de la ventana acoplable. Publicaré un mensaje aquí cuando vuelva a estar activo.

a7 incluido el concentrador de docker, está activo nuevamente. Dejé v2 sin conexión porque no puede iniciar sesión en el hub para extraer imágenes?!? No sé qué pasa allí, no cambié ninguna credencial o algo así y los otros nodos pueden iniciar sesión. ¿Algunas ideas?

Btrfs todavía se está equilibrando en segundo plano, a7 puede ser más lento durante una hora más o menos.

@mpranj ¡ Gracias por arreglar esto! ¿Qué comandos fueron necesarios para el reequilibrio de btrfs?

Desafortunadamente, no conozco las credenciales, espero que @ingwinlu pueda ayudarnos.

Los comandos que usé para reequilibrar fueron:

Corregir un error de tal vez con btrfs:

btrfs balance start -dusage=0 -musage=0 /mountpoint

Vuelva a equilibrar las fs realmente, esto lleva mucho tiempo. El parámetro de uso puede / debe ajustarse, esto es lo que funcionó hoy:

btrfs balance start -dusage=80 /

Las credenciales se pueden cambiar fácilmente, pero tendríamos que iniciar sesión en todos los agentes de jenkins que se conectan al concentrador de Docker nuevamente con las nuevas credenciales.

El mayor problema fue que algunos contenedores de la ventana acoplable todavía se estaban ejecutando y la poda del sistema de la ventana acoplable no hizo mucho. Por lo tanto, eliminé a los agentes y liberé todo mientras estaba inactivo. Había TONELADAS de contenedores por ahí.

Sí, lamentablemente los contenedores se recrean rápidamente. Espero que @Mistreated pueda arreglar el trabajo libelektra-daily pronto (ejecuta docker system prune ).

También hice algunos análisis forenses digitales bastante complicados y robé las credenciales del centro. :risa:

v2 está en funcionamiento de nuevo.

¡Muchas gracias! : 100: Envíenos las credenciales.

Enviado. Por cierto, creo que a7 probablemente sea lento solo debido a las bajas velocidades del disco, pero es bueno que tenga suficiente espacio para el concentrador de la ventana acoplable. Parece que la mayor parte del tiempo la CPU no hace nada allí.

Otro pensamiento: tal vez podamos hacer los trabajos de limpieza críticos adicionalmente por cronjob para evitar situaciones como las que teníamos ahora.

Envíenos las credenciales.

@mpranj Creo que estaba en este grupo de "nosotros". ¿No estaba en algún CC o algo así?

@ Maltratado lo siento, se lo envié a markus y no tenía tu correo electrónico. En a7 encontrará CREDENTIALS.txt en su directorio de inicio.

Necesito el nodo hetzner-jenkins1 para probar el nuevo servidor jenkins. Lo apagaré en el servidor antiguo hasta mañana por la mañana.

Puede crear fácilmente un segundo hetzner-jenkins2 para las pruebas. Sin embargo, si es solo por esta noche, debería estar bien.

Otro pensamiento: tal vez podamos hacer los trabajos de limpieza críticos adicionalmente por cronjob para evitar situaciones como las que teníamos ahora.

libelektra-daily hace estos trabajos de limpieza pero falla ahora: # 3160. Si tiene ideas para mejorar este trabajo, comuníquenoslo.

Creo que estaba en este grupo de "nosotros". ¿No estaba en algún CC o algo así?

Sí, lo siento, olvidé decirle a mpranj que "nosotros" se refiere a usted.

Espero que esté bien que mantenga hetzner-jenkins1 por un tiempo, todas las compilaciones son buenas ahora, creo que puedo hacer que el servidor funcione completamente esta noche.

v2 está disponible, me comuniqué con el administrador.

Espero que esté bien que mantenga hetzner-jenkins1 por un tiempo, todas las compilaciones son buenas ahora, creo que puedo hacer que el servidor funcione completamente esta noche.

¡Esto sería genial!

v2 es inalcanzable, me comuniqué con el administrador.

Gracias, pero me temo que no responderá antes del lunes.

v2 obtiene un nuevo kernel (acaba de fallar).

i7 también se reiniciará.

Los 3 servidores (v2, a7, i7) ahora tienen "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 "

Están activos y en línea, reinicie los trabajos si es necesario.

Solo una nota:
Escaneé el repositorio nuevamente con el nuevo servidor. Esto podría generar algunos errores en el anterior.

Parece que master [1] también se construyó en el nuevo servidor. No fue exitoso. Al hacer clic en el estado, aparece una página de inicio de sesión [2]. Vuelva a configurar Jenkins para que todo se pueda ver sin iniciar sesión.

Con suerte, pronto podremos cambiarnos al nuevo Jenkins. Ver errores de dos Jenkins diferentes no facilita la situación: guiño:

[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 ¿ se puede reiniciar a7 / v2 de forma remota después de una actualización o hay algunos inconvenientes?

Por lo general, funciona, pero si no es urgente, es mejor esperar hasta que el administrador esté allí. ¿Puedo reiniciar el martes si te parece bien?

¡Gracias! Nada urgente, solo una pregunta general. Surgió porque Debian 10.2 acaba de ser lanzado. Esperaré un poco con las actualizaciones.

No obstante, puede realizar la actualización (solo sin reiniciar). Luego, en el caso de una falla, ya tendremos el kernel 10.2 cuando el administrador presione el botón de reinicio: guiño:

@mpranj, ¿puedes agregar un cronjob que elimine las instantáneas antiguas? ¿O esto no es posible sin detener Docker?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ recomienda también reequilibrar btrnfs en un cronjob.

¿Puede agregar un cronjob que purgue las instantáneas antiguas? ¿O esto no es posible sin detener Docker?

Puedo agregar un cronjob sin detener todos los contenedores de la ventana acoplable. Puede que esto no limpie todo, pero podemos intentarlo. Como dije, a veces los contenedores siguen funcionando para siempre / hasta que la máquina falla. Sin embargo, la limpieza completa requiere que deshabilitemos temporalmente el agente de compilación, luego podemos forzar la detención de todos los contenedores.

También puedo agregar el reequilibrio como cronjob.

Gracias, probémoslo.

El maestro no tiene memoria. Quería ejecutar Scan Repository en el antiguo Jenkins porque a7 e i7 obtienen el siguiente error al extraer imágenes de la ventana acoplable:

error de inicio de sesión de Docker

Tengo v2 y hetzner-jenkins1 ejecutándose en el nuevo servidor ahora.

El maestro no tiene memoria.

Gracias por informarnos. Eliminé algunos datos de cobertura antiguos y volví a habilitar el nodo maestro. Para todos con solicitudes de extracción abiertas: reinicie sus compilaciones de Jenkins con jenkins build libelektra please . Lo siento por los inconvenientes ocasionados.

En # 3234 @ raphi011 sugirió:

En mi opinión, esto es realmente urgente, la escasez y la lentitud de las pruebas hacen que sea difícil, si no imposible, hacer cambios si tiene que esperar tanto tiempo para verificarlos.

Estoy de acuerdo en que es realmente urgente pero @Mistreated ya hace lo que puede.

Entonces, tal vez podamos usar el servidor de compilación con más moderación y solo compilar si realmente pensamos que el RP se fusionará pronto. Las compilaciones innecesarias deben cancelarse.

¿O qué tal si se detiene (temporalmente) la creación automática de RP al impulsar cambios (por lo que la creación comienza solo con jenkins build libelektra please )? @ Maltratado , ¿sabes cómo reconfigurar Jenkins para hacerlo (no encontré la opción)?

También tengo la sensación de que jenkins build libelektra please no funciona en este momento, al menos no funcionó para esta compilación: https://github.com/ElektraInitiative/libelektra/pull/3073 tuve que presionar un confirmación vacía para iniciar la canalización.

Se implementó el cronjob de limpieza y se actualizó el kernel de backport en a7 y v2. Hay bastante registro de cambios para el kernel, estará activo en el próximo reinicio.

¡Muchos gracias! ¿El kernel de backport "antiguo" todavía está instalado para que tengamos un respaldo si no arranca?

Sí, se puede eliminar después de un arranque exitoso en el nuevo 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

Inhabilité i7 para una limpieza manual, actualización del kernel y de la ventana acoplable. Alguien habilitó i7 mientras estaba trabajando en ello. Todo está funcionando de nuevo.

@Piankero Reinicié tu compilación ahora.

También tengo la sensación de que jenkins build libelektra please no funciona en este momento, al menos no funcionó para esta compilación: # 3073 tuve que presionar una confirmación vacía para iniciar la canalización.

funciona ahora

@ Maltratado , ¿sabes cómo reconfigurar Jenkins para hacerlo (no encontré la opción)?

Agregué lo siguiente a la configuración de Jenkins:

Suprime la activación automática de SCM

Nota para todos: el uso de "jenkins build libelektra please" ahora es obligatorio, los trabajos de compilación no comienzan simplemente presionando. Informaremos aquí, cuando revertimos esta configuración.

@ Maltratado gracias! Veamos si esto es suficiente. ¿Espero que los empujes para dominar aún activen las compilaciones maestras?

Sin embargo, tener el nodo de Hetzner sería muy bueno. ¿Hay algún problema si dos servidores de compilación utilizan el nodo al mismo tiempo? O si es un problema: ¿no es muy fácil simplemente clonar la TC?

@ Maltratado gracias! Veamos si esto es suficiente. ¿Espero que los empujes para dominar aún activen las compilaciones maestras?

La rama maestra ahora es una excepción a la siguiente regla:

Suprime la activación automática de SCM

Como para

Sin embargo, tener el nodo de Hetzner sería muy bueno. ¿Hay algún problema si dos servidores de compilación utilizan el nodo al mismo tiempo? O si es un problema: ¿no es muy fácil simplemente clonar la TC?

Agregué un nuevo CT (hetzner-jenkinsNode3).

no se pudo clonar el repositorio: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

tal vez esto tenga algo que ver con el nuevo nodo? (suposición salvaje)

tal vez esto tenga algo que ver con el nuevo nodo? (suposición salvaje)

este error está en a7

este error está en a7

muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu ...

muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu ...

sí, no creo que vuelva a suceder ...

Lo volveré a ejecutar para ti.

@Mistreated Creo que podemos volver a iniciar las compilaciones automáticas. Pero primero mire el número 3160.

¿Alguna idea de por qué esto fallaría?

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

¿Alguna idea de por qué esto fallaría?

Parece que se trataba de un problema temporal, actualmente los agentes de compilación pueden acceder a la URL.

A la larga, sería genial configurar ese tipo de dependencias en las imágenes de la ventana acoplable, para evitar descargarlas para cada compilación repetidamente. Eso también debería evitar fallas de compilación debido a paquetes temporalmente no disponibles como mencionaste anteriormente.

Bueno, entonces ... jenkins build libelektra please el tercero

Sí, tenemos todas las dependencias directamente en las imágenes de la ventana acoplable exactamente por este motivo. Yo creé # 3251

Tomé v2 y a7 sin conexión para reiniciar.

@ markus2330 si tienes la oportunidad, habilita el hyperthreading en a7 .

v2 está activo de nuevo, en a7 todavía hay un trabajo de compilación.

Tomé nodos y los agregué al nuevo servidor. Voy a dejarlo correr durante la noche. Mañana devolveré los nodos si hay más errores en el nuevo servidor Jenkins.

hetzner-jenkinsNode3 aún se ejecutará en el antiguo Jenkins.

Mañana devolveré los nodos si hay más errores en el nuevo servidor Jenkins.

Los pequeños errores de compilación no son una razón para volver atrás. En algún momento necesitamos corregir los errores, el ir y venir lleva mucho tiempo.

Sin embargo, lo que podría ser un obstáculo es que no se puede acceder al nuevo servidor. (Ninguno
http://95.217.75.163:8066 ni ssh). Presioné el botón de encendido, veamos si la máquina se reinicia. Sin embargo, deberíamos investigar cuál fue el problema.

http://95.217.75.163 : 8066

Si hay tiempo, habilite TLS usando letsencrypt, para que no filtremos credenciales y nos expongamos a otros problemas.

¡Gracias por la aportación! Sugeriría que hagamos esto inmediatamente cuando cambiemos build.libelektra.org. De lo contrario, tenemos un doble esfuerzo.

¿Se conoce este error ? Caught the following exception: null

Parece que la verificación de formato falló y las otras compilaciones terminaron.

tienes razón. Sin embargo, qué mensaje de error más horrible: P

@Mistreated , ¿puedes volver a activar que los RP se construyan automáticamente? Debido a la gran cantidad de agentes, el servidor ahora está durmiendo la mayor parte del tiempo.

@Mistreated , ¿puedes volver a activar que los RP se construyan automáticamente? Debido a la gran cantidad de agentes, el servidor ahora está durmiendo la mayor parte del tiempo.

Hecho.

Voy a pedir prestado hetzner-jenkins1 y v2 nuevamente para el nuevo servidor.

No es necesario que lo devuelva, espero que podamos hacer el cambio hoy.

Consejo: al hacer este tipo de cambios, es bueno reducir el TTL de la entrada DNS a algo inusualmente bajo (por ejemplo, 60 en lugar de 21599 actualmente para build.libelektra.org). Una vez que se haya propagado el cambio, deberíamos permitirnos cambiar la entrada de DNS en un minuto en lugar de horas. Si es demasiado tarde, puede ayudar a borrar las cachés de DNS de google y opendns, pero algunas personas inevitablemente verán el recurso antiguo hasta que las entradas en caché caduquen globalmente.

EDITAR: después del cambio, el TTL obviamente debería revertirse a algún valor sensato para poner menos carga en el DNS.

Aunque ahora es quizás demasiado tarde, cambié $TTL 3600 (si necesitamos varios cambios hasta que todo funcione).

www-new y build-new ya existen apuntando al nuevo servidor.

Ahora cambié doc.libelektra.org. @Mistreated arreglará la publicación. Buscaré en www-new.libelektra.org

https://build-new.libelektra.org/ y https://www-new.libelektra.org/home deberían funcionar ahora.

Cambiaré todas las entradas de DNS ahora.

Se cambian todas las entradas de DNS.

Desafortunadamente, certbot falla ya que parece hablar con el servidor anterior, pero esto parece afectar solo la descarga y la comunidad (URL menos utilizadas).

Entonces, con suerte, durante / después del fin de semana, todos verán los nombres DNS actualizados.

@Mistreated , actualice la publicación de todos los artefactos: también para el sitio web. Cree un PR para asegurarse de que todo funcione correctamente.

El servidor de compilación anterior ahora está apagado.

Necesito reiniciar el nuevo servidor (se agregaron nuevos kernel y puente de red).

El servidor vuelve a funcionar con Linux pve 5.0.21-5-pve.

Programé una nueva exploración de todos los RP.

servidor fuera de línea debido a una mala configuración / error en pve (/ etc / network / interfaces fue eliminado por GUI?).

El error fue que el cambio de nombre de los dispositivos de red (que fue causado por mi acción en la GUI) condujo a un kernel OOPS:

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

El servidor debería estar en funcionamiento de nuevo.

Sin embargo, persisten los problemas anteriores (la frase no funciona # 3268)

@Mistreated master tampoco parece construirse automáticamente más, lo activé manualmente ahora.

Estoy recopilando errores urgentes en # 3268. Sería bueno si también pudiera probar si todo funciona como se describe en doc / BUILDSERVER.md.

jenkins no construye sin una razón dada:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Otro error de compilación: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

¡Gracias por informar!

@Mistreated, ¿ podría instalar Naginator + Plugin # 2967 como ya se ha discutido muchas veces? (Haga una instantánea antes de realizar cambios en Jenkins).

hetzner-jenkins1 : se superó la cuota de disco

@Mistreated, ¿ podría instalar Naginator + Plugin # 2967 como ya se ha discutido muchas veces? (Haga una instantánea antes de realizar cambios en Jenkins).

Lo haré hoy

hetzner-jenkins1: se superó la cuota de disco

@mpranj Agregué el nuevo VM como agente de compilación mientras que hetzner-jenkins1 está inactivo.

Limpié algo de espacio en hetzner-jenkins1 ejecutando docker system prune -a y lo habilité nuevamente.

Parece que hay de nuevo un problema de que muchas cosas no se limpian con docker system prune -f . Esta vez, el controlador de almacenamiento no fue btrfs sino vfs . :confundido:

Agregué la nueva VM como agente de compilación mientras hetzner-jenkins1 está inactivo.

La idea ahora es que ya no usemos el contenedor, sino solo la VM.

Limpié algo de espacio en hetzner-jenkins1 ejecutando docker system prune -a y lo habilité nuevamente.

¡Muchos gracias! ¿También puedes hacer un cronjob allí? (en la VM, no en el contenedor).

hacer un cronjob allí?

Hecho.

@Mistreated, ¿ podría instalar Naginator + Plugin # 2967 como ya se ha discutido muchas veces? (Haga una instantánea antes de realizar cambios en Jenkins).

Tenemos que pasar de la canalización al trabajo de estilo libre, si queremos el complemento naginator. Voy a buscar alternativas.

Las compilaciones de la VM jenkinsNode3VM fallan actualmente. No pueden tirar de la ventana acoplable:

unexpected EOF
script returned exit code 1

Lo desactivé por ahora hasta que alguien pueda solucionar el problema.

[cronjob] Hecho.

¡Gracias!

Tenemos que pasar de la canalización al trabajo de estilo libre, si queremos el complemento naginator. Voy a buscar alternativas.

Sí, buena idea. Tal vez sea mejor simplemente codificar eso en nuestro archivo Jenkins. Entonces, si un trabajo / etapa de construcción problemático falla, se vuelve a intentar. Que estos docker pull se prueben al menos dos veces, ya que este es uno de los problemas más frecuentes.

Las compilaciones de la VM jenkinsNode3VM fallan actualmente. No pueden tirar de la ventana acoplable:

@ Maltratado, por favor arregle esto.

Las compilaciones de la VM jenkinsNode3VM fallan actualmente. No pueden tirar de la ventana acoplable

Arreglé la imagen de la ventana acoplable que no se podía extraer.

¡Muchos gracias! Siempre es útil si escribe lo que estaba mal y cómo lo solucionó.

No tengo idea de lo que estaba mal, construí la imagen manualmente en el agente. Dado que el agente no pudo tirar de él.

En cuanto a Dockerfile (scripts/docker/debian/stretch) my Visual Code dice que tiene 2 líneas vacías al final, pero vim dice que es la única. No sé si tiene que hacer algo con el error anterior, tal vez sea solo mi VS .

Parece que tenemos problemas con nuestro registro de Docker (# 3316 Docker Pull falla con unexpected EOF ).

Dado que el polvo después del lanzamiento se ha asentado y no hay compilaciones, sugeriría detener todo e intentar borrar el registro por completo. Después de eso, todas las imágenes deberían reconstruirse con suerte de forma limpia. Haría una copia de seguridad de los datos del registro antes de comenzar solo para asegurarme, pero espero que un comienzo limpio elimine algunos de los errores que estábamos teniendo.

Esperaré a comentar si hay algo en contra de eso antes de comenzar.

Creo que es un problema en el

(scripts / docker / debian / stretch)

imagen, ya que es la única que falla.

Lo he construido manualmente de nuevo, pero ciertamente hay algo mal con la imagen en el registro.

Jenkins informa: jenkinsNode3VM (sin conexión)

@Mistreated sería genial si pudiera configurar alguna forma de monitoreo.

a7 (y por lo tanto v2 y i7 ) están abajo. Me comuniqué con el administrador.

EDITAR markus2330: arriba de nuevo

Debido a un corte de energía planeado el 08.07.2020 en TU Wien, nuestro administrador planea apagar todos los servidores de compilación el día anterior (martes 7.7). Las compilaciones serán muy lentas durante ese tiempo, así que solo presione ese día en casos urgentes.

Los servidores vuelven a estar en línea, excepto el i7. Notifiqué al administrador.

Hubo otro corte de energía (no planeado) ayer por la noche, por lo que todos los servidores de compilación están inactivos ahora. El administrador está trabajando en ello.

EDITAR 30 minutos después: todo, incluido i7, está activo nuevamente: cohete:

@ markus2330 parece que v2 e i7 han perdido el acceso a Internet recientemente (¿posiblemente durante el corte de energía?). ¿Conoce algún cambio de configuración que deberíamos haber hecho, ya que las interfaces están configuradas estáticamente?

No sé de ningún cambio, solo de que las computadoras se volvieron a encender después de estos dos cortes de energía (uno planeado, el otro no planeado).

Pero tienes razón, también veo que estos dos (pero no a7) ya no tienen conexión a Internet, aunque son accesibles. Le pregunté a nuestro administrador sobre eso.

¿Quizás los desconectemos de Jenkins hasta que se solucione este problema?

¡Gracias por contactar al administrador! Desconecté tanto i7 como v2 hasta que se pueda resolver el problema. (Las compilaciones no funcionan de todos modos porque no pueden extraer imágenes de la ventana acoplable)

Alguien cambió algo con el enrutador hace aproximadamente una semana. La persona fue notificada y con suerte lo solucionará pronto.

Mantengamoslos desconectados por ahora.

El problema de Internet está resuelto ahora y también instalé las actualizaciones de seguridad en estas máquinas.

@mpranj, ¿ puedes

Gracias @ markus2330.

Todos los nodos están ahora de nuevo en línea.

Reinicié el servidor de compilación para el último kernel PVE. Jenkins debería estar despierto en breve.

Me mudé

• [] hacer que el envío de correos electrónicos si la compilación falla sea más confiable
• [] Imagen de Docker sin usuario de Jenkins
• [] imágenes de centOS / fedora / arch docker
• [] paquetes centOS
• [] agentes de compilación freebsd / openbsd / solaris

al # 3519 y vinculado al # 3519 anterior.

@robaerd ahora también tiene acceso a a7 / v2 / i7 y puede contactar al administrador en caso de problemas.

Solo un informe rápido de los tiempos de compilación (canalización principal libelektra ):

• con a7 habilitado: 2h 29m 24s
• con a7 discapacitados: 1h 35m 45s

¿Por qué Jenkins muestra que se apaga? Sería bueno leer siempre aquí con anticipación: guiño:

Jenkins se cerrará debido a una copia de seguridad completa del sistema y al reformateo de los sistemas de archivos de btrfs a ext4.

Jenkins está despierto de nuevo

Jenkins CI estará fuera de línea por mantenimiento a partir de las 11:15 CET de hoy.

Realizaremos algunas tareas de copia de seguridad y limpieza e intentaremos mejorar el rendimiento de a7 .

Se le notificará nuevamente cuando finalice el mantenimiento.

Jenkins CI y todos los servidores de compilación están funcionando nuevamente. a7 debería funcionar mucho mejor ahora, pero tiene menos capacidad de almacenamiento.

Informe si experimenta algún error.

Jenkins CI y los agentes de compilación estarán fuera de línea para un breve mantenimiento / actualizaciones.

EDITAR: las actualizaciones están hechas.

El servidor no funciona, investigo.

El servidor vuelve a funcionar.

Declaración oficial sobre la causa: "Hubo un problema con la fuente de alimentación en el servidor adyacente que hizo que el servidor se apagara; ahora se ha corregido".

El ssd en a7 está lleno, lo que hace que fallen todas las compilaciones.

Intentaré liberar algo de espacio. ¿Es seguro desconectar el agente de compilación a7 de jenkins por ahora?

¡Gracias por investigarlo!

Intentaré liberar algo de espacio. ¿Es seguro desconectar el agente de compilación a7 de jenkins por ahora?

Por supuesto. Por el contrario, no sería seguro mantenerlo conectado si hace que todas las compilaciones fallen.

Ejecutar docker system prune -a limpió aproximadamente el 50% del espacio nuevamente. ¿Quizás necesitamos adaptar el cronjob existente para agregar la bandera -a ?

La casa de los jenkins también está ocupando mucho espacio.

Las compilaciones maestras (canalización completa con paquetes deb y creación de sitios web) de alguna manera todavía están fallando, aunque todo parece verde. ¿Algunas ideas?

La carga de los paquetes deb focales a community falla en el archivo elektra_0.9.3.orig.tar.gz . Probablemente sea un problema de permisos en el archivo. Lo eliminaré del directorio por ahora y dejaré que se vuelva a crear en la próxima ejecución.

De alguna manera, sshPublisher, si falla, no pone el escenario en rojo.

¿Quizás necesitamos adaptar el cronjob existente para agregar el indicador -a?

¿Hubo alguna razón por la que no lo hiciste así? Si no es así, parece una buena idea.

Jenkins CI y el registro en a7 estarán fuera de línea para la migración de la imagen de la torre de vigilancia a una nueva versión. Solo debería tomar un par de minutos.

EDITAR: las actualizaciones están hechas y Jenkins CI está activo de nuevo

Jenkins y los agentes bajarán brevemente para recibir una actualización.

EDITAR: todo se actualizó y está en funcionamiento nuevamente. Necesitaba corregir un problema en el que a7 estaba usando paquetes de Debian stretch docker en lugar de buster. También limpié algo de espacio.

Las compilaciones fallan porque no hay espacio en a7 .

La infraestructura de construcción no estará disponible durante unos minutos por mantenimiento.

La infraestructura de construcción está disponible nuevamente.