Macht 1031846 rueckgaengig. Der erste Lauf auf der Test-VM hat die Werte
geliefert (Sales Pack 4.4.0: Installation 12 s, Neustart bis healthy 21 s,
gesamt 35 s); die Ausgabe wird nicht mehr gebraucht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Installation, Neustart bis healthy und Gesamtdauer werden gemessen und am
Ende ausgegeben. Fuer die EspoCRM-Installation selbst gibt es noch keinen
Messwert (die Integrationsinstanz protokolliert sie nicht); die ersten
Laeufe liefern so die Grundlage fuer das Zeitlimit des Tasks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ESPO-13 legt Secrets unter /srv/espo/secrets ab (vorerst
gitea_package_token). Je Secret ein Parameter; leer oder woertlicher
Platzhalter laesst den Bestand. Erst Format und Funktion aller Werte
pruefen (Probeabruf der Registry), dann atomar schreiben - ein falscher
Token ersetzt keinen funktionierenden. Getestet: gesetzt, unveraendert,
falsches Format, abgelehnter Token.
ESPO-30 holt <extension> <version> aus der Package Registry
EspoCRM_Packages: SHA-256 gegen die Registry, Name und Version gegen das
Manifest, kein Rueckschritt, Snapshot srv-vor-update vor dem Download,
Installation per command.php als www-data, Neustart und Warten auf
healthy, Nachweis ueber --list. Danach liegt keine ZIP mehr auf der VM -
auch EspoCRMs eigene Archive in data/upload/extensions werden entfernt;
Update und Deinstallation brauchen sie nicht (Quelle 10.0.8).
ESPO-20 misst espo_extensions ("Name Version; ...", "none" wenn leer) und
beschreibt den Leseweg der Version wieder richtig. Ring 0 sperrt den
Extension-Upload in der Oberflaeche. README: Nummernkreise nachgezogen,
verrutschte Zeilen der Verzeichnistabelle zurueckgeholt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
