diff --git a/.claude/commands/upstream-merge.md b/.claude/commands/upstream-merge.md new file mode 100644 index 0000000000..79693904db --- /dev/null +++ b/.claude/commands/upstream-merge.md @@ -0,0 +1,202 @@ +Führe den vollständigen Upstream-Merge-Workflow für pretix_cgo durch. Gehe dabei strikt Schritt für Schritt vor und warte an den markierten Stellen auf Bestätigung. + +--- + +## Schritt 1 – Master aktualisieren + +```bash +git checkout master +git pull +``` + +--- + +## Schritt 2 – Upstream-Tags holen & neuesten Tag ermitteln + +```bash +git fetch upstream --tags +``` + +Bestimme danach den neuesten upstream-Tag (Format `vYYYY.M.P`, **ohne** das `.0`-Suffix unserer eigenen Tags): + +```bash +git tag --sort=-version:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -1 +``` + +Merke dir diesen Tag als `UPSTREAM_TAG` (z.B. `v2026.5.0`) und leite daraus den Branch-Namen ab: `upstream/2026.5.0` (ohne führendes `v`). + +--- + +## Schritt 3 – Branch erstellen + +```bash +git checkout -b upstream/ tags/ +# Beispiel: git checkout -b upstream/2026.5.0 tags/v2026.5.0 +``` + +--- + +## Schritt 4 – Master mergen (immer, nicht optional) + +```bash +git merge master +``` + +Bei Merge-Konflikten: Konflikte anzeigen und gemeinsam mit dem Nutzer lösen, bevor es weitergeht. + +--- + +## Schritt 5 – Branch pushen & MR anlegen + +Push mit Push Option, damit Gitea direkt einen MR anlegt: + +```bash +git push --set-upstream origin upstream/ -o merge_request.create +``` + +--- + +## Schritt 6 – Gender-Prüfung in den deutschen Übersetzungen + +**Erst nach dem Merge mit master** die folgenden vier Dateien auf gegenderte Sprache prüfen: + +- `src/pretix/locale/de/LC_MESSAGES/django.po` +- `src/pretix/locale/de/LC_MESSAGES/djangojs.po` +- `src/pretix/locale/de_Informal/LC_MESSAGES/django.po` +- `src/pretix/locale/de_Informal/LC_MESSAGES/djangojs.po` + +Suche in den `msgstr`-Zeilen (und den zugehörigen `msgid`-Zeilen für Kontext) nach folgenden Mustern: + +| Muster | Beispiele | +|--------|-----------| +| Binneni mit `*` | `Teilnehmer*in`, `Käufer*innen` | +| Binneni mit `:` | `Teilnehmer:in`, `Käufer:innen` | +| Binneni mit `_` | `Teilnehmer_in`, `Käufer_innen` | +| Binneni mit `(in)` | `Teilnehmer(in)`, `Käufer(innen)` | +| Partizip-Plural auf `-enden` | `Teilnehmenden`, `Helfenden`, `Organisierenden`, `Bestellenden`, `Buchenden`, `Zahlenden` | + +**Ausgabe der Befunde:** Zeige für jeden Treffer: +1. Datei + Zeilennummer +2. Den vollständigen `msgstr`-Block (mehrzeilig wenn nötig) als Kontext +3. Den konkreten Vorschlag für die Ersetzung (z.B. `Teilnehmer*in` → `Teilnehmer`, `Teilnehmenden` → `Teilnehmer`) + +Warte dann auf Freigabe durch den Nutzer, bevor Änderungen vorgenommen werden. + +Nach Freigabe: Korrekturen direkt in den Dateien vornehmen und committen: + +```bash +git add src/pretix/locale/de/ src/pretix/locale/de_Informal/ +git commit -m "Remove gendered language from de/de_Informal translations" +git push +``` + +--- + +## Schritt 7 – Warten auf Merge-Bestätigung + +**Hier pausieren.** Den Nutzer auffordern zu bestätigen, sobald der MR auf Gitea gemergt wurde. + +--- + +## Schritt 8 – Master aktualisieren und neuen Tag vergeben + +Nach Bestätigung: + +```bash +git checkout master +git pull +``` + +Den neuen Tag ableiten: `.0` **ohne führendes `v`** (z.B. `v2026.5.0` → `2026.5.0.0`): + +```bash +git tag .0 +# Beispiel: git tag 2026.5.0.0 +git push origin .0 +``` + +Ausgabe: Bestätigung mit dem neuen Tag und kurzem Status. + +--- + +## Schritt 9 – Warten auf Build-Pipeline + +Nutze den Gitea MCP Server, um den Pipeline-Lauf für den soeben gepushten Tag zu überwachen: + +- **Repo:** `CGM_Public` / `pretix_cgo` +- **Methode:** `mcp__gitea__actions_run_read` mit `method: list_runs` +- Warte, bis ein Run mit dem passenden Ref (`refs/tags/`) den Status `success` erreicht. +- Prüfe alle ~30 Sekunden erneut und zeige dem Nutzer den aktuellen Status (running / success / failure). +- Bei `failure`: sofort stoppen und dem Nutzer melden. + +Erst wenn der Build erfolgreich (`success`) abgeschlossen ist, weitermachen. + +--- + +## Schritt 10 – cgm72 GitOps-Update + +Im GitOps-Repo unter `../OrtlerstrasseGitOps/` (liegt immer neben dem pretix_cgo-Repo): + +1. In `pretix-cgm72/pretix-deployment.yaml` den Image-Tag aktualisieren: + - Suche: `cr.ortlerstrasse.de/cgo/pretix:` + - Ersetze mit: `cr.ortlerstrasse.de/cgo/pretix:` (= der in Schritt 8 gesetzte Git-Tag, z.B. `2026.5.0.0`) + +2. Committen und pushen (im OrtlerstrasseGitOps-Verzeichnis): + +```bash +git -C ../OrtlerstrasseGitOps add pretix-cgm72/pretix-deployment.yaml +git -C ../OrtlerstrasseGitOps commit -m "Update pretix-cgm72 to " +git -C ../OrtlerstrasseGitOps push +``` + +Der GitOps-Operator wendet das YAML automatisch via `kubectl apply` an und rollt den Container neu aus. + +--- + +## Schritt 11 – cgm72: Container-Neustart abwarten und Loginseite prüfen + +Warte, bis der Container neu gestartet ist, und prüfe dann die Loginseite: + +- **URL:** `https://anmeldung.cgm72.de` +- **Prüfung:** HTTP 200 und die Seite enthält typische Pretix-Inhalte (z.B. Stichwort „pretix" oder ein Login-Formular im Body) + +Methode: Nutze `mcp__claude_ai_Simon_Fetch__fetch_page` (oder `curl -sI`), um die URL alle ~30 Sekunden abzurufen. Erwarte einen kurzen Ausfall während des Neustarts – warte danach auf eine erfolgreiche Antwort. + +Zeige dem Nutzer das Ergebnis (Status-Code + kurzen Seitenausschnitt als Bestätigung). + +--- + +## Schritt 12 – Manuelle Bestätigung für cgm72 + +**Hier pausieren.** Den Nutzer auffordern zu bestätigen, dass cgm72 korrekt funktioniert (`https://anmeldung.cgm72.de`), bevor mit sola fortgefahren wird. + +--- + +## Schritt 13 – sola GitOps-Update + +Im GitOps-Repo unter `../OrtlerstrasseGitOps/` (liegt immer neben dem pretix_cgo-Repo): + +1. In `pretix-sola/pretix-deployment.yaml` den Image-Tag aktualisieren: + - Suche: `cr.ortlerstrasse.de/cgo/pretix:` + - Ersetze mit: `cr.ortlerstrasse.de/cgo/pretix:` + +2. Committen und pushen: + +```bash +git -C ../OrtlerstrasseGitOps add pretix-sola/pretix-deployment.yaml +git -C ../OrtlerstrasseGitOps commit -m "Update pretix-sola to " +git -C ../OrtlerstrasseGitOps push +``` + +--- + +## Schritt 14 – sola: Container-Neustart abwarten und Loginseite prüfen + +Warte, bis der Container neu gestartet ist, und prüfe dann die Loginseite: + +- **URL:** `https://anmeldung.sola-muenchen.de` +- **Prüfung:** HTTP 200 und die Seite enthält typische Pretix-Inhalte + +Methode: wie in Schritt 11. + +Ausgabe: Bestätigung mit kurzem Abschluss-Status des gesamten Workflows. \ No newline at end of file