[Freifunk-Bonn] Jenkins Buildscripte

[Allgemeine Mailingliste zum Freifunk Köln, Bonn und Umgebung]

Hallo Yanosz,

>Hmm.. was sollte ein solcher build genau machen?
Die Frage ist gut. Ich stelle fest, dass viele Communities ihr eigenes 
buildscript bauen. Einige verdockern irgendein shell-script (Magdeburg) 
Andere bauen Makefiles (Deiner Schilderung nach KBU) andere bauen 
Shell-Scripte die sie auf irgendwelchen hosts ausführen. Wieder andere 
bauen Jenkins Jobs.

Letztlich haben alle diese Ansätze gemeinsam, dass sie den gluon build 
wrappen, wobei ein knappes Dutzend Parameter reingerufen werden:
Site repo, site branch, gluon repo, gluon branch, targets, broken, 
logging... Es ist immer das selbe.

An sich müsste das nicht so sein. Wäre doch schick, wenn das einmal 
zentral gebaut wäre - z.B. das frankfurter firmwarebauscript ist 
mittlerweile recht angenehm nutzbar und auch gut in vorhandene 
Infrastruktur integriert werden könnte. Mit Stages wären sogar tests in 
einer VM möglich.

Hat man eine Integration in so einen Prozess heißt das keinesfalls, dass 
man nicht immer noch genau wie heute eine andere Lösung stricken kann. 
Es gibt dann eben eine Referenzimplementierung die man nehmen kann oder 
auch nicht.

Und Pipeline vs Job ist m.E. Nur dadurch begründet, dass Jenkins beim 
Neustart Jobs abbricht und nicht wieder aufnimmt, pipelines jedoch 
schon.


viele Grüße

Christof



>
>Ich find's nicht wirklich klug, auf einen CI-Server zu zielen. Z.B.
>bauen wir bei KBU mit jenkins und gitlab. Üblich sind auch Travis und bambo.
>
>IMHO ist das Gluon-Buildsystem etwas holprig, da Du nicht mit einem
>"make dist" o.ä. ein subdirectory für alle Artefakte, Plattformen und
>Site-Configs erstellen kannst. Dann wäre ein jenkins-job 3-Zeilen Shell.
>
>Ich glaub' aber auch nicht, dass es einfach möglich ist, den Gluon Build
>zu refactoren, da die Konfiguration sehr komplex ist.
>Z.B. Ist es mit dem gluon-System bei einem Multidomän Setup unmöglich,
>für jede Domain ein Binary zu bauen, bei dem die zugh. Domain auch
>default ist. Bei KBU gibt's für Köln, Bonn und Umgebung aber vers.
>Binaries. Vers. batman-adv Versionen für vers. Domäns sind auch nicht
>möglich.
>
>Ich hab' daher ein Makefile erstellt [1,2], dass den gluon-Build
>mehrfach startet, envsubs-Aufrufe für die die Domänen (Köln, Bonn,
>Umgebung) macht und ein dist-Verzeichnis zusammen stellt. Das Makefile
>damit recht spezifisch für KBU - die Version für gluon 2018.1 [2] läuft
>u.a. wegen gitlab-Problemen auch nicht sauber durch die CI.
>
>Aktuell bin ich ein wenig ratlos, was hier anderen Communities helfen
>könnte. Damit zurück zur Einstiegsfrage: was sollte ein solcher build
>genau machen? Welche Stages / Schritte / etc. soll er durchlaufen?
>
>Gruß, yanosz
>
>[1]https://git.kbu.freifunk.net/ff-kbu/gluon-build/blob/release/Makefile
>[2]https://git.kbu.freifunk.net/ff-kbu/gluon-build/blob/master/Makefile
-- 
()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 195 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20181115/727613ec/attachment.sig>