Vielen Dank für das Sammeln der Ausgaben!

Für die Maven Builds haben wir bereits ein Problem: # 2855

Für die Maven Builds haben wir bereits ein Problem: # 2855

Ich weiß 😊. Ich habe bereits einen Link in der Problembeschreibung hinzugefügt.

Vielen Dank für diese aufwändige Recherche. Wir müssen jetzt ein Problem nach dem anderen beheben.

Für die Haskell-Probleme können wir die Haskell-Bindungen / Plugins entfernen. Sie werden sowieso nicht gewartet.

Haskell wird in # 3017 entfernt

Die Fehler, bei denen docker pull in der Website-Phase fehlschlägt, treten jetzt ziemlich häufig auf.

Ich habe gerade auch Verbindungsprobleme für Build-Elektra-Web-Base bekommen.

3d070e3209ce: Retrying in 1 second

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

script returned exit code 1

Dies ist ein vollständiges Protokoll.

Die Fehler, bei denen docker pull in der Website-Phase fehlschlägt, treten jetzt ziemlich häufig auf.

Ist das alles das Wiederholen und Warten nach Pulling from build-elektra-web-base ( Protokoll )?

Außerdem denke ich, dass dieser Fehler neu ist: test_service_convertengine schlägt während Starting build/hub.libelektra.org/build-elektra-website-backend fehl ( Protokoll 2 )

Ja, ich bin damit einverstanden, dass test_service_convertengine hier noch nicht gemeldet wird. Tatsächlich können wir den Test deaktivieren, da der Dienst sowieso nicht geändert wird.

@sanssecours Gibt es ein Verfahren zum Hinzufügen neuer Tests in der obigen Liste?

@sanssecours Gibt es ein Verfahren zum Hinzufügen neuer Tests in der obigen Liste?

Nee. Ich habe es bereits aufgegeben, die Liste zu ändern, da der Jenkins-Build zu oft fehlschlägt. Ich würde empfehlen, dass wir nur ein Problem für jedes spezifische Problem öffnen.

Bei Problemen im Zusammenhang mit dem Quellcode stimme ich zu. Für die Probleme im Zusammenhang mit der Docker / Jenkins-Instabilität reicht es aus, hier Probleme zu sammeln, da die Möglichkeiten, die wir neben der bereits durchgeführten Migration haben, sehr begrenzt sind, aber leider länger dauern als erwartet. Es wäre schön, wenn @Mistreated mehr Informationen über den Status geben könnte, vielleicht in # 160.

Außerdem halte ich diesen Fehler für neu: test_service_convertengine schlägt beim Starten von build / hub.libelektra.org / build-elektra-website-backend fehl (Protokoll 2)

Können Sie das bitte separat melden? Das Update besteht darin, die Tests zu deaktivieren.

Können Sie das bitte separat melden?

Fertig, siehe # 3086

Ich denke, unsere beste Vermutung, um unser Leben viel einfacher zu machen, besteht darin, diese Probleme mithilfe von https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin zu "beheben"

Dann startet Jenkins fehlgeschlagene Jobs mehrmals neu. Ich denke, wir könnten 5 Neustarts versuchen, bevor wir aufgeben?

@Mistreated Kannst du das auch auf dem alten Server implementieren? Oder ist das zu riskant?

Bevor wir dies implementieren, benötigen wir jedoch den neuen Jenkins-Knoten, da sonst die Warteschlange zu lang wird.

Nach einigem Kämpfen gelang es mir, einen neuen Jenkins-Knoten hinzuzufügen.

Bevor wir dies implementieren, benötigen wir jedoch den neuen Jenkins-Knoten, da sonst die Warteschlange zu lang wird.

Der alte Server ist meiner Meinung nach überlastet, aber wir können es versuchen, denke ich.

Nach einigem Kämpfen gelang es mir, einen neuen Jenkins-Knoten hinzuzufügen.

Vielen Dank, dass Sie den neuen Jenkins-Knoten hinzugefügt haben. Ich habe den Knoten vorerst deaktiviert, da er den Build zu beschädigen scheint .

Ich habe den Knoten aktualisiert. Es sollte jetzt funktionieren. Wenn etwas schief geht, können Sie mich hier erneut aktualisieren.

Wenn etwas schief geht, können Sie mich hier erneut aktualisieren.

Es sieht so aus, als ob docker pull bei hetzner-jenkins1 docker pull fehlschlägt , da der Knoten nicht über genügend freien Speicherplatz verfügt:

Hetzner-jenkins1 kann nicht kontaktiert werden: hudson.remoting.RequestAbortedException: java.io.IOException: Unerwartete Beendigung des Kanals
Layer konnte nicht registriert werden: ApplyLayer-Exit-Status 1 stdout: stderr: write / usr / lib / git-core / git-credential-store: Festplattenkontingent überschritten

.

Es sieht so aus, als ob Docker Pull auf hetzner-jenkins1 fehlschlägt, da der Knoten nicht über genügend freien Speicherplatz verfügt:

Knoten aktualisiert.

Das Erstellen von Jobs auf hetzner-jenkins1 scheint aufgrund von Berechtigungsproblemen fehlzuschlagen:

Ressource: Verzeichnis '/.config' konnte nicht erstellt werden. Grund: Erlaubnis verweigert. Identität: uid: 47000, euid: 47000, gid: 47000, egid: 47000

.

Ich habe den Knoten erneut aktualisiert, es sollte keine Berechtigungsprobleme mehr geben.

Warum möchte Jenkins ein '/.config' und nicht nur ein '.config'-Verzeichnis erstellen?
Es gibt ein .config-Verzeichnis in '/ home / jenkins /', aber er möchte einen .config-Ordner in '/' erstellen.

Ich denke nicht, dass Benutzer 'Jenkins' dazu in der Lage sein sollten.

@Mistreated Bitte machen Sie auch eine PR, um zu testen, ob die Builds jetzt funktionieren.

Warum möchte Jenkins ein '/.config' und nicht nur ein '.config'-Verzeichnis erstellen?
Es gibt ein .config-Verzeichnis in '/ home / jenkins /', aber er möchte einen .config-Ordner in '/' erstellen.

Dies kann passieren, wenn das Ausgangsverzeichnis des Benutzers / ist. Haben Sie sich / etc / passwd angesehen, vielleicht stimmt dort etwas nicht?

Dies kann passieren, wenn das Ausgangsverzeichnis des Benutzers / ist. Haben Sie sich / etc / passwd angesehen, vielleicht stimmt dort etwas nicht?

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

Auch in den Protokollen des Knotens sieht alles gut aus:

'HOME =' / home / jenkins ''
'HINWEIS: Der relative Remote-Pfad wurde aufgelöst in: / home / jenkins /.'

Es wäre einfacher zu debuggen, um eine PR mit dem gesamten Protokoll zu sehen.

Hauptknoten ist ausgefallen.

Es wäre einfacher zu debuggen, um eine PR mit dem gesamten Protokoll zu sehen.

3134

Hauptknoten ist ausgefallen.

Danke für die Information. Ich habe alle Protokollinformationen für alte Pull-Anforderungen gelöscht und den Knoten wieder aktiviert. Leider ist der freie Speicherplatz auf dem Jenkins-Master immer noch sehr gering (~ 3,9 G).

@ Misshandelt Ich habe die Diskussion über den Hetzner-Knoten auf # 3138 verschoben. Bei diesem Problem handelt es sich um vorübergehende Fehler auf dem Build-Server und nicht um eine falsche Einrichtung des Build-Servers.

Es sieht so aus, als würde das Erstellen von Docker-Images unter hetzner-jenkins1 nicht funktionieren :

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

. Ich habe den Knoten deaktiviert.

Es ist nur Disk quota exceeded , ich wollte es nicht mit Speicher übertreiben. Ich habe es jetzt aufgeräumt. Es ist wieder soweit.

Zwei weitere Tests, die manchmal fehlschlagen (# 3168):

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

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

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

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

BINDING TEST-SUITE

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

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

Noch ein Fehler in https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/12/pipeline/

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

 ---> Running in f5ed5e42a480

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

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

script returned exit code 92

Ich fürchte, https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin ist der einzige größere Schritt nach vorne.

Leider werden die Probleme für Travis oder Cirrus nicht behoben.

Haben wir im Startbeitrag "Zeiten fehlgeschlagen" aktualisiert? check_external_example_codegen_econf passiert derzeit ziemlich oft.

Der Versuch, den Startbeitrag zu aktualisieren oder all diese Probleme zu beheben, ist hoffnungslos. Wir müssen es erneut versuchen. Ich hoffe, @Mistreated wird dies bald auf unserem neuen Server implementieren.

Was denkst du über # 3224?

Probleme sind jetzt gelöst. Bitte öffnen Sie neue Probleme, wenn Builds immer noch fehlschlagen.