Dies ist eine alte Version des Dokuments!
Gluon
Gluon ist bei Freifunk Stuttgart die Basis für die Software, die auf Nodes läuft.
Update-Kanaele
Der Autoupdater unterstuetzt verschiedene Kanaele fuer Updates. Welcher Kanal genutzt werden soll, kann im Config Mode eingestellt werden.
Es gibt derzeit die folgenden Kanaele:
* *stable*: die neuste stabile Version. Diese Version wurde ausfuehrlich getestet und wird fuer pflegeleichte Installationen empfohlen. * *beta*: hier gibt es eine etwas aktuellere Version. Sie wurde auch getestet, aber moeglicherweise nicht auf so vielen Geraeten wie die stabile Version. In der Regel sollte hier nichts kaputt gehen, aber es kann vielleicht mal zu kleineren Problemen kommen. * *nightly*: die aktuelle Entwicklungsversion. Wenn du diese Version verwendest, solltest du wissen wie du einen gebrickten Router wiederherstellen kannst. * *experimental*: eine experimentelle Entwicklungsversion. Immer wenn wir etwas groesseres Umstellen, veroeffentlichen wir zunaechst eine experimentelle Version. Sie kann mit unserem derzeitigen Netz inkompatibel sein. Du solltest auch hier wissen, wie du einen gebrickten Router wiederherstellen kannst.
Builds
Gebaut wird die Firmware automatisch mit Gitlab.
Eine Firmware-Version kann ohne erneut zu bauen in einen anderen Release-Kanal geschoben werden. Daher werden bei jedem Build Manifests fuer alle Update-Kanaele erzeugt.
Signatur
Beim Build wird eine Firmware-Version automatisch mit dem Schluessel von Gitlab signiert, wenn sie von einem protected Branch gebaut wurde. Das ermoeglicht es, den Build direkt auf nightly oder experimental zu veroeffentlichten.
Offene Punkte Buildinfrastruktur
* Cache. Der Gitlab CI Cache scheint nicht immer zu funktionieren. Es werden trotzdem bei jedem Build viele Dateien aus dem Internet herunterladen. Untersuchen. * automatische Veroeffentlichung auf firmware
Versionsnummern
Die Versionsnummern unserer Firmware sind wie folgt aufgebaut:
``` v<major-version>.<minor-version>+<build-datum>-g.<commit hash gluon>-s.<commit hash gluon site> ```
Wobei:
* `major-version`: die Version des Haupt-Releases. Wir nur selten erhoeht. * `minor-version`: die Minor-Version. * `build-datum`: das Build-Datum in der Form `YYYY-MM-DD` * `commit hash gluon`: Commit Hash des [Gluon-Repo](https://freifunk-stuttgart.de/firmware/gluon) * `commit hash gluon site`: Commit Hash des [Site-Config-Repo](https://freifunk-stuttgart.de/firmware/site-ffs)
Branches
Es gibt fuer jede Minor-Version einen Branch in [site-ffs](https://freifunk-stuttgart.de/firmware/site-ffs). Die Existenz des Branches bedeutet nicht, dass die Firmware released oder getestet wurde.
Tags
Fuer jede Veroeffentlichung auf einem Kanal soll ein Tag erstellt werden. Er soll wie folgt formatiert sein:
``` <versionsnummer>-<kanalname>-<releasenummer> ```
Wobei:
* *versionsnummer* der Name des Branches, von dem gebaut wurde, ist * *kanalname*: Name des Update-Kanals, z.B. beta * *releasenummer*: Nummer des Releases. Wird nach jedem Release auf Update-Kanal *kanalname* mit Version *versionsnummer* um eins inkrementiert.
Anhand dieses Tag-Namens stellt der Firmware-Server `netinfo` dann die Firmware-Images zum Download auf firmware.freifunk-stuttgart.de bereit.
Automatisches Gluon-Update
Es gibt eine Pipeline, die im Git-Repo automatisch gegen das jeweils neuste Gluon-Release-Minor-Release baut. Benutzen wir aktuell Gluon `v2019.1` und erscheint Gluon `v2019.1.1`, wird auf diese Version upgedated. Erscheint `v2019.2`, wird kein Upgrade durchgefuehrt.
Auf dem Branch der jeweils neusten Entwicklungsversion (d.h. die aus der der nightly-Branch entsteht) wird automatisch jeden Donnerstag geprueft, ob es eine neuere Gluon-Version gibt. Falls ja, wird automatisch upgedated. Diese Firmware-Version wird automatisch auf dem `nighly`-Kanal veroeffentlicht.