Release-Pakete¶
Der Befehl¶
Baut die Assets, packt die Auslieferungspakete und legt sie samt Manifest im Paketverzeichnis ab.
Die Pakete¶
| Paket | Inhalt |
|---|---|
twtheme-<version>.zip |
das Theme ohne die Icon-SVGs |
twtheme-icons-<bibliothek>-<version>.zip |
je eine Icon-Bibliothek: solid, light, brands und weitere |
| Modulpakete | je Modul ein Paket, damit der Hub Module einzeln setzen kann |
twtheme-packages.json |
Manifest mit Version und SHA-256 zu jedem Paket |
Warum die Icons getrennt liegen¶
Die Icon-Bibliotheken machen 16 von 19 MB aus. Lägen sie im Kernpaket, wanderten bei jedem Update 16 MB unveränderte Dateien mit.
Und warum eine Datei je Bibliothek statt eines Sammelarchivs: Damit der Hub sie
einzeln setzen und entfernen kann. Ein Projekt, das nur solid und brands
braucht, überträgt rund 2,3 MB statt 16 — und hat auf dem Kundenserver keine
100 MB ungenutzter SVGs.
Versionen laufen automatisch¶
Angehoben wird über Inhalts-Hashes, nicht von Hand.
| Was | Wo die Version steht | Wann sie steigt |
|---|---|---|
| Modul | module.json → version |
Patch, sobald sich im Modulordner etwas ändert. Die module.json zählt mit; nur die eingesetzte version selbst bleibt außen vor. |
| Kern | style.css und TWTHEME__VERSION |
Patch, sobald sich am Kernpaket etwas ändert. |
Beide Kern-Dateien werden geschrieben und wollen committet werden.
Eine von Hand gesetzte Kernversion gewinnt: Steht in style.css bereits mehr als
zuletzt ausgeliefert, springt die Automatik nicht ein zweites Mal. So lassen sich
Minor- und Major-Sprünge weiterhin bewusst setzen.
Der Git-Hook¶
Ausgelöst wird das Paketieren nach jedem Commit am Theme. Einmalig einhängen:
Der Hook läuft im Hintergrund und protokolliert nach
.git/twtheme-release.log. Wenn etwas schiefgeht, steht die Ursache dort — nicht
in der Ausgabe des Commits.
Überspringen:
Schalter¶
Alle über Umgebungsvariablen:
| Variable | Wirkung |
|---|---|
TWMH_SKIP_BUILD=1 |
Den Asset-Build überspringen. Nur sinnvoll, wenn er gerade schon gelaufen ist. |
TWMH_BUILD_ICONS=1 |
Die Icon-Bibliotheken neu packen. Ohne diesen Schalter werden die Einträge der letzten Auslieferung fortgeschrieben. |
TWMH_FORCE_REBUILD=1 |
Auch unveränderte Module neu packen. |
TWMH_PACKAGE_CHANNEL=preview |
In einen Vorschau-Kanal schreiben, siehe unten. |
TWMH_PACKAGES_DIR |
Ein anderes Zielverzeichnis. |
Die Icons bleiben absichtlich außen vor: Sie ändern sich fast nie, und ihr Packen dauert deutlich länger als alles andere.
Der Vorschau-Kanal¶
Schreibt twtheme-packages-preview.json und lässt das stabile Manifest
unangetastet. Damit lässt sich ein Stand auf einer einzelnen Seite ausprobieren,
ohne alle Installationen zu erreichen.
Zwei Besonderheiten:
- Ist die Versionsnummer dieselbe wie im stabilen Kanal, zählt der Lauf selbst hoch — sonst würde dasselbe ZIP überschrieben.
- Git-Branch und Commit landen mit im Manifest, damit nachvollziehbar bleibt, was in einem Vorschaupaket steckt.
Das Zielverzeichnis¶
In dieser Reihenfolge:
TWMH_PACKAGES_DIR, wenn gesetzt- sonst
<Hosts>/clients.tobiaswedel/wp-content/plugins/tw-maintenance-hub/packages
Existiert das übergeordnete Verzeichnis nicht, bricht der Lauf mit einer Meldung ab — der Hub wurde dann nicht gefunden.
Was nicht im Paket ist¶
Das Kernpaket enthält bewusst keine Quellen und keine Build-Werkzeuge: kein
source/, kein scripts/, kein docs/, kein node_modules/.
Nicht über ein Arbeitsverzeichnis installieren
Weil das Paket diese Ordner nicht enthält, würde eine Installation darüber sie
entfernen. Der Agent lehnt das ab, wenn er .git, node_modules, source
oder scripts im Ziel findet.
Auf einer Entwicklungsumgebung wird nicht installiert, sondern mit Git gearbeitet.
Vor dem Release¶
Der Sammellauf prüft unter anderem den Release-Zuschnitt — ob das Paket vollständig und richtig geschnitten ist. Siehe Qualität prüfen.
Weiter¶
- Build-Kette
- Modul-Vertrag — die Versionsregeln je Modul
- Erste Schritte — die Installation beim Kunden