Deploymentcenter BotandClaude Opus 5
1d5ac92051
Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht
eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es
nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen
Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere
lauffaehig.
ROADMAP IM DEPLOYMENTCENTER (2.7.0)
Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten
Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits
fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit.
Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger.
- Migration 016: epic, roadmap_rank, target_build, defer_trigger,
doc_anchor, Status "deferred", Tabelle roadmap_epics.
KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item.
- Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein
epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen.
- Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die
schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil
die Kennung nach einer Loeschung neu vergeben wurde.
- Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein
Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im
Repository, damit sie auf allen drei Schreibwegen gleich greift.
- Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php,
WebUI-Modul mit Filtern, cli/roadmap.php --write/--check,
dc_roadmap und dc_roadmap_set im MCP-Adapter.
- cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei;
--check prueft nur die Prosa. Was erzeugt wird, kann nicht driften.
- docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte.
TESTINSTANZ UND TESTTOR
- dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel,
Basic-Auth davor, Rocket.Chat aus.
- 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre.
- scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf
die Testinstanz und laesst dann den Testlauf laufen. Erst bei
Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang).
Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht.
- tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann
nicht versehentlich auf dc.mhdf.de landen.
- Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit
Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch
nicht - der Unterschied darf nicht am Rueckgabewert verschwinden.
SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1)
- Migration 013: projektuebergreifend melden (dev_agent, evidence,
triage_external, affects).
- Migration 014: supervisor_findings, Katalog, fuenf serverseitige
Detektoren im Tick.
- Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung.
- DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM.
- MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung
von Fremddaten gegen Prompt-Injektion.
BEHOBEN
- observe und status im Supervisor legten den Zustand des Befundes als
"status" in die Antwort. Http::ok() merged ['status' => 'success']
darunter, also gewann der Befundzustand - eine angenommene Meldung kam
als status="open" an. Heisst jetzt finding_status. War Item #59.
Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt.
Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf
gegen bugtracker_items.epic abfragt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
59 lines
2.2 KiB
C#
59 lines
2.2 KiB
C#
using System;
|
|
|
|
namespace Deploymentcenter.Client
|
|
{
|
|
/// <summary>
|
|
/// Auskunft ueber die eingebundene SDK-Fassung.
|
|
///
|
|
/// Wozu das gut ist: Wer eine Anbindung aktualisiert, will nicht die
|
|
/// gesamte Historie lesen, sondern nur wissen, was sich seit der eigenen
|
|
/// Fassung geaendert hat. Dafuer muss die Anwendung festhalten, gegen
|
|
/// welche Fassung sie gebaut wurde - und genau das ist
|
|
/// <see cref="Version"/>.
|
|
///
|
|
/// Der Wert wandert automatisch in die Update-Pruefung und den Heartbeat,
|
|
/// sodass im Deploymentcenter sichtbar wird, welche Installation auf
|
|
/// welchem Stand haengt. Ohne diese Angabe bliebe nur Nachfragen.
|
|
///
|
|
/// Abfragen laesst sich der Unterschied so:
|
|
///
|
|
/// GET /api/updateservice/v1/changelog?since=2.2.0
|
|
///
|
|
/// Die Antwort nennt nur die neueren Fassungen, dazu die Anzahl der
|
|
/// Punkte mit Handlungsbedarf und der brechenden Aenderungen.
|
|
/// </summary>
|
|
public static class DeploymentcenterSdk
|
|
{
|
|
/// <summary>
|
|
/// Fassung dieses SDK. Bei jeder Auslieferung mitzufuehren - sie ist
|
|
/// der Bezugspunkt fuer den Changelog.
|
|
/// </summary>
|
|
public const string Version = "2.6.0";
|
|
|
|
/// <summary>
|
|
/// Adresse, unter der sich der Unterschied zur eigenen Fassung
|
|
/// abfragen laesst.
|
|
/// </summary>
|
|
public static string ChangelogUrl(string baseUrl, string? since = null)
|
|
{
|
|
string clean = (baseUrl ?? string.Empty).TrimEnd('/');
|
|
string url = clean + "/api/updateservice/v1/changelog";
|
|
|
|
string from = string.IsNullOrWhiteSpace(since) ? Version : since!;
|
|
return url + "?since=" + Uri.EscapeDataString(from);
|
|
}
|
|
|
|
/// <summary>
|
|
/// Kurzer Vermerk fuer Protokolle und Fehlerberichte. Taucht ein
|
|
/// Problem auf, ist damit sofort ersichtlich, gegen welche Fassung die
|
|
/// Anbindung gebaut wurde.
|
|
/// </summary>
|
|
public static string Describe(string? appVersion = null)
|
|
{
|
|
return string.IsNullOrWhiteSpace(appVersion)
|
|
? $"Deploymentcenter-SDK {Version}"
|
|
: $"{appVersion} (Deploymentcenter-SDK {Version})";
|
|
}
|
|
}
|
|
}
|