SNLO – Spittank.net Ladeorganisation – Release-Integrität 0.5.12¶
Der Quellstand enthält im Projektwurzelverzeichnis MANIFEST.sha256. Das Manifest führt jede reguläre Projektdatei außer sich selbst mit ihrem SHA-256-Wert auf. Generierte Verzeichnisse wie site/, Python-Caches und Test-Caches sind nicht Bestandteil des Release.
Prüfung nach dem Entpacken:
Für ZIP und TAR.GZ wird zusätzlich eine äußere Prüfsummendatei veröffentlicht:
Ausgeführte Integritätsprüfungen¶
- beide Archive erneut in getrennte Verzeichnisse entpackt,
unzip -tundtar -tzferfolgreich,- internes
MANIFEST.sha256in beiden entpackten Bäumen vollständig geprüft, - reguläre Dateien aus ZIP und TAR.GZ bytegenau miteinander verglichen,
- Validierungsskript aus dem erneut entpackten ZIP ausgeführt,
- 60 Anwendungstests, Python-Kompilierung und JavaScript-Syntaxprüfung bestanden,
- Alembic-Neuinstallation und Upgrades von 0.1.1 sowie 0.3.0 bestanden,
- FastAPI-/PWA-Smoke-Test bestanden,
- KEBA-Gateway-Tests für festen UDP-Sende-/Empfangsport 7090, Gateway-Authentifizierung und den produktiven
uvloop-Eventloop bestanden, - Zensical-TOML, Markdown-Navigation, lokale Links, Forgejo-Workflows und Compose-YAML geprüft,
- Trennung der Forgejo-Jobs geprüft:
validateenthält keine Dokumentations- oder Containerprüfung; Zensical liegt ausschließlich imdocs-Job, - vollständiger AGPL-v3-Lizenztext und
AGPL-3.0-only-Metadaten geprüft, - Suche nach dem ausgemusterten Produktnamen bestanden.
Nicht lokal ausgeführte Schritte¶
Mangels Docker-Daemon wurde kein reales Containerimage gebaut. Wegen gesperrter externer Namensauflösung konnte Zensical in dieser Umgebung nicht installiert und damit nicht real gerendert werden. Der echte Zensical-Build läuft im separaten docs-Job nach erfolgreicher Validierung und wird anschließend direkt über git-pages veröffentlicht. Container werden bewusst nicht im normalen CI-Workflow gebaut; der Tag-Workflow baut und veröffentlicht sie erst nach erfolgreicher Gesamtvalidierung.