GitHub definiert Builds, die trotz identischem Code manchmal fehlschlagen und manchmal durchlaufen, als flaky Builds. Flaky Builds sollen von der Person behoben werden, die den betreffenden Code geschrieben hat, und per Automatisierung so behandelt werden, dass sie keine Auswirkungen auf andere haben. Dadurch wurde die Zahl der flaky Builds auf ein Achtzehntel reduziert.
In der internen CI von GitHub werden flaky Builds verfolgt, die Problemsituation wird zusammengefasst und dann der Person zugewiesen, die das Problem vermutlich verursacht hat.
-
Bei der Nachverfolgung flaky Builds zeigte sich, dass ihre Häufigkeit unterschiedlich war; flaky Builds mit mehr als 100 Fehlschlägen machten 0,4 % der Gesamtzahl aus. Deshalb entschied man sich, auf diese 0,4 % zu konzentrieren.
-
Bei der Einführung im Jahr 2016 wurde mit den folgenden zwei Methoden gearbeitet.
-
Nach Abschluss eines Builds wird nach Builds gesucht, die mit demselben Commit ausgeführt wurden; wenn die Ergebnisse unterschiedlich sind, wird er als flaky Build markiert.
-
Wenn ein erneuter Versuch desselben Builds zu einem anderen Ergebnis führt, wird er als flaky Build markiert.
-
-
Mit dieser Methode konnten nur 25 % aller flaky Builds unterschieden werden.
Verbessern
-
Verwendung einer Methode mit drei erneuten Ausführungen
-
Erneuter Versuch im selben Prozess. Diese flaky Builds entstehen durch Zufälligkeiten im Code oder Race Conditions.
-
Erneuter Versuch im selben Prozess, aber nach einiger Zeit. Diese flaky Builds entstehen, wenn falsche Annahmen in Bezug auf Zeit getroffen wurden.
-
Erneuter Versuch auf einem vollständig anderen Host. Diese flaky Builds entstehen durch Abhängigkeiten von der Testreihenfolge oder durch gemeinsam genutzten Zustand.
-
Mit dieser Methode konnten 90 % automatisch erkannt werden.
Auswirkungsmessung
Um Prioritäten festlegen zu können, war eine Methode nötig, die Auswirkungen zu quantifizieren.
Anhand von Informationen wie Build, Branch, Autor und Commit wird ein Auswirkungswert vergeben, der misst, wie häufig Fehler auftreten und wie stark andere Branches oder Entwickler betroffen sind.
Wird ein bestimmter Wert überschritten, wird ein Issue erstellt und dem Entwickler zugewiesen, damit er es beheben kann.
1 Kommentare
In meinem Fall traten flaky builds häufig bei den Unittests von Gradle auf, daher habe ich die folgenden Lösungen angewendet.
Mit dem Plugin https://plugins.gradle.org/plugin/org.gradle.test-retry lässt sich flaky build bei Unittests sehr gut nachverfolgen.
Mit https://docs.gradle.org/current/dsl/… wird die Ausführung nach einem bestimmten Zeitraum in einem neuen Prozess fortgesetzt, wodurch flaky builds entschärft werden können.
Wenn man Gradle Enterprise einführt, kann man die Entwicklung von flaky builds leicht verfolgen. https://gradle.com/blog/flaky-tests/