Libelektra: Construire des trucs de serveur

@markus2330

Je viens de pousser quelques correctifs liés au système de construction. Mais vous devez également corriger certains paquets sur votre machine stable debian :

• Veuillez installer qtdeclarative5-dev à partir de wheezy-backports (vous pouvez supprimer /opt/Qt5.3.0 par la suite)
• Veuillez installer java8 en tant que package :
  
  
  
  • Utilisez cette méthode : http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • Laissez cmake trouver 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 + redémarrer le processus java local de jenkins. Sinon, tous les builds échoueront
  
  
  • Facultatif : Supprimer jdk7
  
  

Ça a l'air bien, merci d'avoir résolu ces problèmes.

J'ai également effectué ces étapes sur l'agent debian-stable.

Pour les autres machines, l'installation de qtdeclarative5-dev n'était pas possible, car cela entre en conflit avec qdbus qui est requis par kde4. J'ai donc restauré le script précédent configure-debian-wheezy en tant que configure-debian-wheezy-local.

J'ai également ajouté les étapes d'installation que vous avez mentionnées sous forme de notes dans le fichier README.md car elles pourraient intéresser d'autres personnes.

Merci d'avoir amélioré les agents !

Des trucs qui manquent sur stable

1.) latex (+ je pense que texlive-latex-recommandé est également nécessaire)
voir 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.) Pouvez-vous installer clang (pour elektra-clang, clang of wheezy ne fonctionnera pas) ?
3.) Pouvez-vous installer mingw+wine pour elektra-gcc-configure-mingw ?

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

Pourquoi avez-vous besoin de vin ?

Au fait, vous devriez changer i586-mingw32msvc-X en i686-w64-mingw32-X dans Toolchain-mingw32.cmake . Pour le moment, cela ne fonctionnera pas sur instable.

Merci pour le document !

wine est nécessaire pour exécuter les binaires Windows compilés de manière croisée (par exemple, exporterrors.exe)

Je pense que vous avez installé le mingw qui construit pour w64. Dans le package mingw32, il y a toujours un /usr/bin/i586-mingw32msvc-c++ .

Un nouveau fichier toolchain pour w64 est néanmoins apprécié.

J'ai installé gcc-mingw-w64-i686 qui est la version x64 de mingw avec i686 comme cible.
Le package mingw32-binutils est obsolète et n'est plus disponible sur unstable.

Vin installé sur les deux conteneurs.

En fait, la version mingw est liée à stable, donc cela ne devrait pas être un problème.

MinGW-w64 est un fork sur mingw et est une cible assez différente. Personne ne l'a testé jusqu'à présent.

merci d'avoir installé wine

Mingw-w64 semble supérieur. Il est peut-être temps de passer à autre chose :-)

Contributions bienvenues ;) Je n'ai aucune machine pour le tester.

Je crains que vous ne vous soyez trompé de vin, cela devrait être apt-get install wine32

voir aussi http://build.libelektra.org :8080/job/elektra-gcc-configure-mingw/218/console

Nan.

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

ok, dpkg --add-architecture i386 résoudra cela. Mais ne pouvez-vous pas simplement épingler le travail mingw/wine sur votre machine de construction ? La configuration mingw est assez spéciale.

Edit: je vais voir si je peux obtenir une version elektra avec mingw-w64 afin que je n'aie pas besoin d'installer des tonnes de bibliothèques i686.

Le problème est que je n'ai pas de machine jessie de rechange et que Mingw de Wheezy ne connaît pas C++11.

J'ai réussi à faire fonctionner mingw-w64. Cependant std::mutex n'est pas disponible car il n'y a pas de glibc sur windows et std::mutex dépend de pthreads. Des idées?

Ouah merci!

Cela conduit-il à une erreur de compilation ? Le std::mutex n'est pas utilisé pour l'interne
fonctionnalité, mais uniquement dans un fichier d'en-tête à inclure par un utilisateur. C'est utilisé
dans les cas de test cependant.

Une solution aux problèmes de compilation est de fournir un std::mutex dans le mingw
cas lançant des erreurs système à chaque tentative de verrouillage/déverrouillage. En fait, je voudrais
attendez-vous à ce que les gens mingw fournissent au moins quelque chose comme ça (par exemple quand
une macro est définie, similaire à -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads pourrait être un autre moyen. Mais c'est
très probablement utile uniquement si tous les cas de test sauf ceux impliquant std::mutex
déjà courir.

Fondamentalement, il ne s'agit que d'une instance de C++11 qui n'est pas correctement disponible.

statut mingw en ce moment :

• ajouté dlfcn-win32 en tant que projet externe à libloader. de cette façon, cmake extrait + compile la bibliothèque en tant qu'étape de construction supplémentaire. Je lie l'archive pour éviter des dll supplémentaires.
• ajout de la dépendance winsock2.h/ws2_32.dll à cpp11_benchmark_thread. requis par gethostname()-call

En ce moment, je construis avec -static-libgcc + -static-libstdc++ . Sinon, wine est incapable de trouver les dll. Le mutex supplémentaire ne compile pas non plus. J'ai essayé mingw-std-threads. j'ai juste plus d'erreurs de compilation :-)

Si je passe de x86_64-w64-mingw32-X à x86_64-w64-mingw32-X-posix std::mutex se compile bien, car pthread stuff est défini. Cependant, j'obtiens une dépendance supplémentaire à libwinpthread-1.dll, que wine est incapable de trouver.

Je pense que notre meilleur pari est d'utiliser x86_64-w64-mingw32-X-posix .

Encore une fois, je suis surpris que vous ayez même ce problème. Jusqu'à présent, nous étions heureux d'avoir un fichier libelektra.dll.

Je ne peux rien dire sur cette décision x86_64-w64-mingw32-X-posix , car je ne l'utilise pas et je n'en connais pas les implications. Je me demande si une telle posix-lib existe même, je pensais que l'approche posix-layer était cygwin et non mingw.

Cette décision a-t-elle même un effet sur libelektra.dll ? Si ce n'est que pour les cas de test, personne ne s'en souciera (tant que le serveur de build est capable de l'exécuter). Si les cas de test s'exécutent, ce sera un énorme avantage. (Voir #270 où les tests unitaires ont dévoilé quelques bugs étranges sur Mac OS X)

Il semble que libwinpthread-1.dll puissent être téléchargés, mais je ne sais pas s'ils fonctionnent avec wine ? Pouvez-vous également l'ajouter en tant que projet externe comme avec dlfcn-win32 (afin que toutes les dll soient gérées de la même manière) ? Sinon, si vous avez besoin de télécharger 1 ou 3 dll pour les tests, cela n'a pas vraiment d'importance (encore une fois, je ne suis pas un utilisateur, et je ne comprends pas le concept de déploiement, s'il y en a, des dll windows).

@beku Qu'en pensez-vous ? Avez-vous le temps de tester notre dernière version 0.8.13 mingw-w64 sur Windows avec oyranos ?

Les tests sont-ils généralement activés pour la tâche de génération mingw ? Hier, ils étaient tous handicapés.

Oui, ils étaient handicapés. Mais si j'ai bien compris, les exemples/références comme cpp11_benchmark_thread ont également été désactivés. J'ai donc pensé que vous l'aviez modifié et compiliez plus qu'avant.

J'ai compilé l'intégralité du référentiel avec C++11 activé. Rien de plus.

Mais les exécutables comme bin/basename.exe construits avec -posix fonctionnent bien tant que vous copiez les dll requises dans le répertoire bin (merci windows de ne pas avoir RPATH). Je n'ai pas trouvé de moyen pour a) laisser cmake trouver le répertoire dll + b) pointer wine vers le répertoire dll.
Je pensais que la liaison statique fonctionnerait, mais la construction échoue avec des symboles en double lors de la liaison de la dll elektra. Parce que la dll a déjà les symboles inclus.

@ markus2330 J'ai réussi à faire compiler elektra avec mingw + fonctionnant avec wine sans copier de dll. L'astuce consiste à toujours activer la liaison statique pour les deux exécutables ET les objets partagés ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ").

Pour contourner les symboles dupliqués, j'ai ajouté des scripts de version pour libelektra et libelektratools. De cette façon, seuls nos symboles sont exportés.

Cela fonctionne vraiment bien. par exemple

$ 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

Même bin/cpp11_benchmark_thread.exe fonctionne.

D'autres choses ne font que planter :

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

Pour le moment, j'ai simplement ajouté le script de version sans penser aux autres compilateurs. Dois-je continuer mon travail ou pas intéressé ?

plante dans src/plugins/wresolver/wresolver.c car pk->filename est NULL

pk est de type resolverHandles.user

J'ai essayé de jeter un œil au plugin mais je ne comprends pas la boucle for dans elektraWresolverOpen . La boucle appelle elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System} qui tous malloc resolverHandle->filename et donc une fuite de mémoire.

Merci d'avoir fait remarquer cela! Le code est visiblement cassé depuis l'introduction dans c87ae8e87a716b02b2c7ed790ad56a89d95547a9
Pendant le bouclage uniquement et toujours, le handle du système a été initialisé. Cela entraînait des plantages lorsqu'un autre espace de noms était utilisé.

je l'ai corrigé dans
edb4d50856bb5331749220de5a83fa2062624a9d

À propos de la poursuite du travail : d'une part, ce serait bien si les éléments compilés fonctionnent également. D'un autre côté, la sortie devrait avoir lieu ce week-end, donc une demande d'extraction serait bientôt importante (il devrait y avoir au moins une chance d'un court cercle de commentaires, par exemple ce que font réellement les scripts de version)

Mais à mon humble avis, cela suffit si une seule variante (la compilation statique) fonctionne. Super de voir l'outil kdb fonctionner !

Où puis-je trouver edb4d50856bb5331749220de5a83fa2062624a9d ?

edb4d50856bb5331749220de5a83fa2062624a9d a été poussé un peu plus tard.

Quelles versions de gcc sont installées sur debian-unstable-mm ?

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

dit qu'il n'y a pas de gcc-5.2

Pouvez-vous installer autant de compilateurs que possible, s'il vous plaît ?

Dans un certain numéro ou PR, j'ai dit que j'avais supprimé tous les compilateurs sauf le dernier.
Edit : gcc 4.9 sur stable, 4.9 + 5.x (par défaut) sur unstable

Veuillez faire ce genre de tests (je les trouve très inutiles de toute façon) sur vos propres conteneurs. Le mien ne restera pas éternellement de toute façon.

Je n'ai pas lu cela. Ils ont peut-être 50 Mo chacun. Pourriez-vous les réinstaller et répondre à la première question ?

Peut-être que je vous l'ai dit lors de notre réunion. Mais je te l'ai certainement dit.

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

Le binaire spécifique à la version est appelé gcc-5. Plus de package séparé pour les versions mineures. Donc, votre multiconfig-gcc avec ce niveau de détail est en quelque sorte obsolète. Je recommande de supprimer gcc 4.7 et de remplacer gcc-5.2 par gcc-5 et que ce soit fait.

Le seul compilateur supplémentaire disponible que je n'ai pas installé est gcc-4.8. Et gcc-4.8 a déjà été marqué pour suppression.

Merci pour l'info! On dirait que les jours de gloire de nombreux compilateurs disponibles sont révolus.

J'ai corrigé multiconfig-unstable.

Je vais fermer pour le moment, merci pour l'excellente configuration de l'agent.

Bonjour, jessie (stable) a besoin de quelques paquets supplémentaires. Pourriez-vous s'il vous plaît installer:

• [ ] fausse racine
• [ ] gpg (+ créer une clé pour Autobuilder [email protected])
• [ ] reprepro (peut-être déjà installé, le script n'est pas allé si loin)

fakeroot installé, gpg + repropro est déjà installé.
Pouvez-vous m'envoyer votre clé gpg déjà existante? Donc, les deux machines de construction ont le même

C'est ok d'avoir différentes clés gpg. Je ne sais pas si la configuration actuelle les utilise, alors attendez d'abord si http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/ échoue.

• debhelper + libsystemd-journal-dev installés
• python-dev est une mauvaise dépendance. il devrait être python2.7-dev ou python3-dev ou les deux
• pourquoi avons-nous besoin de python-support?

Merci pour l'installation !

python-dev est disponible pour Jessie et python-support . Veuillez les installer.

Je l'ai testé localement, lorsque ces packages sont installés, il est construit pour jessie.

Bien sûr, c'est disponible mais c'est une mauvaise dépendance. python-dev dépend de python2.7-dev qui n'est _pas_ suffisant. Au lieu de cela, python2.7-dev + python3-dev est requis.

python-support n'est pas du tout requis à mon humble avis.

Je ne sais pas pourquoi les dépendances ont été choisies de cette façon, la plupart du packaging a été fait par @iandonnelly pendant gsoc.

Oui, les packages doivent également être mis à jour pour créer des liaisons python3. Actuellement, ce n'est tout simplement pas fait. Néanmoins, vous pouvez installer python3-dev, afin que la construction ne se brise pas (lorsque les liaisons python3 + les plugins sont ajoutés au paquet debian).

Cela ne veut pas dire qu'ils sont corrects :-) - Je suis assez sûr des deps python-dev.
Pouvez-vous s'il vous plaît les remplacer et supprimer le dep python-support ?

python3-dev et python2.7-dev sont déjà installés. Sinon, aucune liaison ne serait construite.

D'ailleurs. le paquet debian officiel de @pinotree ne construit que python3. Ce serait une perte de temps de réparer ce qu'il y a dans notre branche "debian", le travail de @pinotree est de toute façon supérieur.

Quand je trouverai le temps, je mettrai à jour notre branche "debian" avec ce que

Je n'ai jamais dit que je supprimerais les packages python2. Tout ce que je dis, c'est que python-dev est une dépendance inexacte. Nous avons besoin de versions explicites. Donc, pythonX-dev est le bon dep à utiliser.

Espérons que pinotree a correctement déterminé la dépendance.

Au fait, le guépard est mort. Ne l'utilisez pas.

Ok, je l'ai remplacé. Veuillez rétablir b7c266b36b0ab0fad9120e67a457b580c7c44690 et installer python-support si cela est nécessaire après tout.

Je suis sûr que pinotree l'a fait correctement ;)

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

installée

python-dev est une mauvaise dépendance. il devrait être python2.7-dev ou python3-dev ou les deux

• python-dev installe le package de développement pour la version par défaut de Python 2 ; depuis Wheezy, c'est Python 2.7
• python3-dev installe le package de développement pour la version par défaut de Python 3 ; Python 3.2 dans Wheezy, 3.4 dans Jessie et jusqu'à présent toujours 3.4 dans Stretch (je suppose que ce sera bientôt 3.5)

Donc, si vous voulez compiler avec la version par défaut de Python 2/3, utilisez respectivement python-dev / python3-dev , pas les versions pythonX.Y-dev (que vous devez utiliser lorsque vous voulez qu'une version précise de Python soit installée, même si ce n'est pas la seule installée sur le système, et pas celle par défaut). L'utilisation de l'un ou l'autre est ce que je recommande.

à partir de python-dev description :
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

Selon ce texte, python-dev peut sûrement dépendre de python3 dans un avenir proche

De plus : il n'y aura jamais d'autre version de python2. Ainsi, python2.7-dev sera le dernier package de développement python2 de tous les temps.

En fonction de python3-dev, c'est ce que j'ai dit.

Il ne manque plus que la clé :

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

terminé

Merci!

Veuillez exporter /home/jenkins/repository via http.

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

→ http://194.117.254.29/elektra-stable/

@manuelm Pourriez-vous s'il vous plaît installer ronn sur les agents ? (nécessaire pour générer des pages de manuel)

apt-get install ruby-ronn

terminé

Merci, les packages jessie sont recréés et les pages de manuel sont maintenant incluses !

Veuillez installer musl, c'est-à-dire

apt-get install musl musl-dev musl-tools

Merci!

musl installé et agents mis à niveau

Deux choses importantes à propos du serveur de build :

1. Ne créez pas de nouveaux jobs vides, mais dupliquez plutôt, ils ont des paramètres corrects (sauf ce qui est mentionné au numéro 2.).
2. Nous devrions utiliser des clones de référence (dans /home/jenkins/libelektra) ou préférer des clones superficiels pour chaque tâche de construction (actuellement fait seulement pour certains, par exemple elektra-clang). Actuellement, le trafic est supérieur à 300 Mo sur les commits en raison des nombreux reclonages inutiles.

@mpranj Ce serait bien si vous pouviez réparer 2.

@markus2330 juste pour m'assurer : je devrais juste appliquer le même comportement de clonage à toutes les tâches de build comme c'est le cas dans elektra-clang ?

Clones peu profonds appliqués à tous les build-jobs sauf :

• [ ] elektra-git-buildpackage-jessie
• [ ] elektra-git-buildpackage-wheezy
• [ ] elektra-multiconfig-gcc-stable
• [ ] elektra-multiconfig-gcc-instable
• [ ] elektra-source-paquet-test

Ces travaux sont extraits d'un sous-répertoire. Je n'étais pas sûr de ce que vous vouliez là-bas, alors je vais les laisser tels quels pour le moment.

Merci! Oui, ils ont besoin d'un historique complet et de branches, les clones superficiels n'ont aucun sens, mais le référentiel de clones de référence serait utile.

Jenkins a été mis à jour vers la 1.651.2. De plus, tous les plugins ont été mis à jour.

Je garderai le problème ouvert pour les dépôts de clone de référence. Nous devrions également avoir des "tâches cron" qui mettent à jour les dépôts de temps en temps, idéalement en utilisant jenkins lui-même.

Jenkins a cessé de créer des travaux (depuis la mise à jour apparemment). Il échoue avec
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Merci pour l'info. J'essaie de rétrograder le générateur de requêtes github de 1.31 à 1.14.

Maintenant, il semble bloqué lors de la définition du statut de build pour le commit Github. Il avertit que cela est obsolète dans le fichier config.

J'ai également essayé de rétrograder chaque plugin avec *git* dans son nom, mais il y avait encore des erreurs (erreur étrange liée au plugin Mailer, la rétrogradation du plugin Mailer n'a pas aidé). J'ai donc tout mis à jour vers les versions récentes. Le problème semble être un problème connu en amont :

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

J'espère qu'ils vont le réparer bientôt.

Autre question : est-ce que quelqu'un sait comment exécuter plusieurs tâches pour chaque RP ? (Je voudrais exécuter à la fois elektra-mergerequests-stable et elektra-mergerequests-unstable)

Le travail elektra-test-bindings fonctionne correctement avec les builds paramétrés (comme également décrit dans le ticket en amont). Ne pourrions-nous pas simplement le basculer vers des versions paramétrées ? Le bug est signalé en amont depuis un moment, je ne le vois pas corrigé de sitôt.

Bonne idée, nous pourrions changer tous les travaux de relations publiques en builds paramétrés, cela n'a en fait que des avantages. Cela nous permet également d'exécuter les tâches manuellement en spécifiant une branche. Et il peut également être utilisé pour des travaux de construction réguliers.

Idéalement, chaque tâche pourrait également être exécutée par les PR github. (Sauf celles spécifiquement pour les tâches non liées aux relations publiques qui mettent à jour le docu ou la couverture de la branche principale)

Un inconvénient de la configuration d'elektra-test-bindings est qu'elle ne fait que des interrogations et prend assez de temps jusqu'à ce qu'elle commence à se construire (jusqu'à 5 min). Je ne veux pas activer "Utiliser les hooks github pour le déclenchement de la construction", cependant, pour ne pas interrompre le travail de construction.

D'ailleurs. êtes-vous sûr que l'option « clonage superficiel » convient aux travaux de génération de requêtes de tirage github ?

Je me demande comment github choisit le travail de build qu'il utilise pour les nouveaux PR. Pourquoi les elektra-test-bindings et elektra-ini-mergerequests ne sont-ils jamais sélectionnés pour un nouveau PR ? Pourquoi est-ce parfois elektra-mergerequests-unstable et parfois elektra-mergerequests(-stable) ?

@manuelm avez-vous une idée?

D'ailleurs. d'une manière ou d'une autre, la communication des tâches de construction terminées et de github est gravement altérée (même pour les liaisons elektra-test). Il est maintenant indiqué sur presque toutes les versions "Certaines vérifications ne sont pas encore terminées".

Un inconvénient de la configuration d'elektra-test-bindings est qu'elle ne fait que des interrogations et prend assez de temps jusqu'à ce qu'elle commence à se construire (jusqu'à 5 min).

Et c'est un problème parce que? Le test prend de toute façon plus de 5 minutes.

Pourquoi les elektra-test-bindings et elektra-ini-mergerequests ne sont-ils jamais sélectionnés pour un nouveau PR ?

Pourquoi devrait-il? elektra-test-bindings est déclenché par la "phrase de déclenchement" uniquement. Aucune idée de ce qu'est elektra-ini-mergerequests .

Pourquoi est-ce parfois elektra-mergerequests-unstable et parfois elektra-mergerequests-stable ?

Les -stable/-unstable sont-ils nouveaux ? Je ne suis pas sûr qu'il soit possible de déclencher plusieurs travaux par nouveau PR. Je ferais des sous-jobs.

Au fait, je l'ai déjà dit plusieurs fois, mais je pense que le nombre de travaux devient ridicule et le signe d'une configuration foirée. Mais critiquer est toujours plus facile que de résoudre quelque chose.

Les 5 min sont un problème lorsque vous souhaitez déboguer le serveur de build. Et j'espère toujours que nous aurons un premier test rapide, prenant environ 5 minutes.

Ahh, ok, j'ai raté l'option "Utiliser uniquement la phrase de déclenchement pour le déclenchement de la construction". La configuration du générateur de requêtes github est vraiment un gâchis.

Quelqu'un a parlé de projets github où plusieurs tâches s'exécutent pour chaque PR. (Affiché individuellement)

Qu'est-ce qu'un sous-emploi ? Tu veux dire multijob ?

Quelqu'un a parlé de projets github où plusieurs tâches s'exécutent pour chaque PR. (Affiché individuellement)

Vous devrez ajouter deux services sur github.

Qu'est-ce qu'un sous-emploi ? Tu veux dire multijob ?

Ouais multijob.

d'ailleurs, qu'en est-il de https://docs.travis-ci.com/ ? Travis prend en charge OSX.

Je sais que cela ne remplacera pas jenkins mais pourrait remplacer le PR/à chaque build de commit. Jenkins peut toujours faire les tests de plusieurs compilateurs/etc.
Edit : Travis a même gcc + clang.

D'accord, il serait intéressant d'utiliser leur puissance CPU/électricité gratuitement car elektra est open source.

Il est probable que la connexion entre github et jenkins soit en réalité de 1:1. Dans le service github, j'ai entré http://build.libelektra.org :8080/github-webhook/ et je n'ai pas trouvé le moyen de créer une autre URL dans jenkins. (J'ai seulement trouvé un moyen de spécifier un remplacement, mais cela n'a pas créé de nouvelle URL).

Dans https://github.com/janinko/ghprb/issues/142, ils discutent du fait que cela devrait « juste » ? (Sans ajouter plusieurs services)

Le problème de sha1, cependant, devrait être résolu maintenant. Il a été cassé parce que Jenkins a introduit une nouvelle mesure de sécurité qui élague les variables d'environnement inconnues. Je fixe comme suggéré (ajouté -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 vers /etc/default/jenkins).

À propos de l'utilisation de serveurs de build supplémentaires : Oui, allez-y. Cela résout également le problème des tâches de build multiples pour un seul PR ;) Je n'ai jamais utilisé travis-ci, donc je ne peux rien en dire. J'ai donné la permission à Travis d'avoir accès à ElektraInitiative.

Première version de travis : https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Je pense que nous avons besoin d'un fichier yaml pour que Travis sache quoi faire.

Et j'ai compris comment faire plusieurs tâches jenkins par PR, un contexte différent pour chaque tâche de construction était nécessaire. Lors de la prochaine réunion, nous discutons de ce que devraient faire les tâches "rapides" et les autres tâches de construction.

Je travaille sur Travis (ou je vérifie certaines choses)

S'amuser. Travis a également ajouté un service github, donc je suppose qu'un PR sera également construit avec travis.

je jure déjà fort

-- Impossible de trouver JNI (manquant : JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
-- Exclure le plugin jni car jni introuvable

Je n'arrive pas à configurer correctement le plugin Java. Cependant, les liaisons Java fonctionnent. Sur debian instable. Des idées? Regarder le module cmake n'aide pas beaucoup.

Edit : /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h et /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h est en place

Edit 2 : Compris. JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

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

Debian instable construit dans un conteneur Docker. Mais la construction prend une éternité.
De bonnes idées ?

clang est souvent plus rapide en ce qui concerne le temps de construction, mais je pense que l'installation des dépendances est ce qui prend beaucoup de temps

N'y a-t-il pas une image de docker debian plus minimale que celle utilisée ? Il semble que de nombreux packages soient installés qui ne devraient pas être nécessaires.

@sirblackheart Qu'est-ce qui te fait penser ça ? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm probablement la mise à niveau dist. de nombreux packages sont mis à jour et sont spécifiques au bureau, comme wayland

La mise à niveau de la dist est courte. peut-être une minute. environ 50% du temps est pris par l'installation des deps de construction.

Je pousse l'image de construction sur hub.docker.com en ce moment. J'espère que ça va accélérer les choses. Mais l'image a 1,9 Go

Temps écoulé 14 min 8 sec

Je ne sais pas si nous pouvons faire beaucoup mieux

comme je l'ai dit, clang nous donne peut-être 2-3 minutes. du moins c'est le cas pour le projet aseprite
https://travis-ci.org/aseprite/aseprite

Il serait utile d'avoir les deux compilateurs de toute façon.

Je viens d'avoir une idée en préparant des éléments de travail : et si nous extrayions les chemins de tous les commits dans la requête push et ne construisions des liaisons/plugins que s'ils étaient affectés ? par exemple

• le changement dans cmake/* déclenche tout (plugins + bindings)
• le changement dans src/bindings/foo déclenche la liaison foo
• le changement dans src/plugins/foo déclenche le plugin foo
• tout changer ne compile pas de plugins + liaisons

Nous avons toujours la version complète quotidienne/deux fois par jour de jenkins.

@manuelm bonne idée, @tom-wa écrirait un tel script, pouvez-vous créer un nouveau problème pour cela ?

@mpranj : Rappel : ajoutez les builds Mac OS X à travis et ajoutez les builds mingw à PR. (*BSD semble demander plus d'efforts)

@markus2330 maintenant je comprends l'approche docker de @manuelm , travis ne prendra pas en charge ubuntu 16.04 avant l'année prochaine, donc docker est nécessaire pour obtenir toutes les dépendances qu'ubuntu 14.04 n'a pas = swig3.0 libsystemd-devel.

Je suis désolé de ne pas avoir pu assister à la réunion d'aujourd'hui. Au travail, nous préparons toujours un grand déploiement de logiciel aujourd'hui, je ne peux donc pas quitter le bureau. Mais dans un court délai, je peux répondre aux e-mails.

J'ai commencé à ajouter des versions OS X pour travis il y a 2 jours : https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
La construction est ici : https://travis-ci.org/manuelm/libelektra/builds/130898079
Ouvrez les choses ici :

• [ ] cryto_openssl ne parvient pas à compiler
• Les tests de liaisons [ ] échouent
• [ ] pas de Java

Je suis heureux si quelqu'un assumera mon travail à partir d'ici. Je n'ai pas OS X et attendre que Travis inspecte le système OSX résume très rapidement.

re: docker: Oui, la version ubuntu par défaut de travis ne fonctionne pas bien. Même cmake est trop vieux.
La récupération de l'image docker téléchargée ne prend que 3 minutes environ. Et ajouter plus d'images est une évidence. Je pense donc que c'est un bon moyen de contourner tous les pièges que l'environnement linux travis par défaut a (ou pourrait avoir après une mise à jour).

Je n'ai pas trouvé de bon moyen d'intégrer les différentes phases de build et de test de libelektra (cmake + make + make test) avec docker (build + run) + travis (before_install, before_script, script). Les conteneurs Docker se ferment une fois la commande terminée. Étant donné que les conteneurs docker sont destinés à être jetés, vous ne pouvez pas reprendre par la suite. Ainsi, l'état de votre disque/compilation a disparu, à moins que vous ne montiez un répertoire local dans le conteneur. Continuera à travailler sur docker la semaine prochaine.

@manuelm Super, vous êtes @mpranj a dit qu'il prendrait votre travail. Vous souhaitez créer un PR avec le fichier travis ?

Non, car le fichier travis doit encore être modifié par la suite. Sinon, il ne construira que OS X. Je préférerais que @mpranj prenne mon fichier

PS : veuillez faire des tests de travis dans un dépôt avec espacement des noms d'utilisateur. Vous ferez beaucoup de poussées :-)

mingw64 s'appuie sur PR ajouté, devrait fonctionner. Désolé pour le retard. Je vais me renseigner sur Travis aujourd'hui !

Y a-t-il un inconvénient à activer le déclenchement des tâches de build avec une phrase dans un PR (avec le générateur de PR Github) ?

J'aimerais configurer les travaux de #745 afin de pouvoir tester si je l'ai corrigé, mais je peux l'appliquer à la plupart/(tous) les travaux de construction.

EDIT : Je préfère ne pas démarrer automatiquement tous les travaux, nous en avons déjà quelques-uns.

Je pense que c'est une bonne idée si nous pouvons configurer chaque travail pour qu'il soit déclenché avec une phrase. Je pense qu'il y a un petit inconvénient (au moins pour elektra-test-bindings): vous devez entrer pour quelle branche vous voulez construire et vous ne pouvez pas simplement appuyer sur "construire le travail maintenant". Ce serait génial si vous trouviez une solution pour cela.

Et vous avez raison, nous devrions plutôt réduire les travaux automatiques.

Il existe en fait une solution très simple. Nous utilisons la variable (env) sha1 pour créer des PR. Les builds paramétrés vous demandent la valeur, qu'une valeur par défaut soit définie ou non.

Solution : définissez la variable d'environnement sha1 sur master (dans la configuration de jenkins elle-même) et désactivez les versions paramétrées. S'il n'y a pas d'objection à la définition de la variable, cela résoudrait exactement ce que vous avez mentionné ci-dessus @ markus2330.

Je l'ai déjà défini, vous pouvez donc appuyer sur ce bouton de construction sur par exemple elektra-mergerequests et il commencera à construire le maître.

Oui, c'est une très bonne solution, j'aime ça. Cela nous permettrait également de créer une branche de publication avec un seul commutateur (si nous en avons besoin à l'avenir). Jusque-là, "master" est toujours le bon choix s'il n'est pas exécuté à partir d'un PR.

Je pense que cela résoudrait également le problème de la variable d'environnement filtrée, que nous avions précédemment.

Ensuite, nous pouvons également penser à réduire les build-jobs (pas de duplication pour les jobs bulid -mergerequest) et un nouveau schéma de nommage cohérent. (Des suggestions peuvent être faites ici.) Il pourrait y avoir un problème ouvert : actuellement, nous construisons une couverture, un docu, .. pour les PR et le maître et les copions dans des endroits séparés. Si nous fusionnons les tâches de build, nous avons besoin d'un moyen de distinguer les tâches maître/PR pour copier la couverture, la documentation à différents endroits.

J'ai presque fini d'appliquer cela à tous les travaux (mais le serveur _just_ est devenu vraiment lent).
Ne s'appliquait pas aux emplois qui génèrent des caractères génériques ** (doc et quelques autres, mais très peu)

Vous pouvez toujours arrêter les tâches de build lorsque vous souhaitez travailler dessus si vous les redémarrez plus tard (sauf au moment de la publication). Habituellement, jenkins lui-même est la raison du ralentissement de la machine. Pour le moment, un rsync à partir d'une sauvegarde peut être le problème, mais c'est urgent.

Ouais pas de problème du tout, ça devrait être fait mais je vais faire quelques dernières vérifications.

L'actualité @ElektraInitiative/elektradevelopers :

• comme mentionné, presque _tout_ peut être construit maintenant à partir des PR et/ou en appuyant uniquement sur le bouton de construction
• les phrases de déclenchement sont toujours le nom du travail sans le préfixe elektra- . (par exemple elektra-clang: jenkins build clang s'il vous plaît) Je n'ai pas changé jenkins build please et d'autres anciennes phrases pour des raisons héritées
• le message d'état de build github est toujours exactement le nom de la tâche de build

Merci, bravo ! Veuillez mettre à jour doc/GIT.md afin que tout le monde sache quelles phrases fonctionnent maintenant.

(J'espère que le @mention fonctionne que pour un seul message et que tout le monde ne lit pas tous les messages que nous écrivons ici)

La version de Mac OS X pour xcode 6.1 semble être cassée :
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

J'ai déclenché une reconstruction pour celui-là, mais cela me semble être un échec temporaire de Travis.

Pouvez-vous documenter comment relancer une build pour un PR ? Je ne savais pas que c'était possible.

Directement sur travis-ci.org, en utilisant votre lien ci-dessus :

Je doute que ce soit digne d'un document, mais je peux néanmoins le faire.
La construction ne fonctionne toujours pas uniquement à cause de la commande git. Je ne pense pas que ce soit de notre faute.

Ah. Je pense que vous l'avez fusionné avant que la construction ne soit déclenchée/démarrée en premier lieu.
Lorsque je reconstruis d'autres PRs précédemment réussis, il est également cassé.

C'est plus un problème de Travis qu'autre chose.

D'accord, merci d'avoir étudié.

@manuelm debian-stable-mm semble être inaccessible (à la fois pour jenkins et pour moi du réseau TU). Pourriez-vous s'il vous plaît enquêter?

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..

On dirait que quelqu'un a arrêté le conteneur. Je l'ai recommencé.

d'ailleurs, à partir de demain matin, je serai loin de chez moi jusqu'au 1er août. Je suis toujours joignable par e-mail mais j'attends un petit délai.

Merci pour la solution rapide ! Je suppose donc que vous ne serez pas non plus ici pour les prochaines réunions.

Ouais

Certains travaux ont l'erreur :

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.

par exemple http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

Cela peut être causé par une mise à jour de jenkins ou par @KurtMi créant la branche kdb_import_man ?

Note à moi-même : cppcms doit être installé.

Désolé pour la branche, j'ai fait un PR directement sur la page github.

Est-il plus facile de créer des PR de cette façon ? Github ne propose-t-il pas de supprimer la branche après sa fusion ?

Le changement était si minime que je suis devenu paresseux. Pour de très petites corrections oui, mais apparemment la branche ne sera pas supprimée par la suite. Je n'ai vu aucune branche de suppression après la fusion.

Je pense que la version instable est cassée :

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

Journal complet

@KurtMi unstable fonctionne à nouveau (parmi la plupart des builds), mais l'erreur Walk persiste sur certaines des tâches de build les plus simples. Il semble que la branche soit toujours disponible quelque part, peut-être dans un cache sur les serveurs de build ?

 > 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 Peut-être jenkins-setup qui exporte des variables utiles (telles que export HOME="$WORKSPACE/user space ) et ne

mkdir "build space"
cd "build space"

De plus, nous devrions créer des tâches de construction qui mettent à jour un référentiel global. Tâches individuelles voir ci-dessus.

Le repo global pourrait certainement aider à réduire la bande passante. Construire des scripts dans les sources pourrait également être une bonne idée, au moins ils seraient suivis par git.

Je ne suis pas fan des espaces dans les chemins, mais bien sûr.

build rapide dans passwd cassé?

Le travail de construction rapide est ennuyeux, j'essaie de supprimer kdberrors.h à chaque construction et de voir si cela fonctionne plus facilement. À long terme, la proposition de @manuelm dans #730 est la meilleure solution : nous devons simplement vérifier comment la source a été mise à jour, et sur cette base, prendre les mesures appropriées.

Je pense que #894 corrige également la construction rapide, je commenterai la ligne en supprimant kdberrors.h.

Certains travaux sont cassés, par exemple le travail html doc.

@mpranj Avez-vous le temps de le regarder ?

@markus2330 Terminé. Les échecs de build restants ne semblent pas liés au système de build.

@mpranj Merci ! Qu'avez-vous fait pour le réparer ? Je pense qu'il serait utile que nous rassemblions ici également des solutions pour créer des problèmes de serveur.

J'ai changé dans "Gestion du code source" > "Git"
Valeur du "spécificateur de branche" "**" à "${sha1}"

C'est ce que nous utilisons aussi dans les autres emplois. Cela permet de déclencher le build par bouton (branche par défaut sur master) ou par github PR builder (sha1 de commit).

Je me souviens avoir défini une fois la variable ENV "sha1" sur "master". Cela semble manquer maintenant, mais les travaux fonctionnent bien, alors ignorons cela.

Je pense que nous serions en mesure d'accélérer les builds beaucoup plus en utilisant les bibliothèques d'objets plus fréquemment. De nombreux fichiers objets sont compilés plusieurs fois. Nous n'aurions qu'à nous assurer que les indicateurs de compilation sont les mêmes pour chaque endroit où nous utilisons les bibliothèques d'objets, mais je suppose que cela devrait être facilement possible.

Un exemple où cela pourrait faire une grande différence est KDB à mon avis.

@Namoshek S'il

Jenkins a été mis à niveau vers la version 2.7, tous les plugins ont été mis à niveau, les plugins recommandés ont été ajoutés :

• Pipeline (l'installation semble avoir échoué ?)
• Plugin de dossier d'organisation GitHub

et quelques plugins désinstallés :

• API de succursale
• CVS/SVN (semble ne plus être indispensable)

De plus, ruby-dev a été installé sur chaque agent.

J'ai mis à jour les "Problèmes actuels" dans le premier message. Il serait important qu'Elektra compile également sans aucune dépendance installée, nous devons donc vérifier cela avec des agents de serveur de build qui n'ont aucune dépendance installée (sauf cmake et build-essential). Cependant, les agents de compilation FreeBSD et OpenBSD sont également importants ;)

@mpranj Avez-vous une idée de ce qui ne va pas avec elektra-multiconfig-gcc47-cmake-options ? Ils ont des erreurs "fatal: reference is not a tree:" partout. Leur job a-t-il "sha1" dans sa config ?

J'ai rendu la multiconfig indépendante des compilateurs concrets (il existe suffisamment d'autres tâches de construction pour des compilateurs spécifiques), elles devraient donc pouvoir s'exécuter sur n'importe quel agent.

@markus2330 Aucune idée. Je n'ai rien changé et juste :

• déclenché manuellement une génération à partir du maître
• a déclenché une compilation à partir de github

Les deux versions ont pu vérifier l'arbre et commencer à construire.
Donc : je ne peux pas le reproduire.

Une idée : travis a eu des problèmes quand il y avait un PR et vous le fusionnez avant que travis ne puisse faire le clonage. Peut-être que quelque chose de similaire s'est produit avec elektra-multiconfig-gcc47-cmake-options car une construction prend environ 3 heures.

Pousser les artefacts vers doc.libelektra.org fonctionne à nouveau, Jenkins et les plugins ont été mis à niveau.

J'ai mis à jour la nouvelle URL du serveur de build https://build.libelektra.org dans les Webhooks de github. J'espère donc que les prochains PR seront à nouveau construits.

La maison de Jenkins est presque pleine. Il semble également ne pas construire de relations publiques.

La maison de Jenkins est presque pleine.

Merci je l'ai redimensionné.

Il semble également ne pas construire de relations publiques.

Avez-vous une idée de ce qui pourrait ne pas aller ici? Le déclenchement manuel semble fonctionner ?

Publication du document sur doc.libelektra. org:12025 a échoué pour les builds. J'ai redémarré le serveur ssh (sur l'agent build-homepage) et il semble fonctionner à nouveau.

Le vserver pour *.libelektra.org semble être inaccessible. Je l'ai signalé à hetzner.

La raison de la fermeture de la connexion réseau à partir du conteneur était que libelektra.org est compromis. Voir #1505 pour plus d'informations.

Ce serait formidable si nous pouvions ajouter un paquet git-build pour stretch, il y a de plus en plus d'endroits où nous aurions besoin de paquets debian construits pour stretch.

@BernhardDenner avez-vous parcouru le premier message ? Y a-t-il quelque chose que vous pouvez facilement faire ? Y a-t-il quelque chose que @mpranj doit prendre en compte lors de l'amélioration des tâches de serveur de build à l'avenir ?

Comme demandé par @sanssecours j'ai (temporairement) désactivé les requêtes elektra-merge afin que les PR n'obtiennent pas toujours une erreur erronée. De plus j'ai ajouté pour @KurtMi

jenkins compiler gcc-configure-debian-optimizations s'il vous plaît

@KurtMi Si vous avez besoin de modifier ce que fait la tâche de build, modifiez simplement les scripts/configure-debian-optimizations

@sanssecours a désormais également accès au serveur de build.

D'ailleurs. vous pouvez de toute façon annuler des travaux s'ils sont remplacés par d'autres travaux (il y a actuellement une lourde charge). Veillez uniquement à ne pas interrompre les travaux pour les PR actifs, sinon le PR ne deviendra pas vert. (Sauf si vous les redémarrez avec la phrase "jenkins build... please".)

@sanssecours Jenkins a été redémarré (la deuxième fois). Pourriez-vous s'il vous plaît documenter ici si vous installez de nouveaux plugins. (Les mises à jour n'ont pas besoin d'être documentées).

Les demandes de redémarrage peuvent également être effectuées ici.

J'ai changé "Quiet period" de 2 à 5 pour donner plus de temps pour fusionner plusieurs PR et/ou pousser différents commits sans reconstruire de manière répétitive.

De plus, j'ai ouvert le problème #1689 décrivant les délais d'attente dans les builds (je ne l'ai pas ajouté ici en raison de longs messages d'erreur).

J'ai également déplacé certaines tâches obsolètes ci-dessus dans la nouvelle section « Problèmes obsolètes/non pertinents [raison] : ».

J'ai mis à jour les plugins sur le serveur de build. Espérons que les mises à jour résolvent les problèmes que nous avons dans les PR #1698 et PR #1692.

@markus2330 Pouvez-vous s'il vous plaît redémarrer le serveur de build ?

J'ai mis à niveau Jenkins de 2.73.2 à 2.73.3 et redémarré Jenkins.

Espérons que les mises à jour résolvent les problèmes que nous avons dans les PR #1698 et PR #1692.

Il pourrait s'agir d'un problème général non lié à ces deux PR ? Espérons que ce soit corrigé maintenant.

On dirait que JENKINS_HOME est presque plein 😢.

@markus2330 👋 Pourriez-vous s'il vous plaît

• nettoyez le répertoire personnel ou dites-moi comment je peux le faire,
• mettre à jour Jenkins et tous les plugins obsolètes ?

Merci de m'avoir cinglé !

On dirait qu'un plugin avait une "vulnérabilité de lecture de fichier arbitraire", à savoir le "Script Security Plugin 1.35".

J'ai mis à niveau tous les plugins et également mis à niveau jenkins de 2.73.3 à 2.89.1.

De plus, j'ai redimensionné le disque de 20 Go à 50 Go.

Nous devrions redémarrer le serveur bientôt, certains processus non redémarrés pourraient être affectés par les mises à niveau de la bibliothèque, ce qui pourrait ne pas être sécurisé pour le moment (pas lié à jenkins, cependant). @BernhardDenner Pouvez-vous redémarrer (et

N'hésitez pas à signaler tout ce que j'ai cassé lors de ces mises à niveau.

Le serveur avait une charge de 20 et a à peine répondu. Nous devons être prudents avec "jenkins build all please" et à plus long terme, nous devrions éloigner les agents du serveur principal.

J'ai mis à niveau vers Jenkins 2.89.2 et redémarré le serveur. Je ferai un rapport lorsque tout sera à nouveau opérationnel.

Il semble que tous les agents soient maintenant déconnectés avec l'erreur "La clé d'hôte du serveur n'a pas été acceptée par le rappel du vérificateur".

@BernhardDenner J'ai vu que

J'ai essayé de rétrograder en 2.89.1 et 2.73.3 sans succès : la connexion aux agents ne fonctionne toujours pas.

Un grand merci à @BernhardDenner qui a résolu le problème ssh.

Nous devrions arrêter de mettre à jour Jenkins sans lire les notes de version, il semble que même les mises à jour stables cassent trop de choses. (Ce ne sont même pas réversibles en déclassant!)

Je dois signaler un goulot d'étranglement majeur sur le serveur de build.
elektra-multiconfig-gcc47-cmake-options prend 14h et le
elektra-multiconfig-gcc-stable prend 4h.
Je ne sais pas s'il s'agit d'un nouveau comportement et je suis conscient que ces travaux ne sont pas un seul travail de build, mais ce goulot d'étranglement ne doit pas passer inaperçu.

Merci d'avoir signalé. L'idée était de distribuer des sous-jobs de ces jobs au matériel ryzen, malheureusement personne n'avait le temps pour l'installation. Si quelqu'un est intéressé, merci de me contacter.

a7.complang.tuwien.ac.at (ryzen) semble s'être écrasé. J'ai signalé le problème. Notre administrateur redémarrera, espérons-le, l'ordinateur lundi.

J'ai temporairement désactivé l'incrémentiel (erreur étrange, voir # 1784), l'administrateur a redémarré le serveur ryzen, puis j'ai redémarré jenkins (car Jenkins ne pouvait pas se connecter à ryzen et il y avait un énorme retard de builds ryzen).

ryzen fonctionne à nouveau et construit le backlog.

L'idée était de distribuer des sous-jobs de ces jobs au matériel ryzen

@markus2330 J'ai remarqué qu'il existe une option appelée Run each configuration sequentially dans les paramètres de la matrice de configuration du travail multiconfig. Peut-être qu'il est distribué automatiquement si nous décochons simplement ceci afin qu'il crée plusieurs options de configuration à la fois, ou avez-vous déjà essayé cela?

Non, je ne l'ai pas essayé, s'il vous plaît essayez-le.

@ markus2330 à en juger par la file d'attente du serveur de construction, cela semble faire l'affaire, je l'appliquerai également à gcc-stable après avoir fonctionné pour gcc-stable-multiconfig

J'ai remarqué cependant que le ryzen ne semble pas gérer ces tâches. Je pense que c'est parce qu'il est configuré pour gérer uniquement les tâches correspondant à ses balises et que les versions multiconfig ne semblent pas définir ces balises de manière appropriée à première vue. Nous devrions donc soit faire en sorte que ryzen exécute tout ce qui est possible, soit définir plus de balises sur les tâches de build. Il semble que Ryzen ne gère pas les tâches pour lesquelles aucune balise n'est définie.

je l'appliquerai à gcc-stable en plus après avoir fonctionné pour gcc-stable-multiconfig

Merci!

J'ai remarqué cependant que le ryzen ne semble pas gérer ces tâches.

Non, ce n'est pas le cas, mais il exécute déjà un tas d'autres tâches. Mais peut-être pouvons-nous créer une v2 pour le faire ?

je vais l'appliquer à gcc-stable en plus

terminé

Mais peut-être pouvons-nous créer une v2 pour le faire ?

J'ai configuré la v2 et maintenant j'attends seulement que le PR #1806 soit fusionné afin que je puisse autoriser plus de versions qu'une. J'ai pensé que 8 travaux devraient être parfaits pour cela car il s'agit d'un 8 cœurs, avec -j 2 afin d'utiliser également le SMT?

Pour redémarrer le conteneur build-v2 au cas où v2 planterait ou serait redémarré, tapez simplement . Notez que cela ne peut être fait que si le conteneur a déjà été construit - suivez doc/docker/jenkinsnode/README.md pour ces instructions. Ensuite, utilisez cette commande pour redémarrer après la création du conteneur mais son arrêt :

docker start build-v2

De plus, pour transférer la connexion ssh du nouveau nœud de construction de la v2 via l'a7 vers le monde extérieur, j'ai configuré le tunnel ssh suivant sur l'a7 (le conteneur docker mappe son port ssh sur 22222 sur la v2) :

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

En plus de cela, la clé ssh publique du conteneur docker change à chaque reconstruction d'image et doit donc également être ajustée dans le serveur de construction. Ce n'est pas nécessaire si le conteneur est uniquement redémarré. Pour le découvrir, entrez ce qui suit sur 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>

Ne copiez que les deux premières choses, donc l'algorithme de clé et la clé elle-même, ne copiez pas ces informations utilisateur à la fin de la configuration de ryzen-v2 dans jenkins pour la clé ssh !

v2 est en panne, j'ai informé l'administrateur. C'est assez étrange : a7 et v2 sont tous les deux des matériels complètement nouveaux et les incidents sont assez fréquents.

La v2 semble être de retour et j'y ai redémarré le conteneur de construction. J'espère donc que nous avons à nouveau des versions plus rapides. De plus, j'ai ajouté elektra-haskell à "jenkins build all please" car je veux avoir des builds haskell stables pour mon vérificateur de type, donc les tests sont un bon ajout.

De plus, je veux laisser une note ici que nous voulons également créer un autre nœud de construction qui s'occupe des constructions mm qui semblent maintenant être le nouveau goulot d'étranglement sur la v2.

Enfin, @markus2330, je pense que le vérificateur de /testscr_check_bashisms.sh .

Tous les nœuds de l'étiquette debian-jessie-homepage||homepage et de l'agent de génération debian-wheezy-mr sont actuellement hors ligne. Le redémarrage des agents de build ne fonctionne pas. Ce serait vraiment bien si quelqu'un avec SSH ou un accès physique à ces nœuds pouvait examiner ce problème.

J'ai redémarré les vservers mais le redémarrage des agents dans jenkins n'a pas fonctionné avec l'erreur "Aucune miette valide n'a été incluse dans la demande". @BernhardDenner Vous avez une idée ?

On dirait que la v2 est également en panne. Nous avons donc 3 agents non fonctionnels 😢

La v2 est de retour, mais je me demande pourquoi elle tombe toujours en panne ? cela pourrait-il être lié à notre processus de construction?

En ce qui concerne le "pas de miette valide", je l'ai vu aussi lorsque j'ai essayé de redémarrer l'agent sur la v2, mais lorsque je l'ai simplement réessayé, cela a fonctionné.

La v2 est de retour, mais je me demande pourquoi elle tombe toujours en panne ? cela pourrait-il être lié à notre processus de construction?

Cela semble être une défaillance du noyau/matériel (même sysreq ne fonctionne pas lorsque l'ordinateur se bloque). Notre utilisation peut déclencher l'erreur. L'ordinateur a fonctionné sans aucune erreur pendant plusieurs mois et depuis que nous l'utilisons, nous l'avons déjà planté trois fois.

J'ai mis à jour le noyau et purgé le serveur X.

En ce qui concerne le "pas de miette valide", je l'ai vu aussi lorsque j'ai essayé de redémarrer l'agent sur la v2, mais lorsque je l'ai simplement réessayé, cela a fonctionné.

Merci! J'ai maintenant pu redémarrer l'agent de page d'accueil.

De plus, j'ai désactivé l'agent debian-jessie-minimal et sa tâche de build. Nous devrions créer des conteneurs docker pour des tâches minimales, j'ai ajouté ceci en tant que tâche.

Comme nous avons été surpris hier, le serveur de la communauté était en panne car il s'est écrasé et un mauvais cache ARP a redirigé nos adresses IP vers d'autres serveurs. Après le redémarrage, tout a fonctionné à nouveau, mais la synchronisation du raid est toujours en cours. (Cela peut être si lent à cause de la charge élevée.)

Le serveur communautaire a une charge quasi constante de 10. Pour le moment, il est 13.20 11.29 9.35. Nous devrions vraiment réduire les tâches exécutées directement sur le serveur de la communauté et déplacer la charge vers la v1. Des volontaires?

Il y a une mise à niveau de Jenkins de 2.89.2 à 2.89.4. Malheureusement, je n'ai pas trouvé de moyen simple de voir le journal des modifications ( apt-get changelog échoue car il s'agit d'un package non officiel). Des raisons de ne pas faire cette mise à jour ?

Le journal des modifications en amont est sur https://jenkins.io/changelog-stable/
Apparemment, la version 2.89.4 contient des correctifs de sécurité.

Merci de l'avoir recherché !

J'ai mis à niveau vers Jenkins 2.89.4 et tout fonctionne à nouveau.

elektrahomepage n'a pas été démarré par défaut après les redémarrages, j'ai changé cela (/etc/vservers/elektrahomepage/apps/init/mark=default).

J'ai également activé la tâche de build test-docker.

v2 est en panne, encore :cry:

Mais au moins a7 semble être stable maintenant.

J'ai installé clang-format-5.0 sur a7 et sur le nœud stretch (debian-stretch-mr).

Pour les prochains PR, veuillez reformater selon clang-format-5.0.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ a été temporairement désactivé.

Nous étudions actuellement la v2. UEFI est de 6.6.17. Il semble que les accidents se produisent toujours le week-end, peut-être y a-t-il une charge plus élevée à ce moment-là ? Je vais essayer de répliquer la configuration de la v1 sur la v2.

v1 et v2 fonctionnent avec le même noyau.

@e1528532 semble que votre pont ssh n'a pas démarré et la commande dans doc/docker/jenkinsnode/README.md échoue avec "Impossible de préparer le contexte : impossible d'évaluer les liens symboliques dans le chemin Dockerfile : lstat /root/Dockerfile : aucun fichier ou répertoire de ce type " puis "Impossible de trouver l'image 'buildelektra- stretch:latest ' localement". Cela signifie que la v2 n'est pas accessible pour le moment.

@markus2330 a écrit: problème déplacé vers #1829

Je pense que l'une des dernières mises à jour du serveur de build a cassé elektra-gcc-configure-debian-stretch , qui ne peut plus se connecter au référentiel :

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

.

Je pense que le problème avec elektra-gcc-configure-debian-stretch est le serveur de build ryzen , qui est incapable de se connecter à GitHub. J'ai changé l'étiquette de la tâche de construction de debian à debian-stretch-mr conséquence. Maintenant, la tâche de build semble fonctionner à nouveau .

ryzen, qui ne parvient pas à se connecter à GitHub

On dirait que le correctif NetworkManager de notre administrateur avec "manged=true" n'a pas fonctionné de manière fiable. Après le redémarrage, "/etc/resolv.conf" était à nouveau un lien symbolique suspendu. Je l'ai corrigé à nouveau, GitHub devrait être accessible depuis ryzen. rzyen v2 n'est malheureusement toujours pas accessible (le pont ssh est manquant).

Elektra 0.8.22 est enfin disponible. J'ajouterai le lien vers #676 une fois le site Web créé, la création du site Web prend plus d'une heure. Peut-être pouvons-nous déplacer la construction de la page d'accueil vers une machine plus rapide et copier uniquement le site Web résultant à son emplacement.

Je pense que nous devons faire quelque chose à propos du serveur qui héberge http://build.libelektra.org. C'est juste insupportablement lent et insensible 😢. Personnellement, cela m'est égal si une construction complète de tous les tests prend du temps. Cependant, dans l'état actuel des choses, il faut même quelques minutes pour se connecter au serveur, si nous sommes en mesure de nous connecter au serveur :

<!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>

.

Oui, ce n'est pas seulement Jenkins qui est affecté, mais tout le reste s'exécutant sur ce serveur. Pour moi, la situation est souvent aussi inacceptable. Il semble qu'il y ait trop peu de RAM. (un échange 2GiG est utilisé)

Jenkins pourrait être la raison, il existe des dizaines de processus Java qui sont en tête de liste dans htop. Pendant longtemps, nous avons eu assez de RAM et le swap était à peine utilisé, et nous n'avons pas beaucoup changé (à part la mise à niveau de Jenkins et l'augmentation du nombre de tâches de build).

Je suggère d'arrêter d'utiliser le serveur communautaire en tant qu'agent. Pour cela, nous aurions besoin de la v2 mais @e1528532 semble être occupé. Nous pourrions également louer un meilleur serveur, mais nous aurions alors besoin de quelqu'un qui a le temps pour la migration.

@markus2330 Pouvez-vous s'il vous plaît redémarrer le serveur de build ? Actuellement, même des tâches simples comme elektra-todo échouent.

J'ai redémarré la v2 dimanche, mais apparemment, elle est déjà à nouveau en panne, nous devrions donc d'abord stabiliser la v2 avant de penser à mettre d'autres choses dessus.

J'ai redémarré Jenkins et la v2. Jenkins semble à nouveau fonctionner correctement.

@e1528532 Le tunnel ssh semble toujours ne pas fonctionner. Même après avoir redémarré a7, il n'est pas possible de se connecter à v2.

nous devrions donc d'abord obtenir la v2 stable avant de penser à mettre d'autres choses dessus.

Le principal temps d'arrêt a été causé par le pont ssh. Si la v2 avait des problèmes, elle était généralement redémarrée dans la journée.
J'ai maintenant supprimé le reste du serveur X, j'espère donc que la v2 est maintenant stable également. Pour a7, cela semblait être l'astuce (aucun redémarrage n'a été nécessaire pendant un certain temps). Sans charge sur v2 (qui nécessite le pont ssh), cependant, nous ne saurons pas avec certitude s'il est stable.

Que diriez-vous de diviser les discussions sur le matériel (redémarrages) et les logiciels (mises à niveau Jenkins) ?

Il semble y avoir un problème de connectivité réseau entre a7 et v2. La v2 est opérationnelle, mais j'obtiens toujours "Aucun itinéraire vers l'hôte". On dirait que je ne peux pas le réparer aujourd'hui.

Le réseau de la v2 était en panne car la désinstallation de GNOME a également désinstallé le gestionnaire de réseau. Nous avons maintenant réparé le réseau (à l'aide de /etc/network/interfaces) et mis à niveau vers le dernier BIOS/UEFI. J'espère donc que tout est maintenant stable.

D'ailleurs. il y a un autre matériel que nous pourrions utiliser via un pont ssh... (PCS)

Le tunnel ssh semble toujours ne pas fonctionner. Même après avoir redémarré a7, il n'est pas possible de se connecter à v2.

Oui, ce n'était pas automatisé. Maintenant, je me suis occupé de tout. Le conteneur Docker devrait redémarrer automatiquement maintenant si la machine redémarre. Au moins, j'ai défini l'indicateur --restart sur "toujours" selon https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode #37618747

De plus, j'ai créé un nouvel utilisateur appelé "ssh-tunnel-a7-v2" qui n'a pas de mot de passe défini sur a7 et v2 (donc, l'authentification par mot de passe désactivée pour celui-ci). J'ai créé un certificat ssh pour l'utilisateur sur l'a7 et en ai ajouté la clé publique aux hôtes connus sur la v2. Ensuite, j'ai ajouté un service systemd à /etc/systemd/system/ssh-tunnel-a7-v2.service qui ouvre le tunnel ssh automatiquement en tant que service systemd selon https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service . Par conséquent, cela devrait également fonctionner lorsque le serveur est redémarré ou que la connexion ssh se bloque et ne dépend plus de moi ou de mon utilisateur. En raison de l'utilisation d'un certificat, aucun mot de passe ne doit être utilisé pour les connexions.

En plus de cela, la v2 est bien sûr redémarrée avec cette nouvelle configuration automatisée active. Espérons qu'il survivra au prochain crash (s'il y en a un), théoriquement il devrait mais nous verrons.

La tâche de build test-docker échoue toujours, si Jenkins exécute la tâche sur 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

. Je voulais restreindre le travail à des nœuds autres que ryzen v2 , mais il semble que l'option pour cette étape soit manquante dans la page de configuration de test-docker . Quelqu'un pourrait-il s'il vous plaît jeter un oeil et résoudre ce problème?

Merci de l'avoir examiné ! N'est-il pas possible d'attribuer plusieurs labels aux agents ? Ensuite, vous pouvez attribuer une étiquette unique à ryzen v2 et lier le travail à celui-ci.

Heureusement, nous aurons bientôt du support pour notre serveur de build :+1:

N'est-il pas possible d'attribuer plusieurs labels aux agents ?

Pour autant que je sache oui, il est possible d'attribuer plusieurs étiquettes à un agent.

Ensuite, vous pouvez attribuer une étiquette unique à ryzen v2 et lier le travail à celui-ci.

Comme je l'ai déjà indiqué avant [[1]], l'option « Restreindre où ce projet peut être exécuté » semble manquer :

Je voulais restreindre le travail à des nœuds autres que ryzen v2 , mais il semble que l'option pour cette étape soit manquante dans la page de configuration de test-docker .

.

Ahh, j'ai mal compris votre déclaration comme suit : "Il n'y a aucun moyen d'écrire une expression booléenne qui me permette de dire (stable && !ryzenv2)", pas qu'il n'y a aucune option pour la restriction d'agent.

Peut-être que cela peut être fait par le DSL. Je demanderai à Lukas s'il sait quoi faire.

Salut,

comme @sanssecours l'a noté, ryzen v2 n'a pas de docker installé mais il a la balise docker.
Les exécutions de test-docker nécessitent que les nœuds aient la balise docker.

Les solutions possibles consistent soit à installer docker sur le nœud, soit à supprimer la balise du nœud dans jenkins

Les solutions possibles consistent soit à installer docker sur le nœud, soit à supprimer la balise du nœud dans jenkins

Merci d'avoir apporté une solution au problème. Je viens de supprimer la balise docker de ryzen v2 . Autant que je sache, tout semble fonctionner maintenant.

J'ai mis à jour la description du nœud 'ryzen v2' pour refléter qu'il s'agit en fait 'seulement' d'un conteneur docker fonctionnant sur v2. C'est pourquoi docker n'était pas disponible même s'il est installé sur la v2.

Ajout d'un plugin à jenkins qui permet une visualisation plus facile des données de construction (ne pas avoir à cliquer dans chaque construction)

La v2 est à nouveau en panne, je l'ai signalé.

J'ai redémarré la v2 mais je n'ai pas pu reconnecter l'agent.

Au moins, nous avons finalement reçu des messages d'erreur sur ce qui s'est passé avant le crash (bien sûr, il n'y a aucune garantie que les messages d'erreur aient quelque chose à voir avec le crash) :

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

Étrange, il semble que ma machine de redémarrage ait fonctionné, le tunnel ssh et les nœuds docker ont été redémarrés et je peux me connecter à a7.complang.tuwien.ac.at -p 22222, ce qui signifie que tout doit être ouvert. Cependant, jenkins me montre juste un rouet infini pour une raison quelconque, pas de délai d'attente, rien.

J'ai essayé mon bridge ssh manuel comme on en avait avant, pareil. Redémarré le conteneur Docker une fois de plus, la même chose. Donc honnêtement, je ne sais pas exactement ce qui ne va pas maintenant sans message d'erreur, la seule chose que j'ai trouvée est un gars qui a apparemment un bogue similaire (roue tournante mais pas de message) mais pas de solution à ce sujet à part redémarrer l'ensemble du maître jenkins node (que je n'ai pas essayé): https://issues.jenkins-ci.org/browse/JENKINS-19465

EDIT: j'ai essayé l'une des solutions de contournement suggérées (réinitialiser la configuration du nom d'hôte à quelque chose qui n'existe pas, se reconnecter, puis jenkins se rend compte que le nom d'hôte est erroné, reviens au nom d'hôte réel, puis cela a soudainement fonctionné sans autre problème). Donc, je suppose que cette erreur s'est produite au lieu de quelque chose avec ma configuration de redémarrage, mais attendons le prochain crash pour en être sûr ;)

@markus2330 je parie que vous l'avez déjà découvert vous-même, mais une recherche rapide m'a montré que cela pourrait être lié à la configuration c-state : https://bugzilla.kernel.org/show_bug.cgi?id=196683 , il y a quelques suggestions solutions de contournement pour cela

On dirait que le serveur de build ryzen est incapable de se connecter à notre référentiel :

Échec de la récupération depuis https://github.com/ElektraInitiative/libelektra.git

.

la configuration DNS pendait à nouveau. Comme je ne comprends pas bien pourquoi c'est
configuration telle qu'elle est actuellement, je n'ai restauré que les paramètres du serveur de noms et
redémarré le travail de build docker.

Le 12 mars 2018 à 17h03, René Schwaiger [email protected] a écrit :

On dirait que le serveur de build ryzen est incapable de se connecter à notre référentiel
https://build.libelektra.org/jenkins/job/test-docker/162/console :

Échec de la récupération depuis https://github.com/ElektraInitiative/libelektra.git

.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

Comme je ne comprends pas bien pourquoi il est configuré comme il l'est actuellement

J'ai peur que personne ne le comprenne. Peut-être que le serveur DNS est mal configuré et ne donne pas les informations appropriées sur le serveur de noms. Pour la v2, nous avons désinstallé le gestionnaire de réseau et il semble que resolv.conf y soit maintenant stable. Une option consiste donc à désinstaller également le gestionnaire de réseau sur a7. (et utilisez /etc/network/interfaces) Il n'y a aucune raison pour que v2 et a7 aient des configurations divergentes, c'est uniquement à cause d'une administration bâclée.

Idéalement (à long terme), nous gérons les deux en utilisant Puppet.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , il existe des solutions de contournement suggérées pour cela

C6 devrait être désactivé mais nous continuerons l'enquête.

Le nouvel agent de construction "ryzen v2 docker" ne semble pas avoir de démon D-Bus fonctionnant comme "debian-stable-mm" .

Quelqu'un peut-il l'installer/le démarrer ou me dire quel script configure les versions multiconfig-gcc47-cmake-options afin que je puisse ajouter un extrait pour m'assurer qu'il est démarré ?

@ markus2330 Je suppose que puisque ifupdown et networkmanager sont activés, ils se mettent tous les deux dans les cheveux. désactiver l'un des deux aiderait certainement.

D'accord, j'ai supprimé gnome et network-manager sur a7 pour être cohérent avec la v2.

Le nouvel agent de construction "ryzen v2 docker" ne semble pas avoir de démon D-Bus fonctionnant comme "debian-stable-mm".

L'agent de construction réside dans un conteneur Docker , espérons que @e1528532 peuvent vous aider à démarrer le démon dbus là-bas.

Merci. Cela devrait être assez facile. Je le lance dans le conteneur docker (Ubuntu 17.10 artful construit à partir de docs/docker/Dockerfile ) avec les commandes suivantes :

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

Le serveur de build ryzen ne parvient pas à se connecter à nouveau

Désolé, c'est de ma faute. On dirait que l'arrêt du gestionnaire de réseau a suffi à casser le système.

Cela devrait être corrigé maintenant. N'hésitez pas à signaler d'autres problèmes.

@ markus2330 à peu près sûr qu'il se serait à nouveau cassé au prochain redémarrage

J'ai pris la liberté de refaire le fichier /etc/network/interfaces (et de déplacer la configuration des interfaces dans /etc/network/interfaces.d)
qui, combiné à la désinstallation du gestionnaire de réseau, devrait, espérons-le, le maintenir stable

veuillez revoir la configuration et peut-être déclencher un redémarrage pour voir si cela a fonctionné

@ingwinlu Merci pour le correctif, le redémarrage a bien fonctionné.

J'ai découvert que j'avais supprimé trop de packages, j'ai donc réinstallé Java (openjdk 9 headless et default-jre) :smile:

@ingwinlu Pourriez-vous s'il vous plaît faire fonctionner dbus sur l'agent v2 ? Idéalement, veuillez également déplacer "/home/armin/buildelektra-stretch/Dockerfile" vers une destination non spécifique à l'utilisateur.

@ markus2330 ma proposition sur la façon de procéder avec l'environnement de construction prévoit en fait la suppression du nœud dockercontainer-on-v2 actuel et son remplacement par un docker capable (c'est-à-dire ne pointant plus vers un conteneur docker sur v2 mais pointant directement sur v2) .

Ensuite, nous pouvons configurer le pipeline de génération pour créer l'image elle-même à partir de Dockerfiles archivés dans le référentiel afin de fournir les différents environnements nécessaires aux tests.

Je peux donner la priorité au déploiement d'une image docker compatible dbus lorsque j'y arrive, mais je n'aimerais pas faire un travail qui ne sera bientôt plus pertinent si je n'y suis pas obligé.

Oui, c'est logique !

L'objectif à plus long terme de la v2 est que nous devons le partager avec d'autres conteneurs docker (pas pour Elektra), donc ce serait une bonne chose si toutes nos pièces sont virtualisées de manière à ne pas pouvoir influencer les autres conteneurs docker. (peut-être docker récursif ou Xen ?) Nous pourrions/devrions faire de même pour que a7 ait des configurations identiques.

Nous continuerons à avoir accès directement sur les machines mais nous devrions réduire tout risque que Jenkins puisse tuer des machines Docker avec lesquelles cela n'a rien à voir.

Pour certains agents, nous avons déjà une configuration Puppet. Ce serait formidable si nous ne le contournions pas ou encore mieux : étendez cette configuration pour a7 et v2. J'espère que @BernhardDenner pourra vous donner plus d'informations à ce sujet bientôt.

Le serveur de build est à nouveau en panne 🙌.

Soit dit en passant, nous pourrions déplacer la discussion sur le statut du serveur de build vers une discussion de l'équipe GitHub , car ce sujet pourrait ne pas être intéressant pour toutes les personnes abonnés à ce problème.

Oui, tout le serveur est en panne, y compris le serveur de build :cry: Et la v2 est également en panne (indépendamment). J'ai redémarré la v2 et modifié l'option C-States dans UEFI. Mais il semble qu'il y ait un problème majeur avec notre serveur. Espérons que nous le remplacerons par un meilleur matériel avec plus de mémoire :crossed_fingers:

Discussion de l'équipe GitHub

Tout le monde d'ElektraDevelopers n'est-il pas averti si nous écrivons quelque chose dans la discussion de l'équipe GitHub ? Ici, dans ce numéro, chacun peut décider s'il souhaite s'abonner.

Pour moi, une question encore ouverte est de savoir si nous devons diviser ce problème en deux problèmes : liés au matériel et liés à Jenkins.

Tout le monde d'ElektraDevelopers n'est-il pas averti si nous écrivons quelque chose dans la discussion de l'équipe GitHub ?

Autant que je sache, oui.

Ici, dans ce numéro, chacun peut décider s'il souhaite s'abonner.

C'est également vrai pour les discussions d'équipe .

Le serveur de build est à nouveau opérationnel. Paramètres modifiés :

• Paramètres xms et xmx pour réduire la quantité de ramasse-miettes lorsque de nombreuses versions sont en file d'attente
• J'ai remarqué que nous utilisons l'interrogation scm. J'ai limité le poller à 4 sondages simultanés dans le monde à la fois pour, espérons-le, réduire un peu les pics que le serveur reçoit actuellement.

ÉDITER:

* Définir le nombre de builds à conserver à 30 pour tous les pipelines, car selon plusieurs sources, ceux-ci sont lus lors de l'accès à l'interface Web et donc un grand nombre d'anciennes versions ralentissent les demandes

Mettez à jour Jenkins vers la ver. 2.107.1

• Mettre à jour le fichier de guerre jenkins
• Désactivez le paramètre de sécurité des plugins Use browser for metadata download car cela ne permettrait pas de mettre à jour les plugins
• Mettre à jour les plugins vers les dernières versions disponibles

MODIFIER 2018-03-18 :

• Ajout d'un deuxième exécuteur à tous les nœuds exécutés sur mm

* a dépriorisé tous les agents exécutés sur mr

Master devrait être beaucoup plus réactif maintenant sous charge. Tout construire devrait être plus proche de 2h que des 4h+ d'avant.

MODIFIER 2018-03-24 :
désolé pour les retards, semaine chargée...

• Ajout d'un nouveau travail au jenkinsserver (elektra-jenkinsfile) qui exécutera le Jenkinsfile trouvé dans le repo (une fois qu'il existe)

MODIFIER 2018-03-28 :

• Refait le fichier d'unité de tunnel, maintenant il analyse les fichiers d'environnement et peut donc être ajusté pour pointer vers plusieurs cibles
• Ajout du serveur v2 en tant qu'esclave capable d'exécuter docker
  
  
  
  • utilisateur jenkins ajouté sur v2
  
  
  • installé openjdk-9 sur v2
  
  

MODIFIER 2018-03-29 :

• Correction des paramètres ulimit sur le maître jenkins

Bien que je sois à peu près sûr que @ingwinlu ou quelqu'un est déjà là-dessus : il semble que ryzen v2 soit mal configuré :

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

Run

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

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

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

de https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console mais arrivé à plusieurs reprises.

Oops désolé. Il n'a pas de deps installé et ne devrait agir qu'en tant qu'hôte docker. Je vais supprimer les drapeaux supplémentaires.
//EDIT: devrait être fait. j'espère que c'était suffisant
//EDIT2: J'ai également désactivé test-docker pour le moment car il ne peut évidemment pas trouver les images de construction nécessaires pour exécuter les tests.

Mais bon sang, la chose est rapide si elle obtient réellement quelque chose qu'elle peut construire
//EDIT3: activation du test-docker pour qu'il ne s'exécute que sur les nœuds avec la balise docker-prefab et a donné cette balise à ryzen

Malheureusement, le problème semble être plus important que prévu initialement.

Certains travaux ont leurs nœuds codés en dur. Certaines balises sont obsolètes (stables sur les nœuds jessie). Certains travaux ne nécessitaient pas les bons nœuds et n'étaient exécutés que sur le bon car il y avait été exécuté une fois auparavant et construit avec succès.

L'introduction d'un nouveau nœud (ryzen v2 natif) a un peu brouillé l'allocation alors qu'elle n'aurait pas dû.

Veuillez vous attendre à un comportement inattendu jusqu'à ce que tout fonctionne à nouveau là où il était.

Journal des modifications :

• nœuds renommés, <os>-<hostname>-<buildenv>
• désactivé elektra-multiconfig-gcc47-cmake-options
  il n'a en fait pas fonctionné sur les esclaves gcc47 depuis un certain temps maintenant, avec un mélange de construction gcc49 ou gcc63 selon l'endroit où il a été planifié. S'il est activé, il devrait probablement aller sur le dockercontainer activé par gcc63 sur v2
• retaggé une tonne d'emplois (peut-être en avoir manqué certains)
  
  
  
  • elektra-todo nécessitait stable , mais tous les nœuds stables n'avaient pas réellement sloccount installés
  
  
  • bien d'autres cas similaires
  
  

A7 semble être en panne

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

Bien que je sois à peu près sûr que @ingwinlu https://github.com/ingwinlu ou
quelqu'un est déjà là-dessus : il semble que ryzen v2 soit mal configuré :

FATAL : impossible d'appliquer la balise jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException : la commande "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" a renvoyé le code d'état 128 :
sortie standard :
stderr :
* Veuillez me dire qui vous êtes.

Courir

git config --global user.email " [email protected] "
git config --global user.name "Votre nom"

pour définir l'identité par défaut de votre compte.
Omettez --global pour définir l'identité uniquement dans ce référentiel.

fatal : nom d'identification vide (pour [email protected] ) non autorisé

de
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console
mais s'est produit à plusieurs reprises.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

Voulez-vous travailler dessus ? Je pourrais le redémarrer aujourd'hui. Comme alternative, notre administrateur ou moi pourrions le redémarrer mardi.

Si ce n'est pas trop compliqué. Sinon, je ne peux pas travailler sur mes relations publiques sur le
fin de semaine

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

Voulez-vous travailler dessus ? Je pourrais le redémarrer aujourd'hui. Comme alternative notre
admin ou je pourrais le redémarrer mardi.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

D'accord, je l'ai redémarré et j'ai également désactivé l'état C6 dans le BIOS/UEFI (était activé). J'ai également supprimé gnome/xorg (je pensais l'avoir déjà fait ?).

D'ailleurs. l'écran était complètement noir, nous ne pouvons donc que deviner quelle en était la cause.

ceux-ci sont apparus sur a7 toutes les 10 minutes environ :

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)

Ce sont peut-être les raisons du temps d'arrêt a7 ainsi que certains des comportements de construction étranges sur a7 latelty

Section valgrind désactivée dans elektra-ini-mergerequests car elle était exécutée via make run_memcheck

ceux-ci sont apparus sur a7 toutes les 10 minutes environ

Oui, nous les avons déjà vus. Lorsque l'ordinateur a été acheté, quelqu'un a vérifié si l'ECC fonctionnait et aucune erreur de ce type ne s'est produite à l'époque. La fréquence de ces erreurs dépend-elle en quelque sorte de la charge du système ?

Section valgrind désactivée dans elektra-ini-mergerequests telle qu'elle a été exécutée via make run_memcheck

Merci d'avoir nettoyé ça.

J'ai des sorties aléatoires (des conteneurs se bloquent, des builds s'arrêtent au milieu, des déconnexions, ...) sur a7 sans à nouveau de "vrais" journaux. seulement les corrections de mémoire déjà mentionnées.

Merci, il semble que quelque chose ne va vraiment pas. Et nous avons maintenant aussi des erreurs incorrigibles :

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

il y a encore a7.

sur un front plus productif : j'ai installé le frontend blue ocean sur jenkins. Aperçu

il y a encore a7.

C'est vraiment frustrant. J'ai redémarré la machine et reconnecté les agents. Je demanderai à notre administrateur de remplacer la RAM demain, alors attendez-vous à des temps d'arrêt demain.

sur un front plus productif : j'ai installé le frontend blue ocean sur jenkins. Aperçu

Ça a l'air super ! Peut-être pourrez-vous nous le montrer lors de la prochaine réunion ?

Notre admin est déjà en week-end. Je vais redémarrer a7 et réinitialiser le BIOS/UEFI aux paramètres d'usine. Si les erreurs persistent au cours du week-end, nous espérons qu'il échangera la RAM.

EDIT : aucune tâche de build n'était en cours d'exécution, donc aucune tâche de build n'a été annulée.

EDIT : Tout est à nouveau en place. Aucune erreur de mémoire jusqu'à présent.

Vous cherchez beaucoup mieux. Est-ce que quelqu'un a trop regardé les astuces techniques de Linus et overclocké le serveur ?

Désolé, j'ai dû arrêter Jenkins pendant un certain temps. Le serveur avait une charge de 20 et les choses que je devais faire n'étaient plus possibles (> 1h d'attente, puis j'ai abandonné et arrêté Jenkins).

Est-il possible que même les tâches de build non démarrées aient besoin de RAM ? (la liste de file d'attente était très longue) Sinon, les tâches de construction locales sont les meilleures candidates pour ces problèmes. (3 tâches de build locales étaient en cours d'exécution)

@ingwinlu Idéalement, nous ne construisons rien sur ce serveur. De plus, pouvons-nous rendre les tâches de build dépendantes de la charge sur un serveur. (Ne démarrez pas les travaux sur un serveur avec une charge > 5 ?).

J'ai tout recommencé mais j'espère que nous trouverons une solution rapide pour cela.

J'ai pompé la VERSION et la CMPVERSION dans les paramètres du système Jenkins.

@ingwinlu Ce serait formidable si nous avions également ces paramètres dans Jenkinsfile.

@ markus2330 voir 8de9272051fe903a7df08f0abdf18879701f7ac9 pour un exemple sur la façon d'y parvenir dans un fichier Jenkins

Suppression de make run_memcheck des cibles suivantes en raison de leur échec depuis un certain temps et de leur apparition dans le système de construction grâce à #1882

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

restreindre l'exécution de elektra-gcc-configure-debian-stretch sur les nœuds : stretch && !mr

Mettre à jour le maître jenkins vers ver. 2.107.2 + mettre à jour tous les plugins

J'ai essayé d'ajouter allowMembersOfWhitelistedOrgsAsAdmin à toutes les tâches de build aujourd'hui, mais il semble que je ne puisse toujours pas déclencher correctement une build all (voir #1863) et seules certaines tâches sont exécutées

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

Quelqu'un peut-il s'il vous plaît

• réparer
• désactiver, ou
• (encore mieux) supprimer

elektra-clang-asan s'il vous plaît . Actuellement, la tâche de build échoue bien que tous les tests défaillants :

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

fonctionne très bien sur Travis .

Ils ne testent pas les mêmes car (par exemple) ils utilisent différentes versions de clang...

Étant donné que ce fil est absolument impossible à suivre pour les rapports de bogues ou les discussions plus longues, j'ouvrirai de nouveaux problèmes pour clang et clang-asan dès que j'y arriverai.

Ils ne testent pas les mêmes car (par exemple) ils utilisent différentes versions de clang...

Je suis d'accord, alors que Travis utilise le clang 5.0.0 obsolète, la version Clang sur elektra-clang-asan est ancienne ( 3.8.1 ). Je ne vois pas la valeur d'un travail de construction activé par ASAN pour un si vieux compilateur.

J'ai créé #1919 pour l'échec du test "testlib_notification" sur "elektra-clang-asan".

J'ai testé un build all avec tous les agents mr désactivés et le maître était parfaitement réactif tandis qu'un build all avec tous les agents mr activés a en fait expiré certaines des builds. Par conséquent, #1866 apportera certainement une amélioration si nous pouvons nous débarrasser de tous les agents mr (-wheezy car il n'est pas conteneurisable)

Des tests supplémentaires montrent qu'il s'agit à peu près uniquement du travail de création de la page d'accueil. Je l'ai supprimé de build all pour l'instant afin qu'il ne soit exécuté qu'explicitement.

Il sera remplacé par une solution conteneurisée.

v2 est à nouveau en ligne avec le dernier BIOS.

Veuillez signaler toute erreur de segmentation ici (le processeur peut être bogué).

a7 semble être en panne?

Le 4 mai 2018 à 11h10, markus2330 [email protected] a écrit :

v2 est à nouveau en ligne avec le dernier BIOS.

Veuillez signaler toute erreur de segmentation ici (le processeur peut être bogué).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 est à nouveau opérationnel avec le dernier BIOS

a7 à nouveau?

Oui, il s'était écrasé. Il a montré l'invite de connexion sans aucun message d'erreur et aucune réaction du tout à aucune entrée (y compris sys-req). Seule la réinitialisation matérielle a aidé.

Si vous avez une idée du problème, n'hésitez pas.

malheureusement aucun journal persistant n'est configuré sur a7 donc pas de journaux

quand pouvons-nous nous attendre à ce que a7 et v2 soient à nouveau disponibles ?

Ohh, je ne savais pas qu'ils étaient en panne. Je demanderai à notre administrateur de redémarrer et s'il n'est pas en mesure de le faire, je le ferai vers 17h00.

Edit : Il a dit qu'il va les réinitialiser maintenant.

Edit : Ils sont tous les deux à nouveau debout.

J'ai redémarré a7 et v2 manuellement aujourd'hui. il semble que la v2 ne soit plus accessible. pouvez-vous s'il vous plaît, il est en cours d'exécution ?

//EDIT: résolu en corrigeant la configuration réseau sur les deux machines

apparemment a7 est retombé.

Ok, je vais la redémarrer. Sinon, nous n'obtiendrons jamais cette version.

une indication de la cause? juste des problèmes de réseau ou la machine n'a-t-elle plus répondu ?

Tout devrait être opérationnel maintenant.

Je viens de l'avoir au bon moment, il y avait des bûches jusqu'à ce qu'il finisse par complètement geler.

Les journaux étaient :

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

Cela pourrait être n'importe quoi. du processeur ryzen défectueux à un mauvais bloc d'alimentation :(

Le 12 mai 2018 à 14h33, markus2330 [email protected] a écrit :

Tout devrait être opérationnel maintenant.

Je viens de l'avoir au bon moment, il y avait des logs jusqu'à ce que finalement
complètement gelé.

Les journaux étaient :

INFO : rcu_sched a détecté des blocages sur les processeurs/tâches :
...
rcu_sched kthread affamé pour 7770 jiffies
chien de garde : BUG soft lockup - CPU #2 bloqué pendant 22 s ! [docker-gen]
... (nombreuses répétitions)
Chien de garde NMI : le chien de garde a détecté un LOCKUP dur sur le processeur 2

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

À propos de #1993

@ingwinlu Veuillez désactiver les travaux s'ils ne réussissent pas actuellement (ou du moins ne les déclenchez pas par défaut ni avec "jenkins build all please"). Il devrait avoir une haute priorité que nous n'échouons pas à des postes dans les PR où en fait tout va bien. (un échec pendant un certain temps n'était pas une bonne situation)

S'ils échouent à cause d'une action Jenkins que vous avez faite, redémarrer les travaux serait bien :heart: Le dire ici dans #160 est également correct.

La v2 est de nouveau disponible, avec un nouveau CPU !

S'il vous plaît soumettre de nombreux emplois pour les tests de stress :sourire:

a7 semble être à nouveau en panne.

Merci, tout est à nouveau en place.

J'ai redémarré a7.

Avoir un circuit qui réinitialise a7 toutes les heures augmenterait probablement la disponibilité.

quand pouvons-nous nous attendre à revoir a7 en ligne ?

a7 est de retour en ligne

La v2 est de retour en ligne

L'alimentation de la v2 sera échangée dans environ 1h.

@ingwinlu pouvez-vous désactiver les agents et les

Les agents v2 sont désactivés pour le moment

v2 fonctionne à nouveau. Il a une nouvelle alimentation. Veuillez soumettre de nombreux travaux pour tester la machine sous tension.

J'ai mis à jour les plugins jenkins. Le redémarrage qui en a résulté a partiellement restauré les anciens nœuds jenkins (avant qu'ils ne soient renommés), ce qui a entraîné des versions cassées partout, car les référentiels git étaient cassés.

J'ai nettoyé les référentiels affectés et nettoyé les conteneurs Docker mis en cache juste pour être sûr.

a7 est à nouveau en panne et en tant que telles, les versions basées sur Docker ne sont plus disponibles.

J'annule également la mise à jour vers xunit car elle viole les restrictions de sécurité.

J'ai redémarré a7 et reconnecté tous les agents.

les builds docker ne sont pas disponibles car a7 est à nouveau en panne.

J'ai redémarré le serveur et reconnecté les agents.

Je pense que remplacer a7 est la meilleure voie à suivre, voir #2020

Je pense que c'est à nouveau en panne, mon dernier commit a abouti à Impossible de contacter a7-debian-stretch : java.lang.InterruptedException

@e1528532 Merci de l'avoir écrit ici ! Si vous le souhaitez, vous pouvez également voter en #2020

J'ai redémarré a7 et reconnecté les agents.
Espérons pour le mieux qu'aucun problème ne survienne pendant le week-end.

a7 est à nouveau en panne :cry: Surprenant qu'il ait presque fonctionné tout le week-end. Peut-être le record de disponibilité de la semaine. Néanmoins, #2020 n'a pas reçu beaucoup de commentaires.

J'ai redémarré a7 (il a réagi à sysctl) et quelqu'un d'autre a démarré jenkins. Tout est de nouveau opérationnel.

a7 vient de retomber.

Merci pour l'info! J'ai redémarré a7 et reconnecté les agents.

Est-il logique que nous ayons l'agent "debian-jessie-minimal" ? Je pense que vous pouvez le supprimer en toute sécurité une fois qu'il est intégré dans Docker. (et il semble que c'est déjà le cas)

ÉDITER:
Dans https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
et https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
il y a des avertissements :

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)

mauvaises nouvelles. v2 est également tombé en panne.

EDIT: mais il me semble pouvoir m'y connecter via ssh....
EDIT2 : a émis un redémarrage sur v2 mais maintenant je ne peux plus me connecter. toujours pingable depuis a7 cependant...

EDIT3 : maintenant a7 est également en panne.

Merci d'avoir signalé ! J'ai redémarré a7 et v2. Nous devrions reconsidérer #2020.

Je pense que la v2 est à nouveau en panne :

Impossible de contacter v2-debian-stretch : java.lang.InterruptedException

Avec la v2, tout allait bien mais a7 était à nouveau en panne. Tous les agents sont à nouveau en ligne.

La v2 semble à nouveau ne plus répondre. pingable depuis a7 mais pas d'action ssh du tout. devrait être les problèmes btrfs des seuls symptômes. pouvez-vous tout redémarrer avant de rentrer chez vous pour le week-end ?

@ingwinlu Merci, @waht et j'ai redémarré la v2 avec succès mais je n'arrive pas à connecter les agents ("Connexion refusée (Connexion refusée)"). Une idée de ce qui ne va pas ici ? (la connexion ssh interactive fonctionne)

ssh ne fonctionnait que lorsqu'il ne se connectait pas via le pont.

après avoir redémarré le service de pontage, la connexion a pu être établie.

semble que le ssh-tunnel s'est retrouvé dans un état indéfini étrange et ne s'est pas suicidé. Je ne sais pas pourquoi il ne s'est pas tué (serveraliveinterval est activé).

Je devais également nettoyer manuellement tous les espaces de travail sur v2 car le fs était corrompu et tous les travaux de construction sur eux échouaient.

a7 semble être en panne. Je ne sais pas si je peux le redémarrer avant lundi.

J'ai redémarré a7 et v2. (v2 car il y avait des messages d'erreur sur a7 qu'il ne peut pas créer le pont ssh vers v2. Mais aussi après le redémarrage de v2, les mêmes messages d'erreur se sont produits. Néanmoins, le pont ssh semble fonctionner. Peut-être qu'il manque une dépendance (réseau ?) les scripts de démarrage de a7 ?)

Peut-être qu'il manque une dépendance (réseau ?) dans les scripts de démarrage de a7

Non c'est là.

il ne peut pas créer le pont ssh vers v2

Je pense que ce comportement se produit lorsque le noyau v2 commence à ne plus répondre (et qu'aucune connexion réseau entrante ne peut donc être établie). Dans le passé, vous avez mentionné des journaux indiquant des erreurs btrfs sur v2.

Je prépare le serveur de build pour un arrêt pour remplacer le CPU plus tard.

a7 et v2 sont de retour (a7 avec un nouveau processeur, v2 avec son système de fichiers racine vérifié)

alors qu'il a continué pendant la journée (avec une construction cohérente), il semble qu'a7 vient de redescendre.

Oui, je redémarre demain matin.

Nous devrions à nouveau discuter de #2020.

J'ai redémarré a7. C'était à nouveau un blocage du processeur.

a7 est à nouveau en panne.

Merci, je l'ai redémarré. Tous les agents sont à nouveau en ligne.

On dirait que certains des nœuds Debian sont en panne et donc quelques PRS attendent déjà depuis longtemps que l'exécution du test commence. Est-ce voulu?

On dirait que certains des nœuds Debian sont en panne et donc quelques PRS attendent déjà depuis longtemps que l'exécution du test commence. Est-ce voulu?

Lors d'une mise à niveau sur le nœud mm-debian-unstable, la machine ne répond plus et nous n'avons pas pu nous y connecter depuis. Étant donné que le propriétaire ne répond pas à nos e-mails, il sera probablement parti pour toujours.

Bien que nous ayons porté une bonne quantité de tâches de build sur le nouveau système, celles qui manquent sont déjà celles qui sont actuellement suspendues dans la file d'attente.

J'ai désactivé les travaux concernés et les ai marqués comme devant être remplacés + supprimés de la documentation

@ingwinlu Merci d'avoir pris soin de ça !

Lire les tests xdg est assez important si quelqu'un veut travailler sur le résolveur. Je l'ai ajouté au premier post ici. Pouvez-vous mettre à jour ce que vous avez déjà réalisé dans la liste de contrôle ci-dessus ?

Cette fois, la v2 est l'heureuse gagnante.

@ markus2330 j'ai nettoyé le post du haut.

Merci pour le nettoyage ! Je redémarrerai la v2 (et peut-être a7, voyons) demain matin.

Je l'ai redémarré. Il n'y a eu aucune réaction et aucun message. Voir #2020

Veuillez redémarrer a7 et v2.

J'ai redémarré a7. Je n'ai trouvé aucun problème avec la v2, dois-je quand même le redémarrer ?

i7 est maintenant disponible au 192.168.173.96 pouvez-vous s'il vous plaît créer un pont via a7 vers celui-ci ?

Vous devez créer un utilisateur ssh-tunnel-a7-v2 sur la machine ou créer un compte pour moi.

Nous avons ajouté un esclave de construction supplémentaire i7-debian-stretch qui aidera avec les tâches libelektra construction

v2-docker-buildelektra-stretch (offline) car plus aucune tâche de build n'y est planifiée. Le pont ssh sur a7 qui a exposé l'agent a également été désactivé.

Bonjour @ingwinlu ,
comme discuté lors de la dernière réunion, j'aurais besoin du point d'accès.
Pourriez-vous s'il vous plaît m'envoyer les informations par e-mail, mon e-mail est dans AUTHORS.md .
D'ailleurs. n'a pu trouver votre e-mail nulle part, vous devriez peut-être vous ajouter à ce fichier.

Notre serveur de build v2 sera hors ligne jusqu'au 31.07 09:00 car nous y exécutons des benchmarks. Attendez-vous à des temps de construction plus longs.

Désolé pour le dérangement.

//EDIT : temps d'arrêt prolongé de 2 heures

On dirait que l'extension est maintenant également passée. Ce serait bien de récupérer les builds rapides après le déjeuner (vers 13h00). :le sourire:

mm-debian-unstable a été mis à jour et est de nouveau en ligne. Y a-t-il des tâches que nous pouvons réactiver et épingler sur le serveur ?

Il semble que le disque de l'i7 soit plein. Mes tâches échouent avec No space left on device ( Job et Job )

Au fait, j'aime beaucoup la nouvelle interface de construction (dockerization & jenkinsfile). Très utile pour reproduire les erreurs de construction.

Merci d'avoir signalé !

Malheureusement, le redimensionnement nécessiterait un redémarrage (rootfs doit être réduit avant que l'autre ne puisse être étendu) et n'apporterait que 20G. J'ai supprimé les dossiers de construction Jenkins mais ils étaient minuscules, nous sommes donc toujours à 99%.

Donc nettoyer _docker serait plus efficace :
@ingwinlu semble que les deux _docker/overlay2 sont énormes. Une idée de pourquoi toutes ces choses ont été rassemblées là-bas ?

Je force les artefacts docker nettoyés avec docker system prune -fa . Cette
nettoyé environ 190 Go d'espace utilisé dans les images Docker.

Le lundi 13 août 2018 à 07h54, markus2330 [email protected] a écrit :

Merci d'avoir signalé !

Malheureusement, le redimensionnement nécessiterait un redémarrage (rootfs doit être créé
plus petit avant que l'autre ne puisse être étendu) et n'apporterait que 20G. je
supprimé les dossiers de construction Jenkins mais ils étaient minuscules, nous en sommes donc toujours à
99%.

Donc nettoyer _docker serait plus efficace :
@ingwinlu https://github.com/ingwinlu semble être à la fois _docker/overlay2
est énorme. Une idée de pourquoi toutes ces choses ont été rassemblées là-bas ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

Merci!

Pouvons-nous mettre cela dans libelektra-daily ou dans un cronjob?

Daily fait quelque chose de similaire mais moins agressif. Faudra en prendre un autre
regarde quand je suis de retour à Vienne.

markus2330 [email protected] schrieb am Mo., 13. août 2018, 09:22:

Merci!

Pouvons-nous mettre cela dans libelektra-daily ou dans un cronjob?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Comme vous l'avez peut-être remarqué, le serveur de construction était en panne le matin (peut-être la nuit). Le bloc d'alimentation a été endommagé et est maintenant remplacé.

De plus, a7 ou v2 pourraient être mis hors ligne pour les benchmarks pour de courtes durées au cours de la semaine prochaine. Vous verrez le message hors ligne "benchmark" si Anton démarre les benchmarks. Si l'ordinateur reste hors ligne trop longtemps (par exemple plus d'un jour), veuillez nous contacter. (Ensuite, il a peut-être été oublié de le remettre en ligne.)

Résolution d'un problème avec notre image sid.

testkdb_allplugins segfault dans notre image sid lors des tests debian-unstable-full-clang mais uniquement lorsqu'il est exécuté sur v2. J'ai mis à jour manuellement l'image pour utiliser les derniers packages disponibles et l'ai poussée dans notre registre.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ est passé, mais gardera un œil dessus.

Le problème a été mentionné dans les #2216 et #2215 ( @mpranj @sanssecours).

J'ai mis en place un accès public à notre registre des dockers. Voir ici pour une documentation sur la façon d'y accéder.

Faites-moi savoir si quelque chose ne fonctionne pas comme prévu.

//EDIT il semble que le push ne fonctionne pas même si la connexion réussit.
// L'accès public à EDIT2 est à nouveau désactivé. https://github.com/moby/moby/issues/18569. fonctionnalité restaurée pour construire le système
//EDIT3: le repo public est à nouveau disponible sur hub-public.libelektra.org

Anton veut remplacer la carte mère de l'ordinateur où l'hyper-threading est désactivé mardi ou mercredi prochain (on peut choisir). Est-ce que quelqu'un a besoin du buildserver un de ces deux jours ?

J'ai redémarré le registre Docker et exécuté un nettoyage manuellement. J'espère que cela a résolu tous les problèmes de construction avec l'image du site Web.

@ingwinlu merci pour les travaux d'entretien !

Malheureusement, l'étape WebUI échoue de manière assez fiable, par exemple 321 ou 320 (échec encore plus tôt mais également lors de l'extraction de WebUI ?).

Je suis de plus en plus convaincu que l'annulation des jobs sur master est une mauvaise idée. Nous n'avons pratiquement pas de builds réussies sur master car les builds sont soit annulés, soit échouent en raison de problèmes de réseau. Dans l' historique des commits, il est difficile de dire ce qui s'est passé car dans les deux cas, ils sont simplement affichés comme un échec.

Comme solution de contournement, j'ai désactivé les étapes non fiables dans c3b59ecef95287ffc33b094b37e03d0ec6b5710f mais j'espère que nous pourrons les réactiver bientôt !

a7-debian-stretch toujours être hors ligne pour les benchmarks ? (hors ligne depuis le 21 février 2019 10:47:56)

Merci d'avoir signalé ! On dirait qu'Anton a oublié de réactiver. J'ai réactivé le nœud et j'ai également supprimé les anciens nœuds (sauf mm car ils sont toujours en cours d'exécution).

Il y avait un temps d'arrêt de notre serveur le matin. Tout fonctionne à nouveau mais nous avons reçu une offre selon laquelle ils échangeraient le matériel. Nous aurons donc très probablement un autre temps d'arrêt d'environ une heure aujourd'hui.

Le serveur est de nouveau opérationnel. Malheureusement, nous avons le même matériel. Si quelqu'un a le temps pour l'installation/configuration, nous pouvons mettre à niveau le matériel.

On dirait que les versions de Jenkins sont assez lentes (plusieurs heures pour une version complète). Pour autant que je sache, seuls a7-debian-stretch et i7-debian exécutent des tests, tandis que tous les autres nœuds sont inactifs. Est-ce un comportement attendu ?

Merci d'avoir signalé ce problème!

Non, ce n'est pas un comportement attendu. Il semble que la v2 soit en panne. Je vais le redémarrer dès que possible.

v2 devrait maintenant être à nouveau en place

La v2 est en panne et je crains que cela ne le reste jusqu'à lundi. Les builds seront très lents jusque-là.

La v2 est à nouveau disponible avec une nouvelle carte mère

Je vais mettre à niveau les 3 agents de construction (i7, v2, a7, dans cet ordre) vers Buster pour éviter # 2852

Je vais essayer de garder le temps d'arrêt aussi minime que possible. Les tâches de build peuvent échouer, veuillez les redémarrer (une fois les agents redémarrés).

i7-debian-buster, l'ancien i7-debian-stretch est à nouveau en ligne

la v2 est la suivante

v2-debian-buster et a7-debian buster sont également à nouveau en ligne

J'ai redémarré la précédente tâche de build réussie sur master pour voir si tout fonctionne à nouveau :
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

De plus, j'ai ajouté le PR https://github.com/ElektraInitiative/libelektra/pull/2876 pour permettre les travaux de construction de buster.

v2 semble être en panne (la connexion ssh échoue également), malheureusement je ne suis pas à Vienne. J'espère que notre administrateur système le corrigera demain.

a7 est maintenant également en panne et avec lui i7 (qui est connecté via un pont sur a7).

Donc, actuellement, aucune compilation ne peut être effectuée. J'ai contacté l'administrateur.

Tous les serveurs sont à nouveau opérationnels. Veuillez redémarrer les versions en poussant de nouveaux commits ou en écrivant "jenkins build libelektra s'il vous plaît" comme commentaire à votre PR.

Note technique : a7 est tombé en panne à cause d'un "blocage logiciel du bug watchdog". J'ai essayé d'ajouter "nomodeset nmi_watchdog=0". Espérons qu'ils ne soient pas à nouveau aussi instables qu'ils l'ont déjà été.

a7 (ainsi que v2 et i7 car ils sont connectés via un pont sur a7) sont en panne. J'ai contacté notre administrateur. Veuillez essayer d'éviter de démarrer les builds maintenant, car cela ne fera qu'une longue file d'attente.

a7 est de retour en ligne (c'était déjà hier), la v2 n'a pas été affectée

Selon la page d'état du serveur de build, les serveurs :

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

sont en baisse. Le répertoire de données Jenkins semble également être assez plein. Et pendant que nous y sommes : ce serait génial, si nous pouvions mettre à jour Jenkins et ses plugins. Je suis intéressé à résoudre ces problèmes. Il y a quand même deux problèmes.

1. Je n'ai pas beaucoup (ou vraiment aucune) d'expérience dans l'administration de serveurs.
2. J'aurais probablement besoin d'un accès physique aux machines, car elles semblent assez instables.

a7 est un pont vers i7 et v2, donc avec a7 en panne, nous ne connaissons pas i7 et v2.

L'accès ne pose aucun problème, je peux vous le donner. Mais vous devez savoir que la mise à niveau de Jenkins est une opération importante car elle nécessite généralement de reconfigurer Jenkins (selon les notes de version, qui sont nombreuses car nous n'avons pas mis à jour depuis un certain temps) et de corriger le fichier Jenkins (selon les modifications de l'API des plugins ). Envoyez-moi un email si vous voulez y accéder.

a7 (et tous les autres) sont à nouveau en place.

a7 est à nouveau en panne, j'ai contacté l'administrateur.

Note technique : a7 est tombé en panne à cause d'un "blocage logiciel du bug watchdog".

Une recherche rapide suggère que cela pourrait être un problème de BIOS. Quelqu'un a-t-il vérifié si des mises à jour du BIOS sont disponibles ?

a7 est un pont vers i7 et v2, donc avec a7 en panne, nous ne connaissons pas i7 et v2.

Cela semble être une mauvaise conception. N'y a-t-il aucun moyen de contourner cela?

Une recherche rapide suggère que cela pourrait être un problème de BIOS. Quelqu'un a-t-il vérifié si des mises à jour du BIOS sont disponibles ?

Nous avons installé un nouveau BIOS, remplacé le processeur et mis à niveau le noyau (voir les messages ci-dessus). Le système était stable depuis lors. Maintenant, après la mise à niveau vers Debian buster, il est à nouveau instable.

Néanmoins, j'ai demandé à l'administrateur s'il y avait un nouveau BIOS disponible.

Cela semble être une mauvaise conception. N'y a-t-il aucun moyen de contourner cela?

i7 et v2 sont dans un réseau privé car il n'y a pas assez d'adresses IPv4. J'ai demandé à notre administrateur si une configuration IPv6 serait possible.

J'ai demandé à notre administrateur si une configuration IPv6 serait possible.

Nous n'avons pas vraiment besoin d'IPv6, il suffirait d'utiliser un autre serveur plus stable comme pont.

Très probablement, la v2 est aussi instable que a7 (il n'y a eu qu'un seul plantage mais cela ne dit pas grand-chose car immédiatement quand a7 meurt, il prend la charge de la v2). Nous pourrions utiliser i7 comme pont. Mais si v2 et a7 tombent en panne, i7 n'est pas non plus très utile, il faudrait plusieurs heures pour terminer un travail de build. De plus, i7 n'a pas assez d'espace pour le registre Docker.

Ce changement demanderait donc beaucoup d'efforts avec peu de gain.

Résoudre le problème réel de a7 et v2 est beaucoup plus prometteur.

De plus, i7 n'a pas assez d'espace pour le registre Docker.

Dans ce cas, la seule solution est de corriger a7.

Malheureusement a7 est à nouveau en panne :cry:

J'ai essayé de démarrer avec l'ancien noyau mais cela n'a pas aidé.

Pour le BIOS, d'autres versions sont disponibles, mais selon leurs notes de version, il y a peu d'espoir qu'ils résolvent ce problème et il n'y a aucun moyen de rétrograder à nouveau si cela s'aggravait...

Le BIOS pour a7 est actuellement mis à niveau. De plus, nous essaierons d'utiliser un noyau plus récent à partir des rétroportages.

a7, espérons-le, sera bientôt de retour.

Le nouveau BIOS n'a pas aidé, maintenant a7 s'est écrasé en quelques minutes.

a7 est à nouveau en panne, j'ai contacté l'administrateur. Le noyau le plus récent des backports sera essayé lors du prochain redémarrage.

a7 est de nouveau disponible avec le noyau 5.2

Je pense qu'il a encore planté...

Avons-nous toujours les mêmes messages d'erreur ou y a-t-il au moins un changement ?

Oui, a7 à nouveau en panne, j'ai signalé à l'administrateur. Il nous parlera des messages au redémarrage.

Quelqu'un a-t-il une autre idée ? (Nous avons déjà mis à niveau le BIOS et le noyau.)

Certaines sources suggèrent des problèmes avec le nouveau pilote graphique et que nous devrions essayer nouveau.modeset=0 (d'une certaine manière c'est différent de nomodeset ). La désactivation des "états C" dans le BIOS a également été suggérée.

Oui, a7 à nouveau en panne, j'ai signalé à l'administrateur. Il nous parlera des messages au redémarrage.

Quelqu'un a-t-il une autre idée ? (Nous avons déjà mis à niveau le BIOS et le noyau.)

peut-être désactiver a7 en tant qu'esclave jenkins pour déterminer si cela ne se produit que lorsque la charge «réelle» est sur la machine.

@ingwinlu merci, bonne idée. J'ai réduit maintenant à un travail de construction un a7 (c'était 2). Pour le week-end (une fois que l'administrateur aura quitté le bureau), je désactiverai alors complètement l'agent.

@kodebach : merci, je vais transmettre l'information à l'admin.

Existe-t-il un calendrier pour le moment où a7 sera à nouveau disponible ?

a7 est à nouveau opérationnel, avec l'hyperthreading désactivé et une seule tâche de build simultanée.

Nous pourrions également alléger une partie de la charge de a7, en déplaçant les versions alpine et ubuntu-xenial vers Cirrus. Les deux sont de simples exécutions de « construction et de test ». Ils ne font rien de spécial comme rapporter la couverture.

Cirrus permet 8 builds Linux simultanées par utilisateur . Actuellement, la version linkchecker est la seule version Linux sur Cirrus.

En fait, ubuntu-xenial est un peu redondant, puisque nos versions Travis fonctionnent sur Ubuntu Xenial.

Merci pour les conseils, mais nous ne prévoyons pas de décharger les versions Linux de Jenkins. Au contraire, @Mis Treated travaillera sur l'amélioration de notre infrastructure Jenkins pour qu'elle soit encore plus à jour et utile (par exemple en construisant plus de packages). Les avantages de nos Jenkins sont :

1. nous l'avons entièrement sous notre contrôle
2. nous pouvons facilement le faire évoluer (seul Java + Docker est requis sur les agents de construction)
3. le Jenkinsfile est très soigné et (pour la plupart) assez facilement extensible

Mais bien sûr, tout le monde est invité à étendre également Cirrus (ou tout autre système de build supplémentaire qui est offert gratuitement, voir #1540).

Il s'agissait simplement d'une solution temporaire, pour contrer la désactivation de l'hyperthreading et la limitation à 1 travail simultané sur a7.

a7 ne construit qu'une petite partie (environ 2/5), donc la réduction de moitié devrait être à peine perceptible. Ou y a-t-il des problèmes spécifiques maintenant? (Pour le moment, bien sûr, il faut du temps pour rattraper les nombreux travaux après les temps d'arrêt.)

a7 ne construit qu'une petite partie (environ 2/5)

2/5 c'est 40 %. Je ne considérerais pas cela comme une petite partie.

Ou y a-t-il des problèmes spécifiques maintenant?

Non, en fait, il semble fonctionner mieux qu'avant.

Désolé, je voulais dire environ 2/6 (1/6 est i7, 3/6 est v2). Et cette partie n'est pas supprimée mais seulement réduite.

Non, en fait, il semble fonctionner mieux qu'avant.

Parfait!

On dirait que a7 est à nouveau en panne .

Merci! Je l'ai signalé.

À l'avenir, il serait excellent que celui qui détecte le premier puisse le signaler directement à

herbert à complang.tuwien.ac.at

Il suffit de dire que "a7 ist leider nicht erreichbar".

Et puis signalez-le également ici, afin qu'Herbert ne reçoive pas plusieurs e-mails.

Il existe sûrement un moyen de faire en sorte que le serveur maître Jenkins envoie automatiquement un tel e-mail et peut-être également le publier sur ce problème GitHub. Ce serait très bizarre, s'il n'y avait pas de plugin Jenkins pour une tâche aussi simple...

Oui, il existe https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin mais je ne suis pas sûr qu'il fasse exactement ce que nous voulons. Il peut également envoyer des e-mails lorsque quelqu'un repousse l'agent exprès. Et un e-mail personnel est beaucoup plus susceptible d'être traité par l'administrateur plus rapidement.

Si nous automatisons quelque chose, alors directement le redémarrage des PC s'ils sont inaccessibles (peut-être qu'ils ont même une sorte de chien de garde intégré ?)

a7 a été redémarré et le "contrôle global C-State" désactivé.

Il n'est cependant pas en ligne en tant qu'agent de construction.

Voyons s'il plante aussi sans charge. v2 et i7 fonctionnent à nouveau.

L'administrateur (Herbert) n'est pas disponible demain, je laisse donc a7 en tant qu'agent de construction pour le moment.

Mon plan (s'il n'y a pas de protestations ou de plantages a7 avant) est d'activer a7 en tant qu'agent de construction demain. Si a7 plante à nouveau, Herbert peut redémarrer a7 vendredi. Est-ce correct?

Si la file d'attente n'est pas trop longue, je pense que nous devrions garder l'agent de construction sur a7 désactivé un peu plus longtemps. Le dernier crash s'est produit après 3 jours. Si nous l'avons activé demain, nous ne saurons pas si l'agent de build a causé le plantage ou non, à moins qu'il ne plante avant.

Ok, alors voyons à quoi ressemble la taille de la file d'attente.

J'espère que le "contrôle global C-State" résoudra enfin le problème et je pense que nous avons besoin d'une charge élevée pour le tester.

La file d'attente était très longue et les versions principales étaient toutes suspendues car elles avaient besoin d'a7 pour le déploiement du site Web.

J'ai donc recommencé l'agent a7.

Certaines des tâches de build Jenkins récentes ont été annulées en raison d'un espace disque manquant sur le serveur de build principal. J'ai libéré de l'espace en supprimant les journaux des anciens travaux de construction. Veuillez noter que j'ai peut-être également supprimé certains fichiers journaux de nouvelles tâches de construction. Dans certains cas, la version Jenkins de votre dernier commit peut avoir échoué et vous ne voyez maintenant qu'un message à propos d'une erreur 404. Dans ce cas, s'il vous plaît juste soit

• utilisez jenkins build libelektra please dans un commentaire sous le PR pour redémarrer la version Jenkins, ou
• réécrivez le dernier commit sans modifications (par exemple en utilisant git commit --amend ) et forcez le push

. Désolé pour le dérangement.

Merci de l'entretenir !

J'ai marqué le nœud v2-debian-buster comme temporairement hors ligne , car il ne semble pas fonctionner correctement. Pour plus d'informations, veuillez consulter le numéro 2995 (et le numéro 2994).

Merci d'avoir cherché l'infrastructure !

v2 manquait d'espace disque. J'ai exécuté docker system prune Espace total récupéré : 58,37 Go

Ensuite, j'ai redémarré la v2 et reconnecté l'agent.

J'ai maintenant exécuté du -h | sort -h pour trouver d'autres fichiers à supprimer.

J'ai recommencé la v2 avec une nouvelle version de Docker. Veuillez signaler les builds cassés immédiatement.

J'ai réinstallé docker, purgé toutes les configurations et supprimé /var/lib/docker. Espérons que cela le résout.

La v2 sera à nouveau incluse. Veuillez signaler immédiatement les versions cassées.

Comme suggéré ici, j'ai maintenant exécuté

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

et j'ai aussi redémarré i7 (il y avait beaucoup d'interfaces réseau docker, elles sont parties maintenant)

docker-ce est maintenant partout 5:19.03.1~3-0~debian-buster

Veuillez signaler les builds cassés immédiatement.

On dirait que la construction de master nouveau échoué à cause de problèmes de connexion à v2-debian-buster (voir aussi le problème #2995).

J'ai demandé à notre administrateur de regarder le basculement entre a7/v2/i7. J'ai désactivé v2 et i7 pour l'instant.

J'ai redémarré libelektra/master et libelektra-daily.

Nous avons changé les ports pour les 3 PC.

Ensuite, j'ai supprimé jenkins homedir sur v2/i7 et redémarré l'agent v2/i7.

Il semble qu'il n'y ait plus d'espace disponible sur v2-debian-buster :

ApplyLayer exit status 1 stdout : stderr : write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o : aucun espace restant sur l'appareil

.

Merci pour le signalement, j'ai fait (beaucoup) plus de place sur la v2.

Supprimer le travail terminé :

Taille du système de fichiers utilisée % d'utilisation de la disponibilité Monté sur
/dev/sda3 417G 227G 164G 58% /

buildserver est en panne en raison de la migration (afin que nous obtenions un état cohérent dans la sauvegarde du nouveau buildserver)

https://build.libelektra.org/jenkins/ recommence

La charge sur le serveur de build était de 200 en raison d'erreurs de noyau lors d'une sauvegarde, le serveur ne réagissait plus et devait être réinitialisé.

Les messages de journal étaient (exemples) :

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

Espérons que nous pourrons migrer bientôt au début de la semaine prochaine ( @Mis Treated ?)

Le serveur effectue actuellement une resynchronisation du raid, alors attendez-vous à ce qu'il soit très lent.

Les builds Jenkins ne sont plus exécutés, voir #3035

Jenkins recommençait maintenant. Veuillez répéter les tâches de build Jenkins.

On dirait que v2-debian-buster est hors ligne :

Ouverture de la connexion SSH à a7.complang.tuwien.ac.at:22221.
Connexion refusée (Connexion refusée)

.

Merci, j'ai contacté notre administrateur mais j'ai peur qu'il soit déjà absent.

Herbert a déjà redémarré la v2 hier. Il a désactivé le "multithreading simultané".

Si un serveur (v2, i7, a7) plante à nouveau, veuillez également contacter directement notre administrateur via "herbert at complang.tuwien.ac.at". Veuillez également signaler ici, pour éviter plusieurs e-mails.

Je pense qu'il y a quelque chose qui ne va pas avec le référentiel Git pour la branche master sur v2-debian-buster :

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

. J'ai déjà redémarré le build trois fois, mais Jenkins échoue toujours avec la même erreur.

Malheureusement, la v2 a btrfs qui semble parfois corrompre les fichiers. Un problème similaire que nous avons déjà eu avec un échec de docker pull . Dans le cas actuel, le fichier 0bc3ca6fcbc610abd845aeff5f666938d24117 semble être corrompu. Lors de l'exécution de md5sum sur les occurrences de ce fichier, j'obtiens :

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

J'ai maintenant supprimé tout le répertoire pour master et redémarré le build. Voir aussi #3054

Comme je ne suis pas disponible pendant quelques jours, veuillez contacter "herbert at complang.tuwien.ac.at" sur les problèmes concernant les a7/i7/v2 inaccessibles. @Mis Treated sera responsable de tout ce qui n'est pas lié au redémarrage des serveurs. (J'espère que nous aurons bientôt un nouvel agent de construction.)

Veuillez également toujours signaler ici, pour éviter plusieurs e-mails et pour que tout le monde ait une bonne vue d'ensemble de ce qui se passe.

Le serveur de build a-t-il actuellement un dysfonctionnement ?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

Le serveur de build a-t-il actuellement un dysfonctionnement ?

Il semble que le serveur de construction principal de Jenkins soit incapable de se connecter i7 . J'ai marqué le nœud comme temporairement hors ligne.

La compilation échoue dans des cas arbitraires :
Ici, il a été interrompu sans aucune raison
Ici, un cas de test échoue qui n'est pas lié à mon PR (je viens d'ajouter une décision de conception sans toucher à aucun code)

Ici, il a été interrompu sans aucune raison

J'ai le même code d'interruption 143 pour deux PR et je ne peux pas encore les expliquer. J'ai redémarré le build et j'espère que cela fonctionne maintenant.

Ici, un cas de test échoue qui n'est pas lié à mes relations publiques

Cela devrait être corrigé grâce à @sanssecours avec #3103. Veuillez rebaser sur master.

Le nouveau nœud Jenkins hetzner-jenkins1 ne semble pas fonctionner correctement . J'ai marqué le nœud comme temporairement hors ligne.

J'ai mis à niveau Docker sur i7 et redémarré la machine. J'espère que cela résoudra le problème. L'agent est à nouveau en ligne. Veuillez signaler les problèmes ici (et/ou désactiver l'agent).

Actuellement, un travail de #3065 est en cours d'exécution sur i7.

@ Maltraité pouvez-vous déboguer hetzner-jenkins1 s'il vous plaît ?

Existe-t-il une possibilité de désactiver facilement une vérification de lien pendant un certain temps ?

Cela a duré toute la journée :

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

D'autres PR (plus récemment #3115, #3113) sont également concernés. Selon downforeveryoneorjustme, les liens ne sont pas vraiment disponibles.

MISE À JOUR : Le site Web est toujours hors ligne. J'ai fait un PR pour ce #3117.

Existe-t-il une possibilité de désactiver facilement une vérification de lien pendant un certain temps ?

Vous pouvez désactiver des liens individuels en les ajoutant à tests/linkchecker.whitelist (comme vous l'avez déjà découvert)

Je ne peux pas réexécuter les builds ayant échoué à partir de Cirrus. Voir https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

Le bouton ne fait rien. Existe-t-il un tour de magie pour le faire fonctionner ?

edit: soit quelqu'un a changé quelque chose, soit le x`ème essai a finalement fonctionné. La construction est à nouveau en cours d'exécution ! :)

On dirait que l'agent de build a7-debian-buster n'est pas en mesure de se relancer :

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

.

edit: soit quelqu'un a changé quelque chose, soit le x`ème essai a finalement fonctionné. La construction est à nouveau en cours d'exécution ! :)

Après avoir vu votre commentaire, j'ai également appuyé sur le bouton « Restart Failed Build Jobs ». Pour autant que je sache, appuyer sur le bouton a effectivement redémarré les tâches de génération défaillantes.

Après avoir vu votre commentaire, j'ai également appuyé sur le bouton « Restart Failed Build Jobs ». Pour autant que je sache, appuyer sur le bouton a effectivement redémarré les tâches de génération défaillantes.

Cela n'a pas fonctionné pour moi cependant, je fournirai un gif la prochaine fois!

Je vais redémarrer le serveur de build et ses nœuds. Les tâches de build n°3121 et n°3099 doivent être redémarrées car elles avaient des tâches sur des agents morts.

Cela n'a pas fonctionné pour moi cependant, je fournirai un gif la prochaine fois!

Vous n'avez pas besoin de fournir un GIF, puisque je vous crois déjà 😊.

On dirait que jenkins a du mal à s'arrêter, j'attends un peu avant de forcer la suppression de tous les processus Java.

J'ai également mis à niveau Docker sur tous les agents (sur i7, il était déjà mis à niveau).

Jenkins est à nouveau en hausse avec l'intervalle de pulsation comme suggéré dans #2984. Tous les nœuds sont connectés.

Veuillez redémarrer tous les travaux si nécessaire et signaler tout problème ici.

v2 est en panne, j'ai demandé à notre administrateur de redémarrer.

J'ai réactivé la v2, car elle semble être opérationnelle et notre arriéré de construction est suffisamment dimensionné.

Y a-t-il à nouveau un problème avec la compilation ( hetzner-jenkins1 ) ?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

Y a-t-il à nouveau un problème avec la compilation ( hetzner-jenkins1 ) ?

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

Il vient de dépasser le quota de disque, je ne voulais pas le surcharger avec de la mémoire. Je l'ai nettoyé maintenant. C'est à nouveau.

Nœud mis à jour.

J'ai augmenté hetzner-jenkins1 à 4 versions parallèles. Ce n'est qu'une mesure temporaire tant que rien d'autre n'y circule.

J'ai temporairement réduit le nombre d'exécuteurs sur hetzner-jenkins1 de 4 à 2, car la suite de tests expire. Je pense que cela se produit lorsque trop de travaux sont en cours de compilation pendant l'exécution des tests. Nous pourrions avoir besoin de limiter les ressources disponibles à un seul conteneur et cela n'interfère pas trop avec les autres tâches.

N'hésitez pas à le corriger si vous pensez que ce n'était pas la bonne approche.

EDIT: diminué à 1 car les tests expirent toujours et la reconstruction constante gaspille encore plus de ressources.

@mpranj Merci de l'avoir

@maltraité n'avez-vous peut-être attribué qu'un seul processeur ou similaire ? Pouvez-vous en attribuer plus et augmenter le nombre d'exécuteurs testamentaires ? Le matériel devrait être plus solide que la v2.

J'ai désactivé i7-debian-buster car il n'y a plus d'espace disque, ce qui entraîne l'échec de toutes les versions. Si quelqu'un a accès, veuillez nettoyer quelque chose et le réactiver.

@mpranj merci pour la désactivation !

Désolé, où je suis actuellement, ssh est bloqué (certains pare-feu d'application, ssh sur d'autres ports ne fonctionnent pas non plus). Je ne peux donc pas donner accès ou faire de nettoyage maintenant.

Comme i7 est le plus faible des agents, ce n'est peut-être pas grave de toute façon.

@Maltraité, n'avez-vous peut-être attribué qu'un seul processeur ou similaire ? Pouvez-vous en attribuer plus et augmenter le nombre d'exécuteurs testamentaires ? Le matériel devrait être plus solide que la v2.

Je n'ai aucune idée de la force de la v2.
Actuellement, jenkins1 utilise 4 CPU avec 8 mémoires et 16 swaps. Je peux l'augmenter facilement, je ne sais pas à quel point vous voulez que je l'augmente.

Une note pour les futures décisions matérielles : phoronix semble faire des tests de compilation dans ses articles sur le processeur (par exemple, Ryzen 7 3700X, test Ryzen 9 3900X, vers la fin de l'article ).

On dirait que hetzner a récemment ajouté AMD Ryzen 7 3700X à ses serveurs basés sur AMD.

Je n'ai aucune idée de la force de la v2.

@ingwinlu a écrit à ce sujet dans sa thèse (à trouver dans abgaben repo lukas_winkler)

Actuellement, jenkins1 utilise 4 CPU avec 8 mémoires et 16 swaps. Je peux l'augmenter facilement, je ne sais pas à quel point vous voulez que je l'augmente.

Tant que rien d'autre n'est exécuté sur le serveur, vous pouvez allouer toutes les ressources. Plus tard, nous pouvons encore descendre (lorsque nous déplaçons Jenkins).

J'ai mis à jour le hetzner-jenkins1.
L'erreur avec le frontend où il manque de mémoire est corrigée.
Maintenant, il exécute 2 versions parallèles.

On dirait qu'il n'y a plus d'espace sur v2-debian-buster :

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

.

Merci, je l'ai également marqué hors ligne, jusqu'à ce que quelqu'un ait accès pour le nettoyer.

hetzner-jenkins1 vient d'échouer mes 3 PR car le quota de disque est dépassé. Voici en sortie :

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

Marqué hetzner-jenkins1 comme hors ligne car le quota de disque a été dépassé.

J'ai nettoyé i7 et v2 (en supprimant /home/jenkins/workspace/* et en exécutant docker system prune ). Maintenant nous avons:

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

Ensuite, j'ai redémarré les agents.

@Maltraité pouvez-vous s'il vous plaît corriger #3160 afin que cela ne se reproduise pas si vite. Veuillez également corriger hetzner-jenkins1. Il y a beaucoup de ressources sur cette machine, il n'est vraiment pas nécessaire qu'elle atteigne une limite de ressources tous les jours.

Je ne sais pas s'il existe un bon moyen de redimensionner le disque vers le bas. C'est pourquoi je ne donne pas tout au nœud à la fois .. hetzner est à nouveau opérationnel.

la v2 manquait encore d'espace, j'ai nettoyé : /dev/sda3 417G 315G 102G 76% /

@Maltraité https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log ne démarre pas

Je pense que le système de construction est actuellement complètement bloqué, les PR ne sont pas construits.

Merci pour le signalement, je vais redémarrer Jenkins et nettoyer certains fichiers car le disque est plein.

@Maltraité https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log ne démarre pas

Agent connecté avec succès et en ligne

Je suppose que tout va bien maintenant avec hetnzer-jenkins1?

Merci beaucoup! On dirait que Jenkins ne réagit toujours pas aux builds. v2 et i7 échouent désormais tous les deux avec : java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins est à nouveau opérationnel, veuillez redémarrer les travaux.

java.io.IOException : impossible de copier slave.jar dans '/home/jenkins' sur slave.

fixe (était également à court d'espace)

@Maltraité s'il vous plaît

@Mis Treated "jenkins build libelektra please" est toujours cassé, est-ce lié aux changements des webhooks ?

Essayez peut-être aujourd'hui de passer au nouveau Jenkins, mais si vous n'y parvenez pas, veuillez faire fonctionner à nouveau l'ancienne instance !

J'ai déclenché une analyse du référentiel, maintenant le "jenkins build libelektra s'il vous plaît" semble fonctionner à nouveau.

On dirait que le disque est plein pour v2-debian-buster

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

Malheureusement. J'ai marqué v2 comme hors ligne jusqu'à ce qu'il soit résolu.

Merci d'avoir signalé !

@mpranj je vous ai donné l'accès, pouvez-vous essayer de nettoyer s'il vous plaît ?

Merci! Il me semble qu'il y a une abondance de ressources gaspillées par de vieilles images de docker qui traînent. De plus, il semble que btrfs + docker soient bogués. Docker crée des sous-volumes btrfs pour chaque conteneur et ne les nettoie pas correctement par la suite. La commande docker system prune -f ne libère pas non plus d'espace.

J'ai pris v2 et a7 pour la maintenance afin de libérer les ressources et d'équilibrer les btrfs.

la connexion au docker a échoué

Construisez des images docker impossibles à extraire. Quelque chose se passe avec docker hub?

Oui, désolé, avec a7 j'ai aussi démonté le hub docker. Je posterai un message ici quand il sera de nouveau disponible.

a7 y compris docker hub, est à nouveau opérationnel. J'ai laissé v2 hors ligne car il ne peut pas se connecter au hub pour extraire des images ?!? Je ne sais pas ce qui ne va pas là-bas, je n'ai modifié aucune information d'identification et les autres nœuds peuvent se connecter. Des idées?

Btrfs s'équilibre toujours en arrière-plan, a7 peut être plus lent pendant une heure environ.

@mpranj merci d'avoir

Malheureusement, je ne connais pas les identifiants, j'espère que @ingwinlu pourra nous aider.

Les commandes que j'ai utilisées pour rééquilibrer étaient :

Correction d'un bug peut-être avec btrfs :

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

Rééquilibrer le fs vraiment, cela prend beaucoup de temps. Le paramètre d'utilisation peut/doit être ajusté, voici ce qui a fonctionné aujourd'hui :

btrfs balance start -dusage=80 /

Les informations d'identification peuvent être modifiées facilement, mais nous devrons nous connecter à tous les agents jenkins qui se connectent à nouveau au docker hub avec les nouvelles informations d'identification.

Le plus gros problème était que certains conteneurs docker fonctionnaient toujours et que le prunage du système docker ne faisait pas grand-chose. Par conséquent, j'ai démonté les agents et j'ai tout libéré pendant qu'il était en panne. Il y avait des TONNES de conteneurs qui traînaient.

Oui, malheureusement les conteneurs sont rapidement recréés. J'espère que @Mis Treated pourra docker system prune ).

J'ai également fait de la criminalistique numérique assez complexe et j'ai volé les informations d'identification du hub. :en riant:

v2 est de nouveau opérationnel.

Merci beaucoup! :100: Veuillez nous envoyer les informations d'identification.

Envoyé. Btw, je pense que a7 est probablement lent uniquement à cause de la faible vitesse du disque, mais il est bon qu'il dispose de suffisamment d'espace pour le hub docker. On dirait que la plupart du temps, le processeur ne fait rien là-bas.

Une autre réflexion : peut-être pouvons-nous effectuer les tâches de nettoyage critiques en plus par tâche cron pour éviter des situations comme celles que nous avons eues maintenant.

Veuillez nous envoyer les informations d'identification.

@mpranj Je pense que j'étais dans ce groupe de "nous". Je n'étais pas dans un CC ou quelque chose comme ça?

@Maltraité désolé, je l'ai envoyé à markus et je n'ai pas eu votre e-mail. Sur a7 vous trouverez CREDENTIALS.txt dans votre répertoire d'accueil.

J'ai besoin de hetzner-jenkins1 Node pour tester le nouveau jenkins-server. Je vais l'éteindre sur l'ancien serveur jusqu'à demain matin.

Vous pouvez facilement créer un deuxième hetzner-jenkins2 pour les tests. Si ce n'est que pour cette nuit, ça devrait aller.

Une autre réflexion : peut-être pouvons-nous effectuer les tâches de nettoyage critiques en plus par tâche cron pour éviter des situations comme celles que nous avons eues maintenant.

libelektra-daily effectue ce travail de nettoyage mais il échoue maintenant : #3160. Si vous avez des idées pour améliorer ce travail, n'hésitez pas à nous en faire part.

Je pense que j'étais dans ce groupe de "nous". Je n'étais pas dans un CC ou quelque chose comme ça?

Oui, désolé j'ai oublié de dire à mpranj que "nous" fait référence à vous.

J'espère que c'est ok que je garde hetzner-jenkins1 pendant un petit moment, toutes les versions sont bonnes maintenant, je pense que je peux rendre le serveur complètement opérationnel ce soir.

v2 est inaccessible, j'ai contacté l'administrateur.

J'espère que c'est ok que je garde hetzner-jenkins1 pendant un petit moment, toutes les versions sont bonnes maintenant, je pense que je peux rendre le serveur entièrement opérationnel ce soir.

Ce serait génial !

la v2 est inaccessible, j'ai contacté l'admin.

Merci mais j'ai peur qu'il ne réponde pas avant lundi.

v2 obtient un nouveau noyau (il vient de planter).

i7 sera également redémarré.

Les 3 serveurs (v2, a7, i7) ont maintenant "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 "

Ils sont opérationnels et en ligne, veuillez redémarrer les tâches si nécessaire.

Juste une note:
J'ai à nouveau scanné le repo avec le nouveau serveur. Cela pourrait faire quelques erreurs sur l'ancien..

On dirait que master [1] a également été construit sur le nouveau serveur. Ce n'était pas avec succès. En cliquant sur le statut, une page de connexion apparaît [2]. Veuillez reconfigurer Jenkins pour que tout puisse être consulté sans être connecté.

Espérons que nous pourrons bientôt passer au nouveau Jenkins. Voir les erreurs de deux Jenkins différents ne facilite pas la situation :wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@markus2330 a7 / v2 peut-il être redémarré à distance après une mise à niveau ou y a-t-il des pièges ?

Généralement ça marche mais si ce n'est pas urgent il vaut mieux attendre que l'admin soit là. Je peux redémarrer mardi si cela vous convient ?

Merci! Rien d'urgent, juste une question générale. Cela est arrivé parce que Debian 10.2 vient juste de sortir. Je vais attendre un peu avec les mises à jour.

Vous pouvez néanmoins faire la mise à niveau (uniquement sans redémarrage). Ensuite, en cas de plantage, nous aurons déjà le noyau 10.2 lorsque l'admin appuiera sur le bouton reset :wink:

@mpranj pouvez-vous peut-être ajouter une tâche cron qui purge les anciens instantanés ? Ou n'est-ce pas possible sans arrêter docker ?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ recommande de rééquilibrer également btrnfs dans une tâche cron.

pouvez-vous peut-être ajouter une tâche cron qui purge les anciens instantanés ? Ou n'est-ce pas possible sans arrêter docker ?

Je peux ajouter une tâche cron sans arrêter tous les conteneurs Docker. Cela pourrait ne pas tout nettoyer, mais nous pouvons l'essayer. Comme je l'ai dit, parfois les conteneurs continuent de fonctionner pour toujours/jusqu'à ce que la machine se bloque. Le nettoyage complet nous oblige cependant à désactiver temporairement l'agent de génération, puis nous pouvons forcer l'arrêt de tous les conteneurs.

Je peux aussi ajouter le rééquilibrage en tant que cronjob.

Merci, laissez-nous essayer.

Le maître n'a plus de mémoire. Je voulais exécuter Scan Repository sur l'ancien Jenkins car a7 et i7 obtiennent l'erreur suivante lors de l'extraction des images docker :

la connexion au docker a échoué

J'ai maintenant v2 et hetzner-jenkins1 en cours d'exécution sur le nouveau serveur.

Le maître n'a plus de mémoire.

Merci d'avoir signalé. J'ai supprimé d'anciennes données de couverture et activé à nouveau le nœud maître. Pour tous ceux qui ont des demandes d'extraction ouvertes : veuillez redémarrer vos builds Jenkins avec jenkins build libelektra please . Désolé pour le dérangement.

Dans #3234 @raphi011 a suggéré:

imo, c'est vraiment urgent, la fragilité et la lenteur des tests rendent difficile, voire impossible, toute modification si vous devez attendre aussi longtemps pour les vérifier.

Je suis d'accord c'est vraiment urgent mais @Mis Treated fait déjà ce qu'il peut.

Alors peut-être que nous pouvons utiliser le serveur de build avec plus de parcimonie et ne construire que si nous pensons vraiment que le PR doit être fusionné bientôt. Les builds inutiles doivent être annulés.

Ou qu'en est-il (temporairement) d'arrêter la construction automatique des PR lors de l'envoi de modifications (la construction ne commence donc qu'avec jenkins build libelektra please ) ? @Maltraité, savez-vous comment reconfigurer Jenkins pour le faire (je n'ai pas trouvé l'option) ?

J'ai aussi le sentiment que jenkins build libelektra please ne fonctionne pas pour le moment, du moins cela n'a pas fonctionné pour cette version : https://github.com/ElektraInitiative/libelektra/pull/3073 j'ai dû pousser un commit vide pour démarrer le pipeline.

Cronjob de nettoyage implémenté et noyau de backport mis à niveau sur a7 et v2. Il y a pas mal de changelog pour le noyau, il sera actif au prochain redémarrage.

Merci beaucoup! L'"ancien" noyau de backport est-il toujours installé afin que nous ayons une solution de secours s'il ne démarre pas ?

Oui, il peut être supprimé après un démarrage réussi dans le nouveau noyau.

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

J'ai désactivé i7 pour un nettoyage manuel, une mise à niveau du noyau et du docker. Quelqu'un a activé i7 pendant que je travaillais dessus. Tout est de nouveau opérationnel.

@Piankero J'ai redémarré votre build maintenant.

J'ai aussi le sentiment que jenkins build libelektra please ne fonctionne pas pour le moment, du moins cela n'a pas fonctionné pour cette version : #3073 j'ai dû pousser un commit vide pour démarrer le pipeline.

fonctionne maintenant

@Maltraité, savez-vous comment reconfigurer Jenkins pour le faire (je n'ai pas trouvé l'option) ?

J'ai ajouté ce qui suit à la configuration Jenkins :

Supprimer le déclenchement automatique du SCM

Note à tous : l'utilisation de "jenkins build libelektra please" est désormais obligatoire, les tâches de build ne démarrent pas simplement en poussant. Nous informerons ici, lorsque nous rétablirons ce paramètre.

@Maltraité merci ! Voyons si cela suffit. J'espère que les push to master déclenchent toujours les builds master ?

Avoir le nœud hetzner serait néanmoins très bien. Y a-t-il des problèmes si le nœud est utilisé par deux serveurs de build en même temps ? Ou si c'est un problème : n'est-il pas très facile de simplement cloner le CT ?

@Maltraité merci ! Voyons si cela suffit. J'espère que les push to master déclenchent toujours les builds master ?

master branche est désormais une exception à la règle suivante :

Supprimer le déclenchement automatique du SCM

Pour ce qui est de

Avoir le nœud hetzner serait néanmoins très bien. Y a-t-il des problèmes si le nœud est utilisé par deux serveurs de build en même temps ? Ou si c'est un problème : n'est-il pas très facile de simplement cloner le CT ?

J'ai ajouté un nouveau CT (hetzner-jenkinsNode3).

impossible de cloner le repo : https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

peut-être que cela a quelque chose à voir avec le nouveau nœud? (conjecture folle)

peut-être que cela a quelque chose à voir avec le nouveau nœud? (conjecture folle)

cette erreur est sur a7

cette erreur est sur a7

tellement .. réessayer ?

tellement .. réessayer ?

oui, je ne pense pas que cela se reproduira..

Je vais le refaire pour vous.

@Mis Treated Je pense que nous pouvons recommencer les builds automatiques. Mais s'il vous plaît, regardez d'abord #3160.

une idée pourquoi cela échouerait?

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

une idée pourquoi cela échouerait?

On dirait que c'était un problème temporaire, l'URL est actuellement accessible depuis les agents de construction.

À long terme, ce serait bien de configurer ce type de dépendances dans les images Docker, pour éviter de les télécharger à plusieurs reprises pour chaque build. Cela devrait également empêcher les échecs de construction dus à des packages temporairement indisponibles comme vous l'avez mentionné ci-dessus.

Eh bien.. jenkins build libelektra please le troisième

Oui, nous avons toutes les dépendances directement dans les images docker exactement pour cette raison. J'ai créé le #3251

J'ai mis les v2 et a7 hors ligne pour le redémarrage.

@markus2330 si vous en avez l'occasion, activez l'hyperthreading sur a7 .

La v2 est à nouveau opérationnelle, sur a7, il y a toujours un buildjob.

J'ai pris des nœuds et les ai ajoutés au nouveau serveur. Je vais le laisser tourner toute la nuit. Demain, je retournerai les nœuds s'il y a d'autres erreurs sur le nouveau serveur Jenkins.

hetzner-jenkinsNode3 fonctionnera toujours sur l'ancien Jenkins.

Demain, je retournerai les nœuds s'il y a d'autres erreurs sur le nouveau serveur Jenkins.

Les petites erreurs de construction ne sont pas une raison pour revenir en arrière. À un moment donné, nous devons corriger les erreurs, les allers-retours prennent beaucoup de temps.

Cependant, ce qui pourrait être un obstacle, c'est que le nouveau serveur n'est pas accessible. (Ni
http://95.217.75.163:8066 ni ssh). J'ai appuyé sur le bouton d'alimentation, voyons si la machine redémarre. Nous devrions enquêter sur ce qui était le problème, cependant.

http://95.217.75.163 :8066

S'il reste du temps, veuillez activer TLS à l'aide de letsencrypt, afin que nous ne divulguions pas les informations d'identification et que nous ne nous exposions pas à divers autres problèmes ?

Merci de votre contribution! Je suggérerais que nous fassions cela immédiatement lorsque nous changeons build.libelektra.org. Sinon, nous avons des efforts doubles.

Cette erreur est-elle connue ? Caught the following exception: null

On dirait que la vérification du formatage a échoué et que les autres builds ont été terminées.

tu as raison. quel message d'erreur merdique cependant :P

@Maltraité, pouvez-vous à nouveau activer la création automatique des PR ? En raison des nombreux agents, le serveur est désormais en veille la plupart du temps.

@Maltraité, pouvez-vous à nouveau activer la création automatique des PR ? En raison des nombreux agents, le serveur est désormais en veille la plupart du temps.

Terminé.

Je vais emprunter à nouveau hetzner-jenkins1 et v2 pour le nouveau serveur.

Vous n'avez pas besoin de le rendre, j'espère que nous pourrons faire le changement aujourd'hui.

Astuce : lorsque vous effectuez ce type de commutateurs, il est bon de réduire le TTL de l'entrée DNS à quelque chose d'assez bas (par exemple 60 au lieu de 21599 actuellement pour build.libelektra.org). Une fois le changement propagé, il devrait nous permettre de changer l'entrée DNS en une minute au lieu de plusieurs heures. S'il est trop tard, cela peut aider à effacer les caches DNS de google et opendns, mais certaines personnes verront inévitablement l'ancienne ressource jusqu'à ce que les entrées mises en cache expirent globalement.

EDIT : après le changement, le TTL devrait évidemment être ramené à une valeur saine pour mettre moins de charge sur le DNS.

Même s'il est peut-être trop tard, j'ai changé $TTL 3600 (si nous avons besoin de plusieurs changements jusqu'à ce que tout fonctionne).

www-new et build-new existent déjà et pointent vers le nouveau serveur.

J'ai maintenant changé doc.libelektra.org. @Mis Treated corrigera la publication. Je vais regarder sur www-new.libelektra.org

https://build-new.libelektra.org/ et https://www-new.libelektra.org/home devraient fonctionner maintenant.

Je vais changer toutes les entrées DNS maintenant.

Toutes les entrées DNS sont modifiées.

Malheureusement, certbot échoue car il semble parler avec l'ancien serveur, mais cela ne semble affecter que le téléchargement et la communauté (URL les moins utilisées).

J'espère donc que pendant/après le week-end, tout le monde verra les noms DNS mis à jour.

@Maltraité, veuillez mettre à jour la publication de tous les artefacts : également pour le site Web. Veuillez créer un PR pour vous assurer que tout fonctionne correctement.

L'ancien serveur de build est maintenant arrêté.

Je dois redémarrer le nouveau serveur (nouveau noyau et pont réseau ajoutés).

Le serveur est de nouveau opérationnel avec Linux pve 5.0.21-5-pve.

J'ai programmé une nouvelle analyse de tous les PR.

serveur hors ligne en raison d'une mauvaise configuration/bogue dans pve (/etc/network/interfaces a été supprimé par l'interface graphique ?).

Le bogue était que le renommage des périphériques réseau (qui était causé par mon action dans l'interface graphique) conduisait à un OOPS du noyau :

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

Le serveur devrait être à nouveau opérationnel.

Les problèmes précédents demeurent, cependant (la phrase ne fonctionne pas #3268)

@ Le maître

Je collecte des erreurs urgentes dans #3268. Ce serait bien si vous pouviez également tester si tout fonctionne comme décrit dans doc/BUILDSERVER.md.

jenkins ne construit pas sans raison :
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Une autre erreur de compilation : https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

Merci d'avoir signalé !

@Maltraité, pourriez-vous s'il vous plaît installer Naginator+Plugin #2967 comme déjà discuté à plusieurs reprises ? (Veuillez faire un instantané avant de modifier Jenkins.)

hetzner-jenkins1 : quota de disque dépassé

@Maltraité, pourriez-vous s'il vous plaît installer Naginator+Plugin #2967 comme déjà discuté à plusieurs reprises ? (Veuillez faire un instantané avant de modifier Jenkins.)

Je vais le faire aujourd'hui

hetzner-jenkins1 : quota de disque dépassé

@mpranj J'ai ajouté le nouveau VM tant qu'agent de construction alors que hetzner-jenkins1 est en panne.

J'ai nettoyé de l'espace sur hetzner-jenkins1 en exécutant docker system prune -a et je l'ai réactivé.

On dirait qu'il y a encore un problème que beaucoup de choses ne sont pas nettoyées par docker system prune -f . Cette fois, le pilote de stockage n'était pas btrfs mais vfs . :confus:

J'ai ajouté la nouvelle VM en tant qu'agent de génération alors que hetzner-jenkins1 est en panne.

L'idée maintenant est que nous n'utilisons plus le conteneur mais uniquement la VM à la place.

J'ai nettoyé de l'espace sur hetzner-jenkins1 en exécutant le système docker prune -a et je l'ai réactivé.

Merci beaucoup! Pouvez-vous aussi y faire un cronjob ? (sur la VM, pas sur le conteneur).

faire un cronjob là-bas?

Terminé.

@Maltraité, pourriez-vous s'il vous plaît installer Naginator+Plugin #2967 comme déjà discuté à plusieurs reprises ? (Veuillez faire un instantané avant de modifier Jenkins.)

Nous devons passer du pipeline au job freestyle, si nous voulons le plugin naginator. Je vais chercher des alternatives.

Les builds sur la VM jenkinsNode3VM échouent actuellement. Ils sont incapables de tirer sur docker :

unexpected EOF
script returned exit code 1

Je l'ai désactivé pour le moment jusqu'à ce que quelqu'un puisse résoudre le problème.

[cronjob] C'est fait.

Merci!

Nous devons passer du pipeline au job freestyle, si nous voulons le plugin naginator. Je vais chercher des alternatives.

Oui bonne idée. Il est peut-être préférable de simplement coder cela dans notre fichier Jenkins. Donc, si une tâche/étape de build problématique échoue, elle est réessayée. Que ces tractions de docker soient essayées au moins deux fois car c'est l'un des problèmes les plus fréquents.

Les builds sur la VM jenkinsNode3VM échouent actuellement. Ils sont incapables de tirer sur docker :

@Maltraité s'il vous plaît

Les builds sur la VM jenkinsNode3VM échouent actuellement. Ils sont incapables de tirer docker

J'ai corrigé l'image docker qui ne pouvait pas être extraite.

Merci beaucoup! Il est toujours utile d'écrire ce qui n'allait pas et comment vous l'avez corrigé.

Je n'ai aucune idée de ce qui n'allait pas, j'ai construit l'image manuellement sur l'agent. Depuis l'agent ne pouvait pas le tirer.

Quant à Dockerfile (scripts/docker/debian/stretch) mon Visual Code dit qu'il a 2 lignes vides à la fin, mais vim dit que c'est une seule. Je ne sais pas si cela doit faire quelque chose avec l'erreur ci-dessus, c'est peut-être juste mon VS .

Il semble que nous ayons des problèmes avec notre registre docker (l'extraction du docker #3316 échoue avec unexpected EOF ).

Étant donné que la poussière après la publication est retombée et qu'il n'y a pas de construction en cours, je suggère de tout arrêter et d'essayer d'effacer complètement le registre. Après cela, toutes les images devraient être reconstruites, espérons-le, proprement. Je sauvegarderais les données du registre avant de commencer juste pour m'en assurer, mais j'espère qu'un bon départ éliminera certaines erreurs que nous avions.

J'attendrai de savoir s'il y a quelque chose contre cela avant de commencer.

Je pense que c'est un problème dans le

(scripts/docker/debian/stretch)

image, puisqu'il est le seul à échouer.

Je l'ai recréé manuellement, mais il y a certainement quelque chose qui ne va pas avec l'image dans le registre.

Rapports Jenkins : jenkinsNode3VM (hors ligne)

@Maltraité serait formidable si vous pouviez configurer un moyen de surveillance.

a7 (et donc v2 et i7 ) sont en panne. J'ai contacté l'administrateur.

EDIT markus2330: à nouveau

En raison d'une panne de courant prévue le 08.07.2020 à TU Wien, notre administrateur prévoit d'arrêter tous les serveurs de build la veille (mardi 7.7). Les builds seront très lents pendant cette période, veuillez donc ne pousser ce jour-là que dans les cas urgents.

Les serveurs sont à nouveau en ligne sauf i7. J'ai prévenu l'administrateur.

Il y a eu une autre panne de courant (non planifiée) hier dans la soirée, donc tous les serveurs de build sont en panne maintenant. L'administrateur y travaille.

EDIT 30 min plus tard : tout, y compris i7, est de nouveau opérationnel :rocket:

@ markus2330, il semble que v2 et i7 aient récemment perdu l'accès à Internet (peut-être pendant la panne de courant ?). Êtes-vous au courant des modifications de configuration que nous aurions dû apporter, car les interfaces sont configurées de manière statique ?

Je ne suis au courant d'aucun changement, seulement du fait que les ordinateurs ont été rallumés après ces deux pannes de courant (l'une planifiée, l'autre non planifiée).

Mais tu as raison, je vois aussi que ces deux-là (mais pas a7) n'ont plus de connexion Internet, bien qu'ils soient joignables. J'ai demandé à notre administrateur à ce sujet.

Peut-être que nous les déconnectons de Jenkins jusqu'à ce que ce problème soit résolu ?

Merci d'avoir contacté l'administrateur ! J'ai déconnecté à la fois i7 et v2 jusqu'à ce que le problème puisse être résolu. (Les builds ne fonctionnent pas de toute façon car ils ne peuvent pas extraire les images Docker)

Quelqu'un a changé quelque chose avec le routeur il y a environ une semaine. La personne a été avertie et, espérons-le, le corrigera bientôt.

Gardons-les déconnectés pour le moment.

Le problème Internet est résolu maintenant et j'ai également installé les mises à jour de sécurité sur ces machines.

@mpranj pouvez-vous s'il vous plaît les rallumer ?

Merci @markus2330.

Tous les nœuds sont maintenant de nouveau en ligne.

J'ai redémarré le serveur de build pour le dernier noyau PVE. Jenkins devrait être levé sous peu.

j'ai déménagé

• [ ] rend l'envoi d'e-mails en cas d'échec de la construction plus fiable
• [ ] Image Docker sans utilisateur Jenkins
• [ ] images de docker centOS/fedora/arch
• [ ] paquets centOS
• [ ] agents de compilation freebsd/openbsd/solaris

au #3519 et lié au #3519 ci-dessus.

@robaerd a désormais également accès à a7/v2/i7 et peut contacter l'administrateur en cas de problème.

Juste un rapport rapide des temps de construction (pipeline principal libelektra ):

• avec a7 activé : 2h 29m 24s
• avec a7 désactivé : 1h 35m 45s

Pourquoi Jenkins affiche-t-il qu'il s'arrête ? Ce serait bien de toujours lire ici à l'avance :wink:

Jenkins va être arrêté, en raison d'une sauvegarde complète du système et d'un reformatage des systèmes de fichiers de btrfs à ext4.

Jenkins est à nouveau debout

Jenkins CI sera hors ligne pour maintenance à partir d'environ 11h15 CET aujourd'hui.

Nous allons effectuer des tâches de sauvegarde et de nettoyage et essayer d'améliorer les performances de a7 .

Vous serez à nouveau informé lorsque la maintenance sera terminée.

Jenkins CI et tous les serveurs de build sont à nouveau opérationnels. a7 devrait fonctionner beaucoup mieux maintenant, mais a moins de capacité de stockage.

Veuillez signaler si vous rencontrez des erreurs.

Jenkins CI et les agents de build seront hors ligne pour une courte maintenance/mises à jour.

EDIT : les mises à jour sont faites.

Le serveur est en panne, j'enquête.

Le serveur est de nouveau opérationnel.

Déclaration officielle sur la cause : « Il y a eu un problème avec le bloc d'alimentation du serveur adjacent qui a entraîné l'arrêt du serveur ; il a maintenant été corrigé. »

Le ssd dans a7 est plein, ce qui entraîne l'échec de toutes les versions.

Je vais essayer de libérer de l'espace. Est-il sûr de déconnecter l'agent de construction a7 de jenkins pour le moment ?

Merci de vous y être penché !

Je vais essayer de libérer de l'espace. Est-il sûr de déconnecter l'agent de construction a7 de jenkins pour le moment ?

Bien sûr. Au contraire, il serait dangereux de le garder connecté s'il fait échouer toutes les versions.

L'exécution de docker system prune -a nettoyé environ 50 % de l'espace. Peut-être devons-nous adapter le cronjob existant pour ajouter le drapeau -a ?

La maison jenkins utilise également beaucoup d'espace.

Les builds principaux (pipeline complet avec packages deb et création de sites Web) échouent toujours, même si tout semble vert. Des idées?

Le téléchargement des packages deb focal vers community échoue sur le fichier elektra_0.9.3.orig.tar.gz . C'est probablement un problème d'autorisation sur le fichier. Je vais le supprimer du répertoire pour le moment et le laisser être recréé lors de la prochaine exécution.

D'une manière ou d'une autre, le sshPublisher s'il échoue ne définit pas la scène en rouge.

Peut-être devons-nous adapter le cronjob existant pour ajouter le drapeau -a ?

Y avait-il une raison pour laquelle vous ne l'avez pas fait comme ça ? Si ce n'est pas le cas, cela semble être une bonne idée.

Jenkins CI et le registre sur a7 seront hors ligne pour la migration de l'image de la tour de guet vers une nouvelle version. Cela ne devrait prendre que quelques minutes.

EDIT : les mises à jour sont terminées et Jenkins CI est à nouveau opérationnel

Jenkins et les agents seront brièvement en panne pour une mise à jour.

EDIT : tout a été mis à jour et fonctionne à nouveau. J'avais besoin de corriger un problème où a7 utilisait des paquets Debian Stretch Docker au lieu de Buster. J'ai aussi nettoyé un peu d'espace.

Les builds échouent car il n'y a pas d'espace sur a7 .

L'infrastructure de construction sera indisponible pendant quelques minutes pour la maintenance.

L'infrastructure de construction est à nouveau disponible.