Code-Pruefung ans Deployment haengen, nicht nur an den Commit
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>
This commit is contained in:
Axel Hocks
co-authored by
Claude Opus 5
Claude Opus 5
parent
3f1f19087d
commit
0ab79f1876
@@ -4911,6 +4911,42 @@ Modell schliesst keine Trades.
|
||||
„die Rangfolge ist kaputt" ist **nicht** belegt; belegt ist nur die
|
||||
Basisraten-/Kalibrierungslücke.
|
||||
|
||||
## ⚠⚠ DIE PRÜFUNG HING AM COMMIT, NICHT AM DEPLOYMENT — behoben 2026-08-07
|
||||
|
||||
User-Frage „wird die Pipeline bei jedem Deployment ausgeführt?". **Antwort war
|
||||
NEIN**, und die Lücke war größer als sie aussah:
|
||||
| Weg zum Deployment | Prüfung vorher |
|
||||
|---|---|
|
||||
| `git commit` | ✅ `check_nfalle` + `pytest` (Hook installiert) |
|
||||
| `tools/deploy.py` | ⚠ prüfte nur den **laufenden Server** — nicht den Code |
|
||||
| `restart_server.bat` | ❌ gar nichts |
|
||||
| Aufgabe `OilTradingServer` (Logon/Reboot) → `start_server_hidden.vbs` | ❌ gar nichts |
|
||||
**Commit und Deployment sind zwei Ereignisse, und sie fallen beliebig
|
||||
auseinander:** eine geänderte, nie committete Datei ging über
|
||||
`restart_server.bat` ungeprüft live; nach einem Reboot startet die Aufgabe, was
|
||||
auf der Platte liegt.
|
||||
⚠ **„Der Server kommt hoch" ist KEIN Ersatz für die Prüfung** — 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.
|
||||
|
||||
✅ **GEBAUT: `tools/deploy.py` bekommt Schritt 0** — `check_nfalle` + `pytest`
|
||||
**VOR** dem Kill; bei Rot Abbruch mit Rückgabecode 1. Die Reihenfolge ist der
|
||||
Punkt: ein laufender, funktionierender Server darf für kaputten Code nicht
|
||||
abgeschossen werden. Notausgang `--ohne-pruefung` (Philosophie wie
|
||||
`git commit --no-verify`).
|
||||
✅ **Beide Richtungen verifiziert:** mit eingebautem `F821`-Fehler → „❌ ABBRUCH",
|
||||
Exit **1**, und die **Server-PID vorher/nachher identisch** (20892) — der
|
||||
laufende Prozess wurde nachweislich nicht angefasst; ohne Fehler läuft es durch.
|
||||
|
||||
⚠⚠ **BEWUSST NICHT in `restart_server.bat` und die Aufgabenplanung** — das ist
|
||||
die wichtigere Hälfte der Entscheidung. Das sind **Wiederanlauf**-Pfade. Würde
|
||||
ein fehlschlagender Test dort den Start verhindern, stünde eine offene Position
|
||||
ohne Trailing, Time-Stop und Notfall-Stop da — nur mit dem Broker-SL. **Eine
|
||||
Prüfung, die den Bot offline lässt, ist schlimmer als der Fehler, den sie
|
||||
sucht.** Der Batch gibt stattdessen einen **Hinweis** aus und verweist auf
|
||||
`deploy.py`; ein Kommentarblock hält die Begründung im Skript fest.
|
||||
**Regel: absichtliches Deployment blockieren, Wiederanlauf niemals.**
|
||||
|
||||
## ✅ LIVE↔BACKTEST-VERGLEICH IST JETZT TEIL DER PIPELINE (2026-08-07)
|
||||
|
||||
Konsequenz aus dem Messfehler direkt darunter: der Vergleich lief nur, wenn
|
||||
|
||||
@@ -16,6 +16,22 @@ set "PS=%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe"
|
||||
set "PY=C:\Users\ah\AppData\Local\Programs\Python\Python312\python.exe"
|
||||
set "HLDIR=%~dp0..\HyperLiquid-WTI Trader"
|
||||
|
||||
REM ------------------------------------------------------------
|
||||
REM ⚠ HIER LAEUFT BEWUSST KEINE CODE-PRUEFUNG (2026-08-07).
|
||||
REM Dieser Batch ist ein WIEDERANLAUF-Pfad (auch per Aufgabenplanung
|
||||
REM nach Reboot/Logon ueber start_server_hidden.vbs). Wuerde ein
|
||||
REM fehlschlagender Test den Start verhindern, staende eine offene
|
||||
REM Position ohne Trailing, Time-Stop und Notfall-Stop da - nur mit
|
||||
REM dem Broker-SL. Eine Pruefung, die den Bot offline laesst, ist
|
||||
REM schlimmer als der Fehler, den sie sucht.
|
||||
REM Fuer ein ABSICHTLICHES Deployment gibt es tools\deploy.py:
|
||||
REM das prueft VOR dem Kill und bricht bei Rot ab.
|
||||
REM ------------------------------------------------------------
|
||||
echo.
|
||||
echo [i] Hinweis: dieser Weg fuehrt KEINE Code-Pruefung aus.
|
||||
echo Absichtliches Deployment bitte ueber: python tools\deploy.py --feld ^<feld^>
|
||||
echo.
|
||||
|
||||
echo Beende laufende Server (8000 + 8001) ...
|
||||
"%PS%" -NoProfile -Command "Get-CimInstance Win32_Process | Where-Object { $_.Name -eq 'python.exe' -and $_.CommandLine -like '*server.py*' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force; Write-Host (' gestoppt: PID ' + $_.ProcessId) }; Start-Sleep -Seconds 2"
|
||||
|
||||
|
||||
@@ -9,6 +9,11 @@ NICHTS** über den geladenen Python-Code. Der Fehler fiel damals nur auf, weil e
|
||||
NEUES Snapshot-Feld fehlte (`hl_live.basis_stale`).
|
||||
|
||||
Dieses Skript macht daraus einen prüfbaren Ablauf:
|
||||
0. CODE pruefen (check_nfalle + pytest) — VOR dem Kill, damit ein
|
||||
laufender Server nicht fuer kaputten Code abgeschossen wird.
|
||||
⚠ Ergaenzt 2026-08-07: die Pruefung hing bis dahin am COMMIT, nicht
|
||||
am Deployment. Eine nie committete Datei ging ueber
|
||||
`restart_server.bat` ungeprueft live.
|
||||
1. Prozess auf dem Port gezielt beenden — **nicht** per `*server.py*`-Muster,
|
||||
das trifft auch das Hyperliquid-Dashboard auf 8001 (real passiert: der
|
||||
HL-Server wurde bei jedem MT5-Neustart still mit-erschlagen und riss die
|
||||
@@ -27,6 +32,7 @@ Aufruf:
|
||||
python tools/deploy.py --feld rec_track # zusätzlich Code-Neuheit belegen
|
||||
python tools/deploy.py --hl # HL-Dashboard (8001) mitnehmen
|
||||
python tools/deploy.py --nur-pruefen # nichts anfassen, nur Zustand
|
||||
python tools/deploy.py --ohne-pruefung # Notausgang: Schritt 0 aus
|
||||
"""
|
||||
import argparse
|
||||
import json
|
||||
@@ -76,6 +82,8 @@ def main() -> int:
|
||||
ap.add_argument("--feld", help="Snapshot-Feld, das den neuen Code belegt")
|
||||
ap.add_argument("--hl", action="store_true", help="HL-Dashboard (8001) mit")
|
||||
ap.add_argument("--nur-pruefen", action="store_true")
|
||||
ap.add_argument("--ohne-pruefung", action="store_true",
|
||||
help="Code-Prüfung überspringen (Notausgang, s. Schritt 0)")
|
||||
a = ap.parse_args()
|
||||
|
||||
print("=" * 74)
|
||||
@@ -90,6 +98,31 @@ def main() -> int:
|
||||
print(f" Snapshot: {'antwortet' if s else 'KEINE Antwort'}")
|
||||
return 0 if s else 1
|
||||
|
||||
# ── 0) CODE prüfen, BEVOR der laufende Server angefasst wird ─────────
|
||||
# ⚠⚠ WARUM DAS HIER DAZUKAM (2026-08-07, User-Frage „wird die Pipeline bei
|
||||
# jedem Deployment ausgeführt?"). Antwort war NEIN: die Prüfung hing am
|
||||
# COMMIT, nicht am Deployment — und das sind zwei Ereignisse, die beliebig
|
||||
# auseinanderfallen. Eine geänderte, nie committete Datei ging über
|
||||
# `restart_server.bat` ungeprüft live.
|
||||
# ⚠ Dass der Server hochkommt, 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. Genau solche
|
||||
# Fehler findet `pytest`/`ruff`, nicht der Startvorgang.
|
||||
# ⚠ Die Prüfung läuft VOR dem Kill — ein laufender, funktionierender Server
|
||||
# darf nicht für kaputten Code abgeschossen werden.
|
||||
if not a.ohne_pruefung:
|
||||
schritt(0, "Code prüfen (check_nfalle + pytest) …")
|
||||
r = subprocess.run([PY, "-X", "utf8", str(WURZEL / "tools" / "pre_commit.py")],
|
||||
cwd=WURZEL, capture_output=True, text=True)
|
||||
for z in (r.stdout or "").strip().splitlines():
|
||||
print(f" {z}")
|
||||
if r.returncode != 0:
|
||||
print(" ❌ ABBRUCH — der laufende Server bleibt unangetastet.")
|
||||
print(" Beheben, oder bewusst übergehen: --ohne-pruefung")
|
||||
return 1
|
||||
else:
|
||||
print(" [0] Code-Prüfung ÜBERSPRUNGEN (--ohne-pruefung) ⚠")
|
||||
|
||||
# ── 1) gezielt beenden ───────────────────────────────────────────────
|
||||
alt = pids(PORT)
|
||||
schritt(1, f"Port {PORT}: {alt or 'nichts'} → beenden")
|
||||
|
||||
Reference in New Issue
Block a user