¡Gracias por recopilar los números!

Para las compilaciones de maven ya tenemos un problema: # 2855

Para las compilaciones de maven ya tenemos un problema: # 2855

Lo sé 😊. Ya agregué un enlace en la descripción del problema.

Gracias por esta elaborada investigación. Ahora tenemos que solucionar un problema tras otro.

Para los problemas de Haskell, podemos eliminar los enlaces / complementos de Haskell. De todos modos, no se mantienen.

Haskell será eliminado en el # 3017

Las fallas con docker pull fallando en la etapa del sitio web ocurren con bastante frecuencia ahora.

También tengo problemas de conexión para build-elektra-web-base.

3d070e3209ce: Retrying in 1 second

error creating overlay mount to /home/_docker/overlay2/e9563564b9365114c47d90b7e8d307565225097a525e6b1b866a2da2877b2aa8/merged: device or resource busy

script returned exit code 1

Este es un registro completo.

Las fallas con docker pull fallando en la etapa del sitio web ocurren con bastante frecuencia ahora.

¿Es esto todo el reintento y la espera después de Pulling from build-elektra-web-base ( log )?

Además, creo que este error es nuevo: test_service_convertengine falla durante Starting build/hub.libelektra.org/build-elektra-website-backend ( log 2 )

Sí, acepto que test_service_convertengine aún no se informa aquí. De hecho, podemos desactivar la prueba ya que el servicio no se modifica de todos modos.

@sanssecours, ¿hay algún procedimiento para agregar nuevas pruebas en la lista anterior?

@sanssecours, ¿hay algún procedimiento para agregar nuevas pruebas en la lista anterior?

No Ya dejé de modificar la lista, ya que la compilación de Jenkins falla con demasiada frecuencia. Recomendaría que abramos un número para cada problema específico.

Para cuestiones relacionadas con el código fuente, estoy de acuerdo. Para los problemas relacionados con la inestabilidad de Docker / Jenkins, es suficiente recopilar los problemas aquí, ya que es muy limitado lo que podemos hacer junto con la migración que ya hacemos, pero lamentablemente lleva más tiempo como se esperaba. Sería bueno si @Mistreated pudiera dar más información sobre el estado, tal vez en el # 160.

Además, creo que este error es nuevo: test_service_convertengine falla durante el inicio de build / hub.libelektra.org / build-elektra-website-backend (log 2)

¿Puede informar eso por separado? La solución es desactivar las pruebas.

¿Puede informar eso por separado?

Listo, vea # 3086

Creo que nuestra mejor suposición para hacernos la vida mucho más fácil es "solucionar" estos problemas usando https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin

Entonces Jenkins reiniciará los trabajos fallidos varias veces. Creo que podríamos intentar 5 reinicios antes de rendirnos.

@Mistreated ¿Puede implementar esto también en el servidor anterior? ¿O es esto demasiado arriesgado?

Sin embargo, antes de implementar esto, necesitamos el nuevo nodo Jenkins, de lo contrario, la cola se volverá demasiado larga.

Después de luchar un poco, logré agregar un nuevo Jenkins Node.

Sin embargo, antes de implementar esto, necesitamos el nuevo nodo Jenkins, de lo contrario, la cola se volverá demasiado larga.

En mi opinión, el servidor antiguo está sobrecargado, pero podemos intentarlo, supongo ...

Después de luchar un poco, logré agregar un nuevo Jenkins Node.

Gracias por agregar el nuevo nodo de Jenkins. Inhabilité el nodo por ahora, ya que parece romper la compilación .

Actualicé el nodo. Debería funcionar ahora. Si algo sale mal, puedes actualizarme aquí nuevamente.

Si algo sale mal, puedes actualizarme aquí nuevamente.

Parece que docker pull falla en hetzner-jenkins1 , ya que el nodo no tiene suficiente espacio libre:

No se puede contactar con hetzner-jenkins1: hudson.remoting.RequestAbortedException: java.io.IOException: terminación inesperada del canal
no se pudo registrar la capa: ApplyLayer estado de salida 1 stdout: stderr: write / usr / lib / git-core / git-credential-store: se superó la cuota de disco

.

Parece que docker pull falla en hetzner-jenkins1, ya que el nodo no tiene suficiente espacio libre:

Nodo actualizado.

Los trabajos de compilación en hetzner-jenkins1 parecen fallar debido a problemas relacionados con los permisos:

Recurso: No se pudo crear el directorio '/.config'. Razón: Permiso denegado. Identidad: uid: 47000, euid: 47000, gid: 47000, egid: 47000

.

Actualicé el nodo, de nuevo, ya no debería haber problemas de permisos.

¿Por qué Jenkins quiere construir un directorio '/.config' y no solo '.config'?
Hay un directorio .config dentro de '/ home / jenkins /' pero quiere crear la carpeta .config en '/'.

No creo que el usuario 'jenkins' deba poder hacer eso.

@Mistreated, por favor también haga un PR para probar si las compilaciones funcionan ahora.

¿Por qué Jenkins quiere construir un directorio '/.config' y no solo '.config'?
Hay un directorio .config dentro de '/ home / jenkins /' pero quiere crear la carpeta .config en '/'.

Esto puede suceder si el directorio de inicio del usuario es /. ¿Ha mirado en / etc / passwd, tal vez algo anda mal allí?

Esto puede suceder si el directorio de inicio del usuario es /. ¿Ha mirado en / etc / passwd, tal vez algo anda mal allí?

' jenkins: x : 47000: 47000 :: / inicio / jenkins: / bin / sh'

Todo se ve bien, incluso en los registros del nodo:

'INICIO =' / inicio / jenkins ''
'NOTA: Ruta remota relativa resuelta en: / home / jenkins /.'

Sería más fácil depurar para ver un PR con todo el registro.

El nodo maestro está inactivo.

Sería más fácil depurar para ver un PR con todo el registro.

3134

El nodo maestro está inactivo.

Gracias por la información. Eliminé toda la información de registro para solicitudes de extracción antiguas y volví a habilitar el nodo. Desafortunadamente, la cantidad de espacio libre en el master de Jenkins sigue siendo muy baja (~ 3.9G).

@Mistreated Moví la discusión sobre el nodo hetzner al # 3138. Este problema se trata de fallas temporales en el servidor de compilación, no de una configuración incorrecta del servidor de compilación.

Parece que la creación de imágenes de Docker no funciona en hetzner-jenkins1 :

stderr: error: could not lock config file .git/config: Disk quota exceeded

. Inhabilité el nodo.

Es solo Disk quota exceeded , no quería saturarlo con memoria. Lo limpié ahora. Está arriba de nuevo.

Dos pruebas más que a veces fallan (# 3168):

 27/134 MemCheck  #23: testcpp_contextual_thread ........***Exception: Other  2.59 sec
Running main() from /opt/gtest/googletest/src/gtest_main.cc
[==========] Running 8 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 8 tests from test_contextual_thread
[ RUN      ] test_contextual_thread.instanciation

/home/jenkins/workspace/libelektra_PR-3168-L5JHIPUUQR3TWFGKHQIDK6HHW6QAMSQXWJC5ZUZMBLDMLTYA2ENA@2/src/bindings/cpp/tests/testcpp_contextual_thread.cpp:70: Failure

Expected equality of these values:
  ks.lookup ("user/hello").getString ()
    Which is: "8"
  "5"
terminate called without an active exception

60/254 Test  #57: testio_glib .................................***Failed    5.08 sec

BINDING TEST-SUITE

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

test basics
test idle
test timer
testTimerShouldCallbackOnce (warning): measured 316ms, expected 250ms - deviation 66ms.
testTimerShouldCallbackAtIntervals (warning): measured 343ms, expected 250ms - deviation 93ms.
testTimerShouldCallbackAtIntervals (warning): measured 322ms, expected 250ms - deviation 72ms.
testTimerShouldCallbackAtIntervals (warning): measured 338ms, expected 250ms - deviation 88ms.
../src/bindings/io/test/test_timer.c:273: error in testTimerShouldChangeInterval: timer was not called the required amount of times
test file descriptor
test mix

Otro error más en https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/12/pipeline/

Step 12/31 : RUN curl -o cppcms-${CPPCMS_VERSION}.tar.bz -L         "https://sourceforge.net/projects/cppcms/files/cppcms/${CPPCMS_VERSION}/cppcms-${CPPCMS_VERSION}.tar.bz2/download"     && tar -xjvf cppcms-${CPPCMS_VERSION}.tar.bz     && mkdir cppcms-${CPPCMS_VERSION}/build     && cd cppcms-${CPPCMS_VERSION}/build     && cmake ..     && make -j ${PARALLEL}     && make install     && cd /app/deps     && rm -Rf cppcms-${CPPCMS_VERSION}

 ---> Running in f5ed5e42a480

curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

The command '/bin/sh -c curl -o cppcms-${CPPCMS_VERSION}.tar.bz -L         "https://sourceforge.net/projects/cppcms/files/cppcms/${CPPCMS_VERSION}/cppcms-${CPPCMS_VERSION}.tar.bz2/download"     && tar -xjvf cppcms-${CPPCMS_VERSION}.tar.bz     && mkdir cppcms-${CPPCMS_VERSION}/build     && cd cppcms-${CPPCMS_VERSION}/build     && cmake ..     && make -j ${PARALLEL}     && make install     && cd /app/deps     && rm -Rf cppcms-${CPPCMS_VERSION}' returned a non-zero code: 92

script returned exit code 92

Me temo que https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin es el único gran paso adelante.

Desafortunadamente, no solucionará los problemas de Travis o Cirrus.

¿Actualizamos "Tiempos fallidos" en la publicación de inicio? check_external_example_codegen_econf está sucediendo con bastante frecuencia actualmente.

Intentar actualizar la publicación de inicio o intentar solucionar todos estos problemas es inútil. Necesitamos un reintento automático. Espero que @Mistreated implemente esto pronto en nuestro nuevo servidor.

¿Qué opinas sobre el # 3224?

Los problemas están resueltos ahora. Abra nuevos problemas si las compilaciones aún fallan.