[GH#428] CI: Nightly Fuzz-Run und Test-Report (erweiterte CI-Pipeline) #21

New issue

Open

opened 2026-05-19 22:15:39 +02:00 by Max · 0 comments

Max commented

2026-05-19 22:15:39 +02:00

Owner

Migrated from GitHub #428
Originally created by @Bio1988 on 2026-05-05T13:00:19Z

Motivation

Fuzz-Tests und ausführliche Concurrency-Stress-Tests dauern zu lange für den normalen CI-Lauf (PR → Merge). Diese sollen als Nightly-Build laufen der:

Fuzz-Tests für 5+ Minuten pro Target laufen lässt
Concurrency-Stress-Tests mit hoher Iteration count
Coverage-Trend über Zeit trackt
Vollständigen Test-Report generiert

Scope

Neuer Workflow: `.github/workflows/07-nightly.yml`

Trigger: Schedule (täglich 03:00 UTC) + manuell dispatchbar

Jobs:

1. fuzz Job (opencode-build Runner):

go test -fuzz=FuzzParse -fuzztime=5m ./irsdk/...
go test -fuzz=FuzzParse -fuzztime=5m ./internal/recording/infrastructure/...
go test -fuzz=FuzzParse -fuzztime=5m ./internal/sync/infrastructure/...
Abbruch bei Crash/Fail, Report als Issue-Comment oder Notification
Fuzz-Corpus in .github/cache/fuzz/ persistieren (lässt Corpus über Runs wachsen)

2. stress Job (opencode-build Runner):

Runtime Concurrency Tests: -race -count=1000 -timeout=30m
SQLite Concurrent-Access Tests: -race -count=100
Audio Priority-Queue Tests: -race -count=500

3. coverage-report Job (opencode-maintenance Runner):

Full Coverage Profile generieren
HTML-Report als Artifact uploaden (7 Tage Retention)
Coverage-Trend: vergleiche mit vorherigem Run (in .github/cache/coverage/)
Warnung wenn Coverage um >2% gesunken

4. report Job:

Sammle Ergebnisse aller Jobs
Post Kommentar auf fixed "Nightly Report" Issue (#TBD) mit:
- Fuzz: Anzahl Input-Bytes verarbeitet, Crashes gefunden
- Stress: Anzahl Iterationen, Race Conditions gefunden
- Coverage: Aktuell vs. Vorher (% Änderung)
- Gesamt-Status: Pass/Fail

Edge Cases

Runner offline → Nightly überspringen (kein Alarm bei einmaligem Ausfall)
Fuzz-Corpus wächst unendlich → Cleanup auf 100MB Limit
Coverage-Vergleich bei erstem Run → Kein Trend, nur aktueller Wert
Sehr langsamer Fuzz-Run → Timeout nach 30 Minuten pro Target

Acceptance Criteria

07-nightly.yml Workflow existiert und läuft täglich um 03:00 UTC
Manuell dispatchbar mit Optionen: targets (all/fuzz/stress/coverage), duration
Fuzz-Tests laufen für konfigurierbare Dauer (default 5m pro Target)
Stress-Tests laufen mit hoher Iteration-Count
Coverage-Report als HTML-Artifact
Zusammenfassender Report als Issue-Comment
Graceful Handling bei Runner-Offline

Affected Files

.github/workflows/07-nightly.yml — neuer Workflow
.github/cache/fuzz/ — Fuzz-Corpus Persistenz (gitignored)
.github/cache/coverage/ — Coverage-Trend Persistenz

Dependencies

Issue #420 (Fuzz-Tests) — Fuzz-Targets müssen existieren
Issue #423 (Concurrency Tests) — Stress-Test-Targets müssen existieren

Migrated from [GitHub #428](https://github.com/Bio1988/strategy-desktop/issues/428) Originally created by @Bio1988 on 2026-05-05T13:00:19Z --- ## Motivation Fuzz-Tests und ausführliche Concurrency-Stress-Tests dauern zu lange für den normalen CI-Lauf (PR → Merge). Diese sollen als Nightly-Build laufen der: 1. Fuzz-Tests für 5+ Minuten pro Target laufen lässt 2. Concurrency-Stress-Tests mit hoher Iteration count 3. Coverage-Trend über Zeit trackt 4. Vollständigen Test-Report generiert ## Scope ### Neuer Workflow: `.github/workflows/07-nightly.yml` **Trigger:** Schedule (täglich 03:00 UTC) + manuell dispatchbar **Jobs:** **1. `fuzz` Job (opencode-build Runner):** - `go test -fuzz=FuzzParse -fuzztime=5m ./irsdk/...` - `go test -fuzz=FuzzParse -fuzztime=5m ./internal/recording/infrastructure/...` - `go test -fuzz=FuzzParse -fuzztime=5m ./internal/sync/infrastructure/...` - Abbruch bei Crash/Fail, Report als Issue-Comment oder Notification - Fuzz-Corpus in `.github/cache/fuzz/` persistieren (lässt Corpus über Runs wachsen) **2. `stress` Job (opencode-build Runner):** - Runtime Concurrency Tests: `-race -count=1000 -timeout=30m` - SQLite Concurrent-Access Tests: `-race -count=100` - Audio Priority-Queue Tests: `-race -count=500` **3. `coverage-report` Job (opencode-maintenance Runner):** - Full Coverage Profile generieren - HTML-Report als Artifact uploaden (7 Tage Retention) - Coverage-Trend: vergleiche mit vorherigem Run (in `.github/cache/coverage/`) - Warnung wenn Coverage um >2% gesunken **4. `report` Job:** - Sammle Ergebnisse aller Jobs - Post Kommentar auf fixed "Nightly Report" Issue (#TBD) mit: - Fuzz: Anzahl Input-Bytes verarbeitet, Crashes gefunden - Stress: Anzahl Iterationen, Race Conditions gefunden - Coverage: Aktuell vs. Vorher (% Änderung) - Gesamt-Status: Pass/Fail ### Edge Cases - Runner offline → Nightly überspringen (kein Alarm bei einmaligem Ausfall) - Fuzz-Corpus wächst unendlich → Cleanup auf 100MB Limit - Coverage-Vergleich bei erstem Run → Kein Trend, nur aktueller Wert - Sehr langsamer Fuzz-Run → Timeout nach 30 Minuten pro Target ## Acceptance Criteria - [ ] `07-nightly.yml` Workflow existiert und läuft täglich um 03:00 UTC - [ ] Manuell dispatchbar mit Optionen: targets (all/fuzz/stress/coverage), duration - [ ] Fuzz-Tests laufen für konfigurierbare Dauer (default 5m pro Target) - [ ] Stress-Tests laufen mit hoher Iteration-Count - [ ] Coverage-Report als HTML-Artifact - [ ] Zusammenfassender Report als Issue-Comment - [ ] Graceful Handling bei Runner-Offline ## Affected Files - `.github/workflows/07-nightly.yml` — neuer Workflow - `.github/cache/fuzz/` — Fuzz-Corpus Persistenz (gitignored) - `.github/cache/coverage/` — Coverage-Trend Persistenz ## Dependencies - Issue #420 (Fuzz-Tests) — Fuzz-Targets müssen existieren - Issue #423 (Concurrency Tests) — Stress-Test-Targets müssen existieren

Max added the

labels

2026-05-19 22:15:39 +02:00