Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- technik:software:gluon [09.12.2019 - 15:40] – nrb
+++ technik:software:gluon [05.12.2024 - 17:27] (aktuell) – nrb
@@ Zeile 24: / Zeile 24: @@
 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 =====
@@ Zeile 43: / Zeile 38: @@
   * ''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'': Commit Hash des [Gluon-Repo](https://gitlab.freifunk-stuttgart.de/firmware/gluon)
-  * ''commit hash gluon site'': Commit Hash des [Site-Config-Repo](https://freifunk-stuttgart.de/firmware/site-ffs)
+  * ''commit hash gluon site'': Commit Hash des [Site-Config-Repo](https://gitlab.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.
+Es gibt fuer jede Minor-Version einen Branch in [site-ffs](https://gitlab.freifunk-stuttgart.de/firmware/site-ffs). Die Existenz des Branches bedeutet nicht, dass die Firmware released oder getestet wurde.
 ===== Tags =====
@@ Zeile 56: / Zeile 51: @@
 <code>
-<versionsnummer>-<kanalname>-<releasenummer>
+<versionsnummer>-<build datum>
 </code>
@@ Zeile 62: / Zeile 57: @@
   * ''versionsnummer'': der Name des Branches, von dem gebaut wurde
-  * ''kanalname'': Name des Update-Kanals, z.B. beta
+  * ''builddatum'': Das Datum des Builds
-  * ''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 =====
+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-Mimor-Version gibt. Falls ja, wird automatisch upgedated. Diese Firmware-Version wird automatisch auf dem `nighly`-Kanal veroeffentlicht.
+Es wird immer nur auf die neuste Minor-Version upgegraded. Benutzen wir aktuell Gluon v2019.1 und erscheint Gluon v2019.1.1, wird auf diese Version upgedated. Erscheint v2019.2, wird kein Upgrade durchgefuehrt.
+Die Pipeline: https://gitlab.freifunk-stuttgart.de/firmware/ffs-pipeline-nightly
+===== Firmware veröffentlichen =====
+Es gibt zwei Varianten:
+  * Sofortige Veröffentlichung, eignet sich nur für beta, nightly etc. Dabei gibt es keinen gestaffelten Rollout.
+  * Gestaffelte Rollout, für die stabile Firmware rollen wir die Firmware Segmentweise aus, um eventuelle Probleme frühzeitig zu finden
+==== Sofortige Veröffentlichung ====
+<WRAP center round important 60%>
+Dieses Vorgehen rollt die Firmware auf einmal im ganzen Netz aus! Bitte nur für beta, nightly oder experimental verwenden! Nicht für stable verwenden!
+</WRAP>
+  - sicherstellen, dass die Firmware bereits auf dem Firmwareserver unter ''/home/www/html/firmware/gluon/archive'' liegt.
+    - falls nicht, mit ''/home/www/ffs-firmware-downloader/download-nightly.sh'' herunterladen
+  - sicherstellen, dass das Manifest des entsprechenden Release-Kanals die Mindestanzahl Signaturen enthält (stable 2, sonst 1)
+  - unter ''/home/www/html/firmware/gluon'' einen eventuell vorhandenen ''.old'' symlink löschen, bspw so: ''rm /home/www/html/firmware/gluon/beta.old''
+  - den alten symlink nach ''.old'' umbenennen: ''mv /home/www/html/firmware/gluon/beta /home/www/html/firmware/gluon/beta.old''
+  - einen Symlink mit dem Namen des release-Kanals auf die entsprechende Version anlegen, bspw so: ''ln -s /home/www/html/firmware/gluon/archive/3.1+2024-07-08-g.1a770db5-s.54a31d0/images /home/www/html/firmware/gluon/beta''
+==== Gestaffelte Veröffentlichung ====
-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.
+  - sicherstellen, dass die Firmware bereits auf dem Firmwareserver unter ''/home/www/html/firmware/gluon/archive'' liegt.
+    - falls nicht, mit ''/home/www/ffs-firmware-downloader/download-nightly.sh'' herunterladen
+  - sicherstellen, dass das Manifest des entsprechenden Release-Kanals die Mindestanzahl Signaturen enthält (stable 2, sonst 1)
+  - als root die ''/etc/nginx/sites-enabled/default'' bearbeiten
+    - in ''geo $serve_oldstable''
+      - ''default'' auf ''0''
+      - ''fd21:b4dc:4b00::/40'' auf ''1''
+  - unter ''/home/www/html/firmware/gluon'' einen eventuell vorhandenen ''.old'' symlink löschen, bspw so: ''rm /home/www/html/firmware/gluon/beta.old''
+  - den alten symlink nach ''.old'' umbenennen: ''mv /home/www/html/firmware/gluon/beta /home/www/html/firmware/gluon/beta.old''
+  - einen Symlink mit dem Namen des release-Kanals auf die entsprechende Version anlegen, bspw so: ''ln -s /home/www/html/firmware/gluon/archive/3.1+2024-07-08-g.1a770db5-s.54a31d0/images /home/www/html/firmware/gluon/beta''
-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.
 ===== Siehe auch =====