Karte 896: Job-Limit auf 180 — das Step-Limit von 120 war durch den Vorlauf unerreichbar

[daniel-marthaler]

Mein eigener Restdefekt aus PR 71

Die Hierarchie „Job-Limit > Step-Limit" aus #71 stimmt arithmetisch (150 > 120), ignoriert aber
den Vorlauf vor dem OWASP-Schritt. Gemessen an zwei echten Laeufen am 17.08.2026:

                        fwtool 32014862052      root 32017744221
Job-Start               09:57:33Z               10:12:54Z
Setup JDK 25            20:00 min               20:02 min      <- feste Groesse (Cache-Restore)
SonarQube Analysis       1:08 min               11:00 min      <- root ist das groessere Repo
OWASP-CVE-Start         10:19:11Z               10:44:22Z
Vorlauf                 21:38 min               31:28 min

Bei root blieben damit real 118:32 Minuten fuer einen Schritt, der 120 haben darf — das
Step-Limit war unerreichbar. Der Lauf starb entsprechend:

Job-Limit  10:12:54Z + 150 = 12:42:54Z
Abbruch                       12:43:07Z    <- 13 s nach dem JOB-Limit
Step-Limit 10:44:22Z + 120 = 12:44:22Z     <- 75 s SPAETER, also nie erreicht

OWASP-CVE                     118:45 min, conclusion=cancelled
SpotBugs                      SKIPPED
Quality-Gate bewerten         SKIPPED
Quality-Gate-Statusfile …     SKIPPED
OWASP-Report als Artifact     success  (if: always())

Folge: cve.high.count bleibt in plaintext-root auf n/a — genau der Zustand, den Karte 896
beheben sollte, nur eine Ebene hoeher. Und bei einem Job-Timeout laufen nur noch die
if: always()-Schritte, und selbst die nicht alle (Artifact ja, Gate nein).

Aenderung

Job "SonarQube Analysis"   timeout-minutes: 150 -> 180

Rechnung statt Schaetzung: 31 (Vorlauf, gemessen) + 120 (OWASP-Step-Limit) + 1 (Gate + Commit +
Postgres-Stop) + 4 (Post-Setup JDK, gemessen 4:08) = 156, also 24 Minuten Reserve. Schoepft
SpotBugs sein eigenes Limit von 30 Minuten voll aus, reisst es — dann ist der CVE-Scan aber durch
und die Meldung erscheint. Real braucht SpotBugs 10 Sekunden (fwtool, gemessen).

Geprueft

nach der Aenderung:   Job=180  OWASP=120  ->  real fuer OWASP: 144 min   OK
gegen origin/master:  Job=150  OWASP=120  ->  real fuer OWASP: 114 min   PROBLEM (Positivkontrolle)

Die Pruefung rechnet den gemessenen Vorlauf (31) und Nachlauf (5) vom Job-Limit ab und vergleicht mit
dem Step-Limit — sie meldet den Zustand von master als Problem, also greift sie.

Der eigentliche Ausweg bleibt der NVD-API-Key (Karte 897)

Zwei Messungen, dieselbe Woche, dasselbe Werkzeug:

fwtool  auf nas-runner-org-twingate-1 (sauberer Cache, kein Lock)    98:35 min, success
root    auf nas-runner-org-2 (Cache mit liegengebliebenem Lock)     >118:45 min, abgebrochen

Ohne Key ist die Dauer damit nicht 98 Minuten, sondern zwischen 98 und mehr als 120 — abhaengig
davon, ob der Runner einen sauberen Bestand hat. Mit Key gehoeren Step auf ~30 und Job auf ~90
zurueck; das steht als Kommentar an der Zeile.

[skip-ci], weil nur ein Workflow geaendert wird.