also ich finde das Konzept gerade nicht ganz so optimal. Alles ein bisschen viel, wenn ich bedenke wo wir aktuell stehen.

Bevor wir diesen rissigen Firmware build Wahnsinn anfangen, der unheimlich viel Ressourcen und Zeit kostet. Sollten wir mal schauen ob wir vor diesem "Operational acceptance testing / System test“ schnellere Varianten anwenden.

Wir sollten denke ich eher schauen, automatische tests zu erzeugen, die den code testen ohne gleiche eine Firmware bauen zu müssen.

Aus der Hüfte geschossen würde ich erstmal sowas einbauen, welches wir automatisiert testen können ohne eine komplette firmware zu bauen:

Alles: Code Style Check
Hoodfile:

JSON valid?
Lorenz sein script welches alle peers durchtestetet

Hoodselector:

Unit tests mit verschieden Testseznarien, ob sich der hoodselector richtig entscheidet

Ich denke das macht für uns mehr sinn aktuell.

Nach meiner Hochzeit im August nehme ich mich gerne diesem Thema an

Am 29.06.2017 um 13:26 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:

Hi zusammen,

Clemens hatte vor einiger Zeit mal den nigthly autoupdater
branche im siteconf repo angelegt.

Ich habe gestern testweise mal den nigthly CI in das packages repo eingebaut.

Langfristig würde ich mir wünschen den nigthly CI in dem packages repo zu lassen.
Das ermöglicht bsp. das Änderungen die in den Master gemerged wurde automatisch
Auf die Router installiert werden die auf dem nigthly branch zeigen.
Somit können Entwickler relativ einfach neue Änderungen von anderen Entwicklern
testen und auf bestehenden Änderungen entwickeln.

Ein nigthly branche im siteconf repo ist nicht wirklich hilfreich.
Da dieses relativ selten, meist zur Zeit eines releases geädert wird.

vg
Tarek

_______________________________________________
Dev mailing list
Dev@lists.ffnw.de
https://lists.ffnw.de/mailman/listinfo/dev