mirror of
https://github.com/pretix/pretix.git
synced 2026-08-10 10:47:00 +00:00
Add claude skill
This commit is contained in:
@@ -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/<VERSION> tags/<UPSTREAM_TAG>
|
||||
# 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/<VERSION> -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: `<UPSTREAM_TAG>.0` **ohne führendes `v`** (z.B. `v2026.5.0` → `2026.5.0.0`):
|
||||
|
||||
```bash
|
||||
git tag <VERSION>.0
|
||||
# Beispiel: git tag 2026.5.0.0
|
||||
git push origin <VERSION>.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/<NEUER_TAG>`) 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:<ALTER_TAG>`
|
||||
- Ersetze mit: `cr.ortlerstrasse.de/cgo/pretix:<NEUER_TAG>` (= 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 <NEUER_TAG>"
|
||||
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:<ALTER_TAG>`
|
||||
- Ersetze mit: `cr.ortlerstrasse.de/cgo/pretix:<NEUER_TAG>`
|
||||
|
||||
2. Committen und pushen:
|
||||
|
||||
```bash
|
||||
git -C ../OrtlerstrasseGitOps add pretix-sola/pretix-deployment.yaml
|
||||
git -C ../OrtlerstrasseGitOps commit -m "Update pretix-sola to <NEUER_TAG>"
|
||||
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.
|
||||
Reference in New Issue
Block a user