gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

dev: GlitchTip-Doku auf Git-Deploy umgestellt (Release-Datei schreibt deploy.sh)

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-10-06 13:17:19 +00:00
parent 88b4feb352
commit 072fd6235e
1 changed files with 5 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

9
dev/glitch-tip/README.md
View file

@ -136,7 +136,7 @@ Wenn der Auftrag lautet „schau in GlitchTip“, „was sagt GlitchTip“ o. Ä
4. **Reproduzieren mit rotem Test**, dann Fix (Projektregel: jede Änderung mit Test). Ist der Fehler ein Muster, das wieder auftreten kann, einen **Wächtertest** über alle Dateien schreiben (Beispiele: `BladePhpBlockGuardTest`, `BladeAlpineTranslationGuardTest`). 4. **Reproduzieren mit rotem Test**, dann Fix (Projektregel: jede Änderung mit Test). Ist der Fehler ein Muster, das wieder auftreten kann, einen **Wächtertest** über alle Dateien schreiben (Beispiele: `BladePhpBlockGuardTest`, `BladeAlpineTranslationGuardTest`).
5. **Qualitätsgates:** betroffene Tests, dann `php artisan test --compact --parallel`, `vendor/bin/phpstan analyse --memory-limit=2G`, `vendor/bin/pint --dirty --format agent`; bei JS `npm run build`. 5. **Qualitätsgates:** betroffene Tests, dann `php artisan test --compact --parallel`, `vendor/bin/phpstan analyse --memory-limit=2G`, `vendor/bin/pint --dirty --format agent`; bei JS `npm run build`.
6. **Dokumentieren:** Eintrag in Abschnitt 7 (ID, Klasse, Ursache, Fix, Commit). Commit-Nachricht nennt die GlitchTip-ID. 6. **Dokumentieren:** Eintrag in Abschnitt 7 (ID, Klasse, Ursache, Fix, Commit). Commit-Nachricht nennt die GlitchTip-ID.
7. **Ausliefern** über den nächsten Deploy (Hotfix: letzte Versionsstelle, z. B. `v1.1.1`; Ablauf wie [`../betrieb/deploy-v1.1.0.md`](../betrieb/deploy-v1.1.0.md)). 7. **Ausliefern** über den nächsten Deploy (Hotfix: letzte Versionsstelle erhöhen). Ablauf seit `v1.1.1`: Git-Deploy per Tag, [`../betrieb/git-deploy.md`](../betrieb/git-deploy.md) Abschnitte C und D (Assets bauen und committen, Tag, Push, auf dem Server `deploy.sh`).
8. **Auflösen** in GlitchTip macht der Betreiber (Token ist nur lesend) — erst nach dem Deploy. Kommt der Fehler mit neuem Release wieder, öffnet GlitchTip den Eintrag erneut. 8. **Auflösen** in GlitchTip macht der Betreiber (Token ist nur lesend) — erst nach dem Deploy. Kommt der Fehler mit neuem Release wieder, öffnet GlitchTip den Eintrag erneut.
--- ---
@ -163,9 +163,10 @@ Wenn der Auftrag lautet „schau in GlitchTip“, „was sagt GlitchTip“ o. Ä
**Release:** `App\Support\Monitoring\Release::current()` liest `APP_VERSION` **Release:** `App\Support\Monitoring\Release::current()` liest `APP_VERSION`
bzw. `SENTRY_RELEASE`, sonst die Datei `RELEASE` im Projektwurzelverzeichnis. bzw. `SENTRY_RELEASE`, sonst die Datei `RELEASE` im Projektwurzelverzeichnis.
Die Datei entsteht beim Paketbau **auf dem Tag** (`git describe --tags --always > RELEASE`) Seit dem Git-Deploy schreibt `dev/betrieb/deploy.sh` sie beim Deploy (`echo "$tag" > RELEASE`),
und wird mit ausgeliefert. Nicht später auf einem anderen Stand neu erzeugen: GlitchTip zeigt also genau den ausgelieferten Tag. Bei den SFTP-Deploys bis
dann steht z. B. `v1.1.0-3-gb1cec16` statt `v1.1.0` (so am 05./06.10. auf Live). `v1.1.0` wurde sie von Hand erzeugt; daher stammen Releases wie
`v1.1.0-3-gb1cec16` in älteren Einträgen.
Nach Änderung: `php artisan config:cache`. Nach Änderung: `php artisan config:cache`.
--- ---