Files
Deploymentcenter/docs/BUGTRACKER_INTEGRATION_GUIDE.md
T
Deploymentcenter BotandClaude Opus 5 a74c6fd990 fix(clients, docs): Lizenz-Antwortformat wiederherstellen, Packager absichern
Regression aus dem vorigen Commit
- /api/license/v1/validate lieferte die Antwort im neuen status/error-Umschlag.
  Der Vertrag dieses Endpunkts ist aber bereits ausgerollt: das Feld "status"
  auf oberster Ebene trägt den Lizenzzustand (valid, revoked, expired ...).
  LicenseClient las dadurch "success" statt "valid" — jeder ausgelieferte
  Client hätte seine Lizenz für ungültig gehalten. Die Lizenz-Endpunkte
  antworten jetzt wieder ohne Umschlag (Http::raw).
  Gefunden durch Ausführen der projekteigenen Test-Suite gegen den Server.

Packager
- FTP-Zugangsdaten standen als Standardwerte im Quelltext und zusätzlich in
  packager.config.json und in der Integrationsanleitung. Alle drei Fundstellen
  bereinigt; die Konfigurationsdatei ist nicht mehr versioniert. Zugangsdaten
  kommen aus Datei, Umgebungsvariablen oder CLI-Argument, sonst bricht das
  Programm mit einer klaren Meldung ab.
- Das Veröffentlichen sendet jetzt ein Token (updateservice:publish) und nutzt
  den Endpunkt /api/updateservice/v1/publish.
- Fehler wurden von einem leeren catch verschluckt, und ohne Erfolgsfall wurde
  gar nichts ausgegeben. Das Werkzeug meldete am Ende immer Erfolg und lieferte
  Rückgabewert 0, selbst wenn FTP-Upload und API-Aufruf fehlgeschlagen waren.
  Jetzt ehrliche Meldungen und Rückgabewerte 0/1/2.
- packager.config.json wurde vom csproj nie ins Ausgabeverzeichnis kopiert,
  weshalb sie dort nie gefunden wurde und stets die hartkodierten Werte griffen.

UpdateClient
- IsVersionNewer entfernte die Vorabkennung, aber kein führendes "v". Damit
  scheiterte Version.TryParse bei "v1.4.2" und es wurde auf einen
  alphabetischen Vergleich zurückgefallen, in dem "v1.9.0" als neuer gilt als
  "v1.10.0" — derselbe Fehler wie zuvor serverseitig im SQL. Ersetzt durch
  einen vollständigen semantischen Vergleich, verifiziert mit 16 Testfällen.
- Der Rückfall auf die API lag in einem catch-Block, aber GetAsync wirft bei
  einem 404 keine Exception. Fehlte die statische latest.json, brach die
  Prüfung ab, statt die API zu befragen.

Dokumentation
- BUGTRACKER_INTEGRATION_GUIDE.md beschrieb denselben Workflow ein zweites Mal
  und war bereits auseinandergelaufen: Aufrufe ohne Token, alte Pfade, weder
  Claim/Lease noch Idempotenz. Ersetzt durch einen Verweis auf das gepflegte
  Agenten-Handbuch samt Übersicht der Änderungen.
- UPDATESERVICE_INTEGRATION_GUIDE.md um Token, Umgebungsvariablen und
  Rückgabewerte ergänzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 16:27:02 +02:00

57 lines
2.6 KiB
Markdown

# Bugtracker-Integration
> **Dieser Leitfaden wurde zusammengeführt.**
>
> Die vollständige, gepflegte Beschreibung steht im
> **[Agenten-Handbuch](../public/docs/bugtracker.md)** — öffentlich erreichbar
> unter `https://dc.mhdf.de/docs/` und maschinenlesbar unter
> `https://dc.mhdf.de/api/openapi.json`.
>
> Zuvor existierten zwei Beschreibungen desselben Workflows nebeneinander. Sie
> waren bereits auseinandergelaufen: die hier stehenden Beispiele riefen die
> Endpunkte ohne Token auf, benutzten `report.php` und `manage/index.php` als
> Pfade und kannten weder Claim/Lease noch Idempotenz. Ein Agent, der diesem
> Dokument folgte, wäre seit Version 2.0 an `401 unauthorized` gescheitert.
---
## Was sich gegenüber der alten Fassung geändert hat
| Alt | Neu |
|---|---|
| `POST /api/bugtracker/v1/report.php` ohne Token | `POST /api/bugtracker/v1/report` **mit** Token (`bugtracker:report`) |
| `GET /api/bugtracker/v1/projects.php` ohne Token | `GET /api/bugtracker/v1/projects` **mit** Token (`bugtracker:read`) |
| `GET .../manage/index.php?project_slug=…` | `GET .../manage?action=list&project_slug=…` |
| `created_by` frei wählbar | Wird aus dem Token abgeleitet |
| Keine Reservierung — zwei Agenten konnten dasselbe Item bearbeiten | `?action=next` holt und reserviert exklusiv (Claim/Lease) |
| Wiederholte Sendung erzeugte Duplikate | `client_ref` bzw. Header `Idempotency-Key` |
| Fehler nur als Freitext | Stabiler `error.code` zum Auswerten |
## Kürzestmögliche Fassung
```bash
# 1. Arbeit holen und übernehmen
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=next" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"project_slug": "myapp", "limit": 1}'
# 2. Zwischenstand festhalten
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=comment&id=42" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"comment": "Ursache gefunden.", "action_taken": "investigated"}'
# 3. Abschließen
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=resolve&id=42" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"resolved_in_build": "v1.4.3", "resolution_notes": "Fix in AuthController."}'
```
## Weiterführend
- **[Agenten-Handbuch](../public/docs/bugtracker.md)** — vollständige Referenz mit allen Feldern, Filtern, Fehlercodes und einem Python-Beispiel
- **[Agent-Prompt-Vorlage](./AGENT_PROMPT_TEMPLATE.md)** — Textbaustein für `CLAUDE.md` / `AGENTS.md`
- **[UPGRADE.md](./UPGRADE.md)** — Umstellungsschritte für bestehende Integrationen