Vorschlag: Nutzung von Frankfurter Firmware Release-builder

[christf]

Ich schlage vor, dass der Frnakfurter Firmwarebuilder auch für die Magdeburger Firmware eingesetzt wird:
https://github.com/freifunk-ffm/Firmware-Release-Builder

Das script übernimmt den Bau der Firmware, Verwaltung vom Download-Cache und es wird aktiv gepflegt.
Lasst uns das doch zusammen pflegen!

[andreasscherbaum]

Welche Änderungen sind dafür notwendig?

Speziell: lässt sich das mit dem integrieren was @johannwagner bisher gebaut hat?

[penguineer]

AFAIK hat @johannwagner den Docker-Container gebaut. Das Build-Script kommt u.A. von @LeSpocky .
Ich halte es aber auch für sinnvoll, keine doppelte Arbeit zu machen, sondern beide Build-Scripte so zu verheiraten, dass ein noch besseres Script herauskommt, das man dann gemeinsam pflegen kann.

[johannwagner]

So ist es.
Generell gehört das Build-Script, welches momentan mit der site-ffmd geshippt wird, etwas überarbeitet, gerade, was Benutzerführung angeht.

[andreasscherbaum]

@johannwagner Welche Änderungen sind dafür deiner Meinung nach notwendig? Und könnten die ggf. gleich Upstream als PR einfließen?

[penguineer]

Ist vielleicht etwas für einen Hacking-Abend?

Ich habe auch Ideen für Erweiterungen, tatsächlich hatte ich mit dem Script soweit aber auch keine Probleme, was die Nutzung angeht. Intern könnte man es etwas mehr kommentieren. 8)

[penguineer]

Für den Docker-Container wäre es schön, wenn man besser steuern könnte, was gebaut wird. Derzeit ist da ein Tag fest verlinkt, aber eigentlich müsste das für die site-ffmd von außen und für Gluon aus der site-conf kommen.

[andreasscherbaum]

Braucht es den Docker Container noch, wenn das Frankfurter System zum Einsatz kommt?
Ansonsten würde es den Aufwand sparen, die gewünschten Änderungen in den Container einzubinden.

[johannwagner]

@andreasscherbaum Generell ist ein Fork von der Frankfurter Variante wünschenswert. Da müsste erörtert werden, wie viel man da ändern muss und ob das über eine Konfiguration funktioniert oder ob hart geforkt werden muss. Ich kann zu dem Aufwand nichts sagen, da ich generell nicht flüssig in Bash bin. Ich denke aber, dass eine Grundversion mit dem Ändern von ein paar URLs durchaus möglich ist, insofern die Frankfurter nicht eine komplett abgefahrene Version von Freifunk fahren.

@penguineer Ich finde die Idee ebenfalls sehr gut, dass man an einem Hacking-Abend das Geschoss mal forkt und mal probiert, was passiert, wenn man das mal versucht. In einem zweiten Anlauf könnte man das dann ordentlich machen, sodass es evtl. sogar wieder dem Frankfurter Upstream zugeführt werden kann.

@penguineer Es ist möglich, dass der Docker-Container über Environment-Variablen gesteuert wird. Diese können auch beim Bau eingebaut werden und dann in einem .env-File daneben gelegt werden. Further Reference: https://docs.docker.com/engine/reference/commandline/build/ mit dem Stichwort --build-arg
Man kann auf der Seite nicht auf SubTopics verlinken, das macht das Ganze ziemlich mühsam.

@andreasscherbaum Wenn man das Build-System entweder sauber forken oder einen Fork zur Konfigurierbarkeit machen möchte, dann dauert das seine Zeit, vielleicht auch länger als die nächsten zwei Versionen. Der Aufwand, einen Docker-Container konfigurierbar zu machen, ist generell nicht so schlimm. Außerdem ist der Grundgedanke von Freifunk ja auch, dass man etwas lernt.

[penguineer]

Ich bin übrigens weiterhin dafür, den Docker-Container zu haben, weil er eine einheitliche Build-Umgebung bereitstellt und dokumentiert.

[andreasscherbaum]

Das würde den Docker Container dann quasi als Entwicklungsumgebung bereitstellen, sehe ich das richtig?

Damit ist es um so wichtiger dass man steuern kann welche Branches oder Builds der Container baut, und wohin die Dateien danach geschoben werden (auf den Host des Entwicklers).

[penguineer]

Gut, dann brauchen wir einen Mechanismus zur Auswahl der Branches. Ich habe dafür FreifunkMD/gluon-docker#6 angelegt.

Die Auswahl der Zielverzeichnisse ist über Mounts beim Aufruf des Containers möglich, siehe dazu die entsprechende Readme).

[christf]

Heute Abend haben wir mit Docker etwas herumgespielt und ich hab einen sehr viel einfacheren Buildjob in meinem jenkins in Docker abgebildet. Branches kann man von außen in den Frankfurter Firmwarebuilder reinrufen, es werden allerdings ein paar Annahmen getroffen von denen wir mal schauen müssen ob die in MD passen. Das kriegen wir angepasst. Den Dockercontainer kann man so bauen, dass man ENTRYPOINT ["/bin/bash","-c"] im Dockerfile setzt. Dadurch kann man von außen die Kommandos reinrufen, die man ausgeführt haben will: docker run --name stefan ffmdbuild "./firmwareReleaseBuilder -a -b -c -d -e -f" docker cp stefan:output/images/factory wosolldashin? So lässt sich das auch ohne mounts und damit mit weniger Abhängigkeiten zur Infrastruktur bauen. Mein aktueller Jenkins-Job sieht so aus: DATE=$(date -I) docker container prune -f docker run --name "mmfdb" mmfdbuild " \ git fetch --all && \ git reset --hard origin/master && \ rm -rf build && \ mkdir build && \ cd build && \ cmake .. && \ make -j4 && \ checkinstall -D --maintainer=\"Christof Schulze \<christof.schulze@gmx.net\>\" \ --requires=\"libbabelhelper\" \ --pkgname=mmfd \ --pkgversion=$DATE \ --install=no \ --nodoc make install \ " docker cp mmfdb:/mmfd/build/mmfd_${DATE}-1_amd64.deb . docker cp mmfdb:/mmfd/build/src/mmfd . /usr/local/bin/publish-mmfd docker container prune -f Die Wahl des Branches kann mit dem gleichen Verfahren abgebildet werden. Von außen reinrufen, so wie ich aktuell alle Parameter von checkinstall in den docker container rufe, ist sicherlich das flexibelste.

On Thu, May 03, 2018 at 02:31:11AM -0700, Stefan Haun wrote: Gut, dann brauchen wir einen Mechanismus zur Auswahl der Branches. Ich habe dafür FreifunkMD/gluon-docker#6 angelegt. Die Auswahl der Zielverzeichnisse ist über Mounts beim Aufruf des Containers möglich, siehe dazu die entsprechende [Readme](https://github.com/FreifunkMD/gluon-docker/blob/master/README.md)).

-- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments

[oszilloskop]

Der Frankfurter FirmwareReleaseBuilder wurde/wird von mir entwickelt :)
Er war ursprünglich stark an Frankfurt angelehnt. Da @christf ihn auch für seine Babel-Entwicklung benutzt, wurden die Frankfurter Abhängigkeit peu à peu entfernt. Lediglich default-Werte einiger CLI-Parameter zeigen noch wo seine Wurzeln liegen.
Der aktuelle Frankfurter FirmwareReleaseBuilder wurde stark weiterentwickelt, ist (falls gewünscht) recht frei parametrierbar und sollte nun eigentlich Community-unabhängig einsetzbar sein.

Falls noch Umstellungsbedarfe im Magdeburger Build-Prozess vorhanden sein sollten und evtl. der Frankfurter FirmwareReleaseBuilder in Betracht gezogen wird, so stehe ich gerne für Fragen und/oder Anregungen zur Verfügung.