Karte 896: Job-Timeout ueber das Step-Timeout heben — sonst greift continue-on-error am CVE-Scan nie

[daniel-marthaler]

Der Fehler, der zwei fruehere Fixes unwirksam gemacht hat

Job und OWASP-Schritt standen beide auf timeout-minutes: 90. Der Job startet aber immer
zuerst, also greift sein Limit zuerst — gemessen am 17.08.2026 in plaintext-schuetu (Lauf
31995201432):

05:03:25Z  Job "SonarQube Analysis" startet         -> Job-Limit endet 06:33:25Z
05:06:55Z  Schritt "OWASP-CVE" startet              -> Schritt-Limit endet 06:36:55Z
06:33:37Z  ##[error]The operation was canceled.     <- das JOB-Limit, 3,5 Min vor dem Schritt

Folge: der Lauf endet auf cancelled, das continue-on-error: true am Schritt kommt nie zum
Tragen, und die dort vorgesehene Meldung

|| echo "::error::OWASP-CVE-Scan NICHT gelaufen — es entsteht kein Report, und das Quality-Gate …"

wird nie ausgefuehrt. Genau deshalb war der Timeout-Fix aus Karte 420 (30 -> 90 Minuten) ohne
Wirkung, und genau deshalb steht in allen sechs quality-gate.properties weiterhin
cve.high.count=n/a — der Zustand, den Karte 604 beschrieben hat.

Alle fuenf Wochenlaeufe des 17.08. bestaetigen es: 90:19 · 90:20 · 90:20 · 90:22 · 90:44 Minuten.
Fuenfmal das Job-Limit, keine einzige echte Laufzeit. Der Kommentar im Schritt („Der naechste
Weekly liefert die erste echte Dauer") konnte sich damit nicht erfuellen.

Aenderung

Job "SonarQube Analysis"   timeout-minutes: 90 -> 150
Schritt "OWASP-CVE"        timeout-minutes: 90 -> 120

Warum 120 am Schritt: Ohne NVD_API_KEY braucht allein der NVD-Download rund 96 Minuten —
gemessen 84 Minuten fuer 330.000 von 378.426 Eintraegen, dann Abbruch bei 87 %. Mit 90 stirbt er
jedes Mal kurz vor dem Ziel; der persistente Cache in $HOME/.cache/owasp-dc-data bleibt
unvollstaendig (auf den vier Runnern gemessen: 411 · 527 · 647 · 722 MB, jeder anders weit) und der
Zustand erhaelt sich selbst. Mit 120 wird der Cache einmal fertig, danach laeuft der Scan
inkrementell in Minuten.

Warum 150 am Job: damit das Job-Limit ueber dem Schritt-Limit liegt und continue-on-error
ueberhaupt greifen kann. Das ist der eigentliche Fix — ohne ihn bliebe jeder weitere
Timeout-Wert wirkungslos.

Der eigentliche Ausweg bleibt der NVD-API-Key (Karte 897, ein Handgriff Daniels): mit Key ist
das Rate-Limit zehnmal hoeher. Sobald er gesetzt ist, gehoert das Schritt-Limit zurueck auf ~30 —
das steht als Kommentar an der Zeile.

Geprueft

Ein Skript liest die YAML und vergleicht jedes Job-Limit mit dem groessten Step-Limit
darin:

nach der Aenderung:   sonar Job=150  groesstes Step-Limit=120   OK        -> 0 Jobs mit Problem
gegen origin/master:  sonar Job=90   groesstes Step-Limit=90    PROBLEM   (Positivkontrolle)
                      "Step 90 coe=True 'OWASP-CVE' — continue-on-error greift nie"

Die uebrigen Jobs (ci, deploy, namespace-lint) haben gar kein Job-Limit, dort kann die
Kollision nicht auftreten; verify-dev/verify-prod ebenso.

Nebenbefund, bewusst nicht mitgeaendert

ci und deploy haben kein timeout-minutes — fuer sie gilt GitHubs Vorgabe von sechs
Stunden. Ein haengender Deploy-Job blockiert damit sechs Stunden lang die Gruppe
deploy-<project>. Das ist derselbe Fall, den Karte 365 fuer fwtool beschrieben hat, nur an einer
anderen Stelle. Nicht Teil dieses PRs, weil ein zu knapper Wert einen laufenden Blue-Green-Deploy
mitten im Umschalten abschneiden koennte — das gehoert gemessen, nicht geschaetzt.

Nicht geprueft

Ob 120 Minuten fuer den Download tatsaechlich reichen. Die 96 Minuten sind aus 84 Minuten fuer 87 %
linear fortgeschrieben; die letzten Prozente koennen langsamer sein. Der naechste Wochenlauf sagt
es — und diesmal kann er es sagen, weil der Job nicht mehr vorher abbricht.