User-Frage "wird die Pipeline bei jedem Deployment ausgefuehrt?". Antwort war
NEIN:
git commit check_nfalle + pytest (Hook installiert)
tools/deploy.py prueft nur den LAUFENDEN Server, nicht den Code
restart_server.bat gar nichts
Aufgabe OilTradingServer -> start_server_hidden.vbs gar nichts
Commit und Deployment sind zwei Ereignisse und fallen beliebig auseinander:
eine geaenderte, nie committete Datei ging ueber restart_server.bat ungeprueft
live; nach einem Reboot startet die Aufgabe, was auf der Platte liegt.
"Der Server kommt hoch" ist kein Ersatz: die beiden log.-NameError in
core/trader.py sassen MONATE in except-Zweigen (einer seit dem Initial-Commit),
und der Server startete jedes Mal sauber.
deploy.py bekommt Schritt 0: check_nfalle + pytest VOR dem Kill, bei Rot
Abbruch mit Rueckgabecode 1. Die Reihenfolge ist der Punkt - ein laufender,
funktionierender Server darf fuer kaputten Code nicht abgeschossen werden.
Notausgang --ohne-pruefung.
Beide Richtungen verifiziert: mit eingebautem F821-Fehler -> ABBRUCH, Exit 1,
Server-PID vorher/nachher identisch (20892), der Prozess wurde nachweislich
nicht angefasst. Ohne Fehler laeuft es durch.
BEWUSST NICHT in restart_server.bat und die Aufgabenplanung - das sind
WIEDERANLAUF-Pfade. Wuerde ein fehlschlagender Test dort den Start verhindern,
staende eine offene Position ohne Trailing, Time-Stop und Notfall-Stop da, nur
mit dem Broker-SL. Eine Pruefung, die den Bot offline laesst, ist schlimmer als
der Fehler, den sie sucht. Der Batch gibt stattdessen einen Hinweis aus und
verweist auf deploy.py.
Regel: absichtliches Deployment blockieren, Wiederanlauf niemals.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ersetzt das von Hand zusammengesetzte "killen, starten, warten, nachsehen" —
und macht die dokumentierte Schwachstelle der Pipeline pruefbar.
Fuenf Schritte, Rueckgabecode 0 nur wenn alle durchlaufen (verkettbar):
1. Prozess GEZIELT AM PORT beenden — nicht per *server.py*-Muster wie
restart_server.bat, das trifft auch das HL-Dashboard auf 8001 (real: es
wurde bei jedem MT5-Neustart still mit-erschlagen und riss die Luecken in
die Lead-Lag- und Order-Flow-Datensammlung).
2. starten und warten, bis /api/snapshot WIRKLICH antwortet.
3. genau EINE Instanz je Port.
4. --feld <name> pruefen.
5. Log AB DER STARTPOSITION auf ERROR/Traceback.
Schritt 4 ist der Kern: restart_server.bat hat zweimal still nicht neu
gestartet, und weil statische Dateien je Request frisch von der Platte gelesen
werden, belegt eine korrekt ausgelieferte app.js?v=N gar nichts ueber den
geladenen Python-Code. Ein neues Snapshot-Feld ist der einzige belastbare
Beweis — genau daran fiel der Fehler am 02.08. auf (hl_live.basis_stale). Ohne
--feld sagt das Skript ausdruecklich, dass der Beweis fehlt.
Beide Richtungen geprueft:
--feld rec_track -> "Python-Code ist neu", Exit 0
--feld dieses_feld_gibt_es_nicht -> "FEHLT - der alte Code laeuft weiter!",
Exit 1
Eine Pruefung, die nicht scheitern kann, waere wertlos.
Aufrufe:
python tools/deploy.py --feld <snapshot_feld>
python tools/deploy.py --nur-pruefen
python tools/deploy.py --hl
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
