Nach #93 liegt der CI-Lauf bei 6 min 48 s (Task 53 auf 7e5003b, gruen, 930 checks).
Die Phasen, gemessen aus dem Job-Log:
Phase
Dauer
checkout + npm ci
9 s
./check.sh (Gate)
83 s
npm run build
16 s
tools/ci/run-e2e.sh
251 s
tools/ci/run-smokes.sh
45 s
Das Gate haengt an nichts: es braucht weder den Build noch den Server. Heute laeuft es trotzdem
davor und blockiert build + e2e + smokes um 83 s.
Vorschlag
.gitea/workflows/ci.yml in zwei Jobs teilen:
gate — checkout, npm ci, ./check.sh
suite — checkout, npm ci, npm run build, tools/ci/run-e2e.sh, tools/ci/run-smokes.sh
Ohne needs: laufen beide parallel. Der Runner hat capacity: 2, der Host 4 Kerne — zwei Jobs
gleichzeitig sind moeglich.
Was dagegen spricht (ehrlich gemessen werden muss)
Der Gewinn ist kleiner als 83 s. Der zweite Job zahlt checkout + npm ci noch einmal
(9 s) und faengt frueher an, aber suite endet trotzdem erst nach seinen 312 s. Netto also
maximal ~83 s, wenn sich die Jobs nicht gegenseitig ausbremsen.
Sie bremsen sich womoeglich doch.check.sh (vitest, mehrere Worker) und der e2e-Lauf
(Chromium + GPU) teilen sich dann 4 Kerne. Es kann sein, dass e2e dadurch langsamer wird und
unterm Strich nichts uebrig bleibt — schlimmstenfalls flattern zeitabhaengige Checks.
Das ist der eigentliche Grund, warum es ein eigenes Issue ist und nicht Teil von #93 war.
Zwei Job-Container heisst zwei Mal die GPU durchgereicht (die container.options des
Runners gelten runner-weit). Fuer das Gate ist das unnoetig, stoert aber nicht.
Abnahme
Gemessen wird an der Gesamtlaufzeit ueber mindestens zwei Laeufe, nicht an der Theorie.
Bleibt e2e in derselben Groessenordnung (251 s ± wenig) und faellt die Gesamtzeit unter 6 min,
ist es die Aufteilung wert. Wird e2e langsamer oder flattert ein Check, wird zurueckgebaut —
dann ist die serielle Reihenfolge das Richtige und das Issue wird mit dieser Messung geschlossen.
Nach #93 liegt der CI-Lauf bei **6 min 48 s** (Task 53 auf `7e5003b`, gruen, 930 checks).
Die Phasen, gemessen aus dem Job-Log:
| Phase | Dauer |
|---|---|
| checkout + `npm ci` | 9 s |
| `./check.sh` (Gate) | **83 s** |
| `npm run build` | 16 s |
| `tools/ci/run-e2e.sh` | 251 s |
| `tools/ci/run-smokes.sh` | 45 s |
Das Gate haengt an nichts: es braucht weder den Build noch den Server. Heute laeuft es trotzdem
davor und blockiert `build + e2e + smokes` um 83 s.
## Vorschlag
`.gitea/workflows/ci.yml` in zwei Jobs teilen:
- `gate` — checkout, `npm ci`, `./check.sh`
- `suite` — checkout, `npm ci`, `npm run build`, `tools/ci/run-e2e.sh`, `tools/ci/run-smokes.sh`
Ohne `needs:` laufen beide parallel. Der Runner hat `capacity: 2`, der Host 4 Kerne — zwei Jobs
gleichzeitig sind moeglich.
## Was dagegen spricht (ehrlich gemessen werden muss)
1. **Der Gewinn ist kleiner als 83 s.** Der zweite Job zahlt checkout + `npm ci` noch einmal
(9 s) und faengt frueher an, aber `suite` endet trotzdem erst nach seinen 312 s. Netto also
maximal ~83 s, wenn sich die Jobs nicht gegenseitig ausbremsen.
2. **Sie bremsen sich womoeglich doch.** `check.sh` (vitest, mehrere Worker) und der e2e-Lauf
(Chromium + GPU) teilen sich dann 4 Kerne. Es kann sein, dass e2e dadurch langsamer wird und
unterm Strich nichts uebrig bleibt — schlimmstenfalls flattern zeitabhaengige Checks.
Das ist der eigentliche Grund, warum es ein eigenes Issue ist und nicht Teil von #93 war.
3. **Zwei Job-Container heisst zwei Mal die GPU durchgereicht** (die `container.options` des
Runners gelten runner-weit). Fuer das Gate ist das unnoetig, stoert aber nicht.
## Abnahme
Gemessen wird an der Gesamtlaufzeit ueber mindestens zwei Laeufe, nicht an der Theorie.
Bleibt e2e in derselben Groessenordnung (251 s ± wenig) und faellt die Gesamtzeit unter 6 min,
ist es die Aufteilung wert. Wird e2e langsamer oder flattert ein Check, wird zurueckgebaut —
dann ist die serielle Reihenfolge das Richtige und das Issue wird mit dieser Messung geschlossen.
Commit 15bdfdf — .gitea/workflows/ci.yml hat jetzt zwei Jobs ohne needs:: gate (checkout, install, check.sh) und suite (checkout, install, build, e2e, smokes).
Dazu liest vite.config.ts die Worker-Zahl aus GM_TEST_WORKERS und der Gate-Job setzt sie
auf 2 — das ist die Antwort auf das Gegenargument aus dem Eröffnungspost: vitest startet sonst
einen Worker je Kern, und die Suite misst in derselben Phase Textbreiten und Frame-Zahlen.
Der erste parallele Lauf (Task 58 gate + 59 suite, beide auf 15bdfdf, beide grün)
Phase
CI-57 (seriell, 36ccc76)
CI-58/59 (parallel, 15bdfdf)
checkout + npm ci
6,3 s
9,4 s
Gate (check.sh)
50,3 s (im selben Job)
89,5 s (eigener Job, daneben)
Build
12,5 s
17,1 s
e2e
266,1 s
272,0 s
Smokes
45,3 s
45,4 s
Wanduhr gesamt
382 s (6:22)
344 s (5:44)
−38 s, also 10 %. Weniger als die ~50 s meiner Rechnung, und deutlich weniger als die 83 s,
mit denen dieses Issue eröffnet wurde — die 83 s waren ein Ausreißer (Task 53, erster Lauf nach
dem #93-Umbau); stabil lag der Gate bei 50 s.
Was die Überlappung kostet — ehrlich benannt
Der Gate-Job dauert selbst 89,5 s statt 50 s. Er wartet, wo er vorher alleine rechnete:
eigener checkout + npm ci, zwei Worker statt vier, und daneben läuft Chromium.
Für die Wanduhr ist das egal, weil er komplett in der e2e-Phase verschwindet.
Build 12,5 → 17,1 s und e2e 266,1 → 272,0 s (+2 %) — das ist die Kern-Konkurrenz,
gemessen, nicht vermutet.
ALL PASSED – 958 checks, Smokes 24 / 19 / 21 — identisch zu CI-57. Kein zeitabhängiger
Check ist geflattert, das war das eigentliche Risiko.
Der Grund, der mehr wert ist als die 38 s
Ein Lint- oder Typfehler kostete bisher den vollen e2e-Lauf, bevor er gemeldet wurde: die Nachricht
kam nach sechs Minuten. Jetzt meldet der Gate ihn nach 90 Sekunden, während die Suite noch dreht.
Dazu steht im UI zweierlei getrennt da statt einer langen Kette — rot ist damit sofort zuzuordnen.
Einschränkung
Die Abnahme in diesem Issue verlangte eine Messung über mindestens zwei Läufe; belegt ist bisher einer. Die Entscheidung, trotzdem zu schließen, ist die des Users. Sollte die e2e-Zeit in den
nächsten Läufen deutlicher steigen als die gemessenen 2 %, gehört das hier wieder aufgemacht —
der Rückbau ist eine Datei und klein.
## Gebaut, gemessen, angenommen
Commit `15bdfdf` — `.gitea/workflows/ci.yml` hat jetzt zwei Jobs ohne `needs:`:
`gate` (checkout, install, `check.sh`) und `suite` (checkout, install, build, e2e, smokes).
Dazu liest `vite.config.ts` die Worker-Zahl aus `GM_TEST_WORKERS` und der Gate-Job setzt sie
auf `2` — das ist die Antwort auf das Gegenargument aus dem Eröffnungspost: vitest startet sonst
einen Worker je Kern, und die Suite misst in derselben Phase Textbreiten und Frame-Zahlen.
### Der erste parallele Lauf (Task 58 `gate` + 59 `suite`, beide auf `15bdfdf`, beide grün)
| Phase | CI-57 (seriell, `36ccc76`) | CI-58/59 (parallel, `15bdfdf`) |
|---|---|---|
| checkout + `npm ci` | 6,3 s | 9,4 s |
| **Gate (`check.sh`)** | **50,3 s** (im selben Job) | **89,5 s** (eigener Job, daneben) |
| Build | 12,5 s | 17,1 s |
| e2e | 266,1 s | 272,0 s |
| Smokes | 45,3 s | 45,4 s |
| **Wanduhr gesamt** | **382 s (6:22)** | **344 s (5:44)** |
**−38 s, also 10 %.** Weniger als die ~50 s meiner Rechnung, und deutlich weniger als die 83 s,
mit denen dieses Issue eröffnet wurde — die 83 s waren ein Ausreißer (Task 53, erster Lauf nach
dem #93-Umbau); stabil lag der Gate bei 50 s.
### Was die Überlappung kostet — ehrlich benannt
- Der **Gate-Job dauert selbst 89,5 s statt 50 s.** Er wartet, wo er vorher alleine rechnete:
eigener checkout + `npm ci`, zwei Worker statt vier, und daneben läuft Chromium.
Für die Wanduhr ist das egal, weil er komplett in der e2e-Phase verschwindet.
- **Build 12,5 → 17,1 s** und **e2e 266,1 → 272,0 s (+2 %)** — das ist die Kern-Konkurrenz,
gemessen, nicht vermutet.
- **`ALL PASSED – 958 checks`, Smokes 24 / 19 / 21** — identisch zu CI-57. Kein zeitabhängiger
Check ist geflattert, das war das eigentliche Risiko.
### Der Grund, der mehr wert ist als die 38 s
Ein Lint- oder Typfehler kostete bisher den vollen e2e-Lauf, bevor er gemeldet wurde: die Nachricht
kam nach sechs Minuten. Jetzt meldet der Gate ihn nach 90 Sekunden, während die Suite noch dreht.
Dazu steht im UI zweierlei getrennt da statt einer langen Kette — rot ist damit sofort zuzuordnen.
### Einschränkung
Die Abnahme in diesem Issue verlangte eine Messung über **mindestens zwei** Läufe; belegt ist bisher
**einer**. Die Entscheidung, trotzdem zu schließen, ist die des Users. Sollte die e2e-Zeit in den
nächsten Läufen deutlicher steigen als die gemessenen 2 %, gehört das hier wieder aufgemacht —
der Rückbau ist eine Datei und klein.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nach #93 liegt der CI-Lauf bei 6 min 48 s (Task 53 auf
7e5003b, gruen, 930 checks).Die Phasen, gemessen aus dem Job-Log:
npm ci./check.sh(Gate)npm run buildtools/ci/run-e2e.shtools/ci/run-smokes.shDas Gate haengt an nichts: es braucht weder den Build noch den Server. Heute laeuft es trotzdem
davor und blockiert
build + e2e + smokesum 83 s.Vorschlag
.gitea/workflows/ci.ymlin zwei Jobs teilen:gate— checkout,npm ci,./check.shsuite— checkout,npm ci,npm run build,tools/ci/run-e2e.sh,tools/ci/run-smokes.shOhne
needs:laufen beide parallel. Der Runner hatcapacity: 2, der Host 4 Kerne — zwei Jobsgleichzeitig sind moeglich.
Was dagegen spricht (ehrlich gemessen werden muss)
npm cinoch einmal(9 s) und faengt frueher an, aber
suiteendet trotzdem erst nach seinen 312 s. Netto alsomaximal ~83 s, wenn sich die Jobs nicht gegenseitig ausbremsen.
check.sh(vitest, mehrere Worker) und der e2e-Lauf(Chromium + GPU) teilen sich dann 4 Kerne. Es kann sein, dass e2e dadurch langsamer wird und
unterm Strich nichts uebrig bleibt — schlimmstenfalls flattern zeitabhaengige Checks.
Das ist der eigentliche Grund, warum es ein eigenes Issue ist und nicht Teil von #93 war.
container.optionsdesRunners gelten runner-weit). Fuer das Gate ist das unnoetig, stoert aber nicht.
Abnahme
Gemessen wird an der Gesamtlaufzeit ueber mindestens zwei Laeufe, nicht an der Theorie.
Bleibt e2e in derselben Groessenordnung (251 s ± wenig) und faellt die Gesamtzeit unter 6 min,
ist es die Aufteilung wert. Wird e2e langsamer oder flattert ein Check, wird zurueckgebaut —
dann ist die serielle Reihenfolge das Richtige und das Issue wird mit dieser Messung geschlossen.
Gebaut, gemessen, angenommen
Commit
15bdfdf—.gitea/workflows/ci.ymlhat jetzt zwei Jobs ohneneeds::gate(checkout, install,check.sh) undsuite(checkout, install, build, e2e, smokes).Dazu liest
vite.config.tsdie Worker-Zahl ausGM_TEST_WORKERSund der Gate-Job setzt sieauf
2— das ist die Antwort auf das Gegenargument aus dem Eröffnungspost: vitest startet sonsteinen Worker je Kern, und die Suite misst in derselben Phase Textbreiten und Frame-Zahlen.
Der erste parallele Lauf (Task 58
gate+ 59suite, beide auf15bdfdf, beide grün)36ccc76)15bdfdf)npm cicheck.sh)−38 s, also 10 %. Weniger als die ~50 s meiner Rechnung, und deutlich weniger als die 83 s,
mit denen dieses Issue eröffnet wurde — die 83 s waren ein Ausreißer (Task 53, erster Lauf nach
dem #93-Umbau); stabil lag der Gate bei 50 s.
Was die Überlappung kostet — ehrlich benannt
eigener checkout +
npm ci, zwei Worker statt vier, und daneben läuft Chromium.Für die Wanduhr ist das egal, weil er komplett in der e2e-Phase verschwindet.
gemessen, nicht vermutet.
ALL PASSED – 958 checks, Smokes 24 / 19 / 21 — identisch zu CI-57. Kein zeitabhängigerCheck ist geflattert, das war das eigentliche Risiko.
Der Grund, der mehr wert ist als die 38 s
Ein Lint- oder Typfehler kostete bisher den vollen e2e-Lauf, bevor er gemeldet wurde: die Nachricht
kam nach sechs Minuten. Jetzt meldet der Gate ihn nach 90 Sekunden, während die Suite noch dreht.
Dazu steht im UI zweierlei getrennt da statt einer langen Kette — rot ist damit sofort zuzuordnen.
Einschränkung
Die Abnahme in diesem Issue verlangte eine Messung über mindestens zwei Läufe; belegt ist bisher
einer. Die Entscheidung, trotzdem zu schließen, ist die des Users. Sollte die e2e-Zeit in den
nächsten Läufen deutlicher steigen als die gemessenen 2 %, gehört das hier wieder aufgemacht —
der Rückbau ist eine Datei und klein.