Fortsetzung der Diskussion von Firmware, wer sucht hat verloren:
Weil Jenkins ZFS-Snapshots nur unzureichend unterstützt, aber in Jenkins das rückrollen von kaskadierten Patches faktisch anders nicht möglich ist. (Zumindest nach meinem Wissensstand. Mag aber sein, dass ich etwas Naheliegendes übersehe.)
Ich empfehle den Ansatz von @RubenKelevra
Was haben Dateisystemfeatures mit Buildumgebungen zu tun?!
Keine Ahnung, was Du da für überkandidelte Umgebungen Dir gebaut hast, aber Jenkins baut erst einmal, was ihm gesagt wurde – i. d. R. also basierend auf einer git-commit-ID –, oder verstehe ich hier etwas miß?
Wenn man in unterschiedliche Patches für verschiene Communities hat, spart man sich mit Snapshots die „make dirclean“. (Weil „git stash“ bei mehrfach kaskadierten GITs ineinander hängen)
Bitte 
Man lernt ja nie aus, und viele Wege führen nach Rom (als auch über die Klippe).
Ich tendiere dazu, Langsamkeit mit Hardware zu erschlagen – oder, mangels Funding dafür, ergebenst wartend das eine oder andere Getränk mehr zu mir zu nehmen –, anstatt ein an sich ziemlich gut funktionierendes System (git, Jenkins) durch weitere Komponenten zu verkomplizieren. Ggf. war der Leidensdruck bei uns aber auch nur nicht groß genug (s. u.).
Snapshots auf FS-Ebene als Shortcut zum Checkout alter Versionen bei Verwendung von git finde ich eine bemerkenswerte Idee. Aber warum ZFS, LVM kann doch auch Snapshots?
Aber das Problem mit »kaskadierten GITs« haben wir eh’ nicht, da statt auf drölfzig Firmwareversionen schon frühzeitig (beim Stand von 3) auf genau eine FW-Version hingearbeitet wurde, die über internen (koordinaten-, naja, effektiv »LOCODE«-abhängigen) Austausch der site.confs in allen unterstützten Communities einsetzbar ist. Ist halt die Frage, wo man die Prioritäten setzt, Reduktion der Buildanzahl/-zeiten oder der Zeit bei Rollbacks. Aktuell dauert ein frischer Build in der VM auf dem Core-i7-Build-Blech von Hetzners Resterampe rd. 3h, ein Durchnudeln der letzten Commits ca. 20 Minuten (es werden als PoC nur 841v9+, 1043v2+ und x86-kvm gebaut; voller Build aller Firmwares dauert aber auch nicht wirklich viel länger, unter 30 Min. IIRC). Mit dem geplanten Schwenk von besagter 6-vCore-VM auf Docker auf einem 24-Core-Host erhoffen wir uns eine spürbare Verkürzung des Durchlaufs, insbesondere bei einem frischen Build, sollte mal ein Rollback notwendig werden. Aber selbst mit 20 Minuten kann ich gut leben, denn der Krempel baut sich dank Jenkins – um wieder on-topic zu werden – bei jeder Codeänderung automatisch neu, inkl. Upload auf den FW-Server in einen Experimental-Branch.
Mit Jenkins (1.x) kommen wir hier also ganz gut zurecht; ich weiß, daß die Berliner per Buildbot bauen. Gibt’s denn sonst noch Erfahrungen (welche? ;)) mit anderen Buildumgebungen?
Ich versteh die Frage nicht so ganz, LVM ist absolute Krüppelsoftware die eigentlich niemand mehr einsetzen will. Warum sollte man darauf bauen? Da könnte man auch argumentieren das man FAT32 benutzt, weil es auch lange Dateinamen kann. 
Bei uns dauert ein Komplett frischer Build derzeit ca. 40 Minuten, wenn schon der Cache gefüllt ist ca 2-3 Minuten pro Architektur, seh derzeit keinen Grund das Setup anzupassen.
Wir werden jetzt vermutlich Drone einsetzen um Continuous Integration der Firmware zu machen inkl. Tests der Firmware in einer VM 
LG Ruben
