Merci d'avoir collecté les numéros!

Pour les builds maven, nous avons déjà un problème: # 2855

Pour les builds maven, nous avons déjà un problème: # 2855

Je sais 😊. J'ai déjà ajouté un lien dans la description du problème.

Merci pour cette recherche élaborée. Nous devons maintenant résoudre un problème après l'autre.

Pour les problèmes Haskell, nous pouvons supprimer les liaisons / plugins haskell. Ils ne sont de toute façon pas maintenus.

Haskell sera supprimé dans # 3017

Les échecs avec docker pull échouent à l'étape du site Web se produisent assez souvent maintenant.

J'ai aussi des problèmes de connexion pour 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

Ceci est un journal complet.

Les échecs avec docker pull échouent à l'étape du site Web se produisent assez souvent maintenant.

S'agit-il de toutes les tentatives et de l'attente après Pulling from build-elektra-web-base ( log )?

De plus, je pense que cette erreur est nouvelle: test_service_convertengine échoue pendant Starting build/hub.libelektra.org/build-elektra-website-backend ( log 2 )

Oui, je suis d'accord que test_service_convertengine n'est pas encore signalé ici. En fait, nous pouvons désactiver le test car le service n'est de toute façon pas modifié.

@sanssecours existe-t-il une procédure pour ajouter de nouveaux tests dans la liste ci-dessus?

@sanssecours existe-t-il une procédure pour ajouter de nouveaux tests dans la liste ci-dessus?

Nan. J'ai déjà renoncé à modifier la liste, car la construction de Jenkins échoue trop souvent. Je recommanderais d'ouvrir simplement un numéro pour chaque problème spécifique.

Pour les problèmes liés au code source, je suis d'accord. Pour les problèmes liés à l'instabilité de docker / jenkins, il suffit de collecter les problèmes ici car ce que nous pouvons faire à côté de la migration que nous faisons déjà est très limité, mais prend malheureusement plus de temps que prévu. Ce serait bien si @Mistreated pouvait donner plus d'informations sur le statut, peut-être au # 160.

De plus, je pense que cette erreur est nouvelle: test_service_convertengine échoue lors du démarrage de build / hub.libelektra.org / build-elektra-website-backend (log 2)

Pouvez-vous le signaler séparément? Le correctif consiste à désactiver les tests.

Pouvez-vous le signaler séparément?

Terminé, voir # 3086

Je pense que notre meilleure hypothèse pour nous faciliter la vie est de "résoudre" ces problèmes en utilisant https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin

Ensuite, Jenkins redémarrera plusieurs fois les travaux ayant échoué. Je pense que nous pourrions essayer 5 redémarrages avant d'abandonner?

@Mistreated Pouvez-vous implémenter cela également sur l'ancien serveur? Ou est-ce trop risqué?

Avant d'implémenter cela, cependant, nous avons besoin du nouveau nœud Jenkins, sinon la file d'attente deviendra trop longue.

Après un peu de mal, j'ai réussi à ajouter un nouveau nœud Jenkins.

Avant d'implémenter cela, cependant, nous avons besoin du nouveau nœud Jenkins, sinon la file d'attente deviendra trop longue.

L'ancien serveur est surchargé à mon avis, mais on peut essayer je suppose ..

Après un peu de mal, j'ai réussi à ajouter un nouveau nœud Jenkins.

Merci d'avoir ajouté le nouveau nœud Jenkins. J'ai désactivé le nœud pour le moment, car il semble casser la construction .

J'ai mis à jour le nœud. Cela devrait fonctionner maintenant. Si quelque chose ne va pas, vous pouvez me mettre à jour ici à nouveau.

Si quelque chose ne va pas, vous pouvez me mettre à jour ici à nouveau.

On dirait que docker pull échoue sur hetzner-jenkins1 , car le nœud n'a pas assez d'espace libre:

Impossible de contacter hetzner-jenkins1: hudson.remoting.RequestAbortedException: java.io.IOException: arrêt inattendu du canal
échec de l'enregistrement de la couche: statut de sortie ApplyLayer 1 stdout: stderr: write / usr / lib / git-core / git-credential-store: quota de disque dépassé

.

On dirait que l'extraction de docker échoue sur hetzner-jenkins1, car le nœud n'a pas assez d'espace libre:

Nœud mis à jour.

Les tâches de création sur hetzner-jenkins1 semblent échouer , en raison de problèmes liés aux autorisations:

Ressource: impossible de créer le répertoire «/.config». Raison: autorisation refusée. Identité: uid: 47000, euid: 47000, gid: 47000, egid: 47000

.

J'ai mis à jour le nœud, encore une fois, il ne devrait plus y avoir de problèmes d'autorisation.

Pourquoi Jenkins veut-il construire un répertoire '/.config' et pas seulement '.config'?
Il y a un répertoire .config dans '/ home / jenkins /' mais il veut créer un dossier .config dans '/'.

Je ne pense pas que l'utilisateur «jenkins» devrait pouvoir le faire.

@Mistreated, veuillez également faire un PR pour tester si les versions fonctionnent maintenant.

Pourquoi Jenkins veut-il construire un répertoire '/.config' et pas seulement '.config'?
Il y a un répertoire .config dans '/ home / jenkins /' mais il veut créer un dossier .config dans '/'.

Cela peut se produire si le répertoire personnel de l'utilisateur est /. Avez-vous regardé dans / etc / passwd, peut-être que quelque chose ne va pas?

Cela peut se produire si le répertoire personnel de l'utilisateur est /. Avez-vous regardé dans / etc / passwd, peut-être que quelque chose ne va pas?

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

Tout semble bien, même dans les journaux du nœud:

'HOME =' / home / jenkins ''
'REMARQUE: le chemin distant relatif a été résolu en: / home / jenkins /.'

Il serait plus facile de déboguer pour voir un PR avec tout le journal.

Le nœud maître est en panne.

Il serait plus facile de déboguer pour voir un PR avec tout le journal.

3134

Le nœud maître est en panne.

Merci pour l'information. J'ai supprimé toutes les informations du journal pour les anciennes demandes d'extraction et réactivé le nœud. Malheureusement, la quantité d'espace libre sur le maître Jenkins est encore très faible (~ 3,9G).

@Mistreated J'ai déplacé la discussion sur le nœud hetzner vers # 3138. Ce problème concerne des échecs temporaires du serveur de build, pas une mauvaise configuration du serveur de build.

Il semble que la création d'images Docker ne fonctionne pas sur hetzner-jenkins1 :

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

. J'ai désactivé le nœud.

C'est juste Disk quota exceeded , je ne voulais pas le surcharger de mémoire. Je l'ai nettoyé maintenant. C'est à nouveau.

Deux autres tests qui échouent parfois (# 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

Encore une autre erreur dans 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

J'ai peur que https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin soit le seul grand pas en avant.

Malheureusement, cela ne résoudra pas les problèmes de Travis ou de Cirrus.

Avons-nous mis à jour "Times failed" dans le post de démarrage? check_external_example_codegen_econf se produit assez souvent actuellement.

Essayer de mettre à jour le post de démarrage ou essayer de résoudre tous ces problèmes est sans espoir. Nous avons besoin d'une nouvelle tentative automatique. J'espère que @Mistreated l'implémentera bientôt sur notre nouveau serveur.

Que pensez-vous du # 3224?

Les problèmes sont résolus maintenant. Veuillez ouvrir de nouveaux problèmes si les versions échouent toujours.