Fehler melden mit Screenshot und Markierung, Sammlung für Bearbeiter
Käfer-Button unten rechts: nimmt den sichtbaren Bildschirm mit html2canvas (selbst gehostet) auf, Vorschau mit roten Rechtecken, Beschreibung, Name optional, Senden ohne Anmeldung. Aus offenen Dialogen heraus wird der Dialog selbst aufgenommen. Bearbeiter sehen die Meldungen unter „Fehler" mit Zähler, kopieren einen fertigen Claude-Prompt und den Screenshot. Serverseitig: Pfade nur in exakter Schreibweise, /api standardmäßig nur für Bearbeiter mit ausdrücklicher Freigabeliste, Bremse zählt jeden Versuch vor dem Lesen großer Bodies, X-Forwarded-For nur von vertrauten Proxys, Nutzertext im Prompt eingezäunt. HTTP-Tests für die Sperren. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
1 parent
6a3c68aaac
commit
4ec23ccd25
15 files changed
+877
-36
No files matched your search
+39
-2
@@ -330,7 +330,12 @@ Die **Engine** (Postgres oder MySQL) leitet VCH aus deinen Schlüsselnamen und d
|
||||
|
||||
**Bringt dein Compose seine eigene Datenbank mit**, startet VCH sie mit und bietet **keine**
|
||||
zweite an. Achte dann selbst auf ein dauerhaftes Volume — ein Datenbankdienst ohne Volume
|
||||
verliert seine Daten beim nächsten Neubau, und VCH warnt nur.
|
||||
verliert seine Daten beim nächsten Neubau, und VCH warnt nur. Erkannt wird der Dienst **am
|
||||
Image-Namen**: `postgres`, `postgresql`, `pgvector`, `postgis`, `timescaledb`, `mysql`,
|
||||
`mariadb`, `percona`/`percona-server`. Ein anderes Image (eigener Build, fremder Name) gilt
|
||||
nicht als Datenbank — dann bietet VCH eine verwaltete an, und der Deploy läuft blau-grün mit
|
||||
einem zweiten Stapel.
|
||||
<!-- Beleg: deployManifest.ts PG_IMAGE_RE/MYSQL_IMAGE_RE, deploy.ts skipBlueGreen -->
|
||||
|
||||
Eine Compose-Datei, die **nur** eine Datenbank startet, ist Entwicklungs-Beiwerk: sie läuft in
|
||||
Produktion nicht mit. Nimm dort die verwaltete Datenbank.
|
||||
@@ -347,6 +352,8 @@ const datenVerzeichnis = process.env.VCH_DATA_DIR || './data';
|
||||
VCH setzt die Variable bei allen Betriebsarten (bei Docker als Einhängepunkt `/data`). **Lies
|
||||
sie zur Laufzeit**, schreibe den Pfad nirgends fest und trage sie nicht in `.env`-Dateien ein.
|
||||
Ein Verzeichnis relativ zum Release (`./data`) ist beim nächsten Deploy weg.
|
||||
Bei Compose gilt das nur im Container des `${VCH_PORT}`-Dienstes — in der Compose-Datei selbst
|
||||
steht die Variable nicht zur Verfügung (Abschnitt 13, Regel 5).
|
||||
|
||||
Der Prüfling während des Audits (Abschnitt 10) bekommt diesen Speicher **nicht** — er läuft
|
||||
gegen einen leeren. Das ist Absicht: zwei Prozesse dürfen nicht gleichzeitig auf dieselbe
|
||||
@@ -377,6 +384,16 @@ Projektarbeitsplatz per Rollback zurückholen.
|
||||
**Auto-Deploy:** ist er eingeschaltet, löst jeder Push auf den konfigurierten Deploy-Branch
|
||||
einen Deploy aus. Pushes auf andere Branches werden ignoriert.
|
||||
|
||||
- **Das Ergebnis jedes Deploys liegt in `.vch/deploy-report.md`** (nicht im Git — VCH trägt
|
||||
die Datei wie den Audit-Bericht in `.git/info/exclude` ein). Er nennt Commit, Stufe,
|
||||
Fehlermeldung, das Ende des Logs (Geheimnisse geschwärzt) und eine Einschätzung:
|
||||
„probably fixable in this repository" heißt, die Ursache liegt vermutlich im Code — beheben,
|
||||
committen, pushen. „platform error" heißt: **nicht** im Code suchen, sondern dem Nutzer sagen,
|
||||
was dort steht. Nach einem erfolgreichen Deploy steht dort genau das; ein alter Fehlerbericht
|
||||
bleibt nicht liegen. Nennt der Bericht einen anderen Commit als den, nach dem du gefragt
|
||||
wirst, ist er noch nicht aktualisiert.
|
||||
<!-- Beleg: services/deployReportFile.ts -->
|
||||
|
||||
## 11. Audit — was geprüft wird
|
||||
|
||||
Das Audit läuft nicht hier, sondern in einem eigenen Runner gegen einen **sauberen Checkout
|
||||
@@ -399,6 +416,11 @@ macht eine Datei für das Audit unsichtbar.
|
||||
`skipped` meldet, gilt als **durchgefallen** — sie ist nie gelaufen.
|
||||
- `secrets` sucht eingecheckte Zugangsdaten. Echte Werte gehören nie ins Repository: in die
|
||||
`.env.example` nur Beispiele, die echten Werte in den Env-Editor von VCH.
|
||||
- **Das Ergebnis liegt nach jedem Audit in `.vch/audit-report.md`** (nicht im Git — VCH trägt
|
||||
die Datei in `.git/info/exclude` ein). Bei einem Fehlschlag: lesen, beheben, committen,
|
||||
pushen — erst der nächste Deploy auditiert den neuen Commit. Der Kopf nennt Commit und
|
||||
Zeitpunkt; lief die Instanz beim Audit nicht, ist die Datei älter oder fehlt, dann steht der
|
||||
aktuelle Bericht im Audit-Fenster von VCH zum Kopieren.
|
||||
|
||||
## 12. Veröffentlichen
|
||||
|
||||
@@ -410,7 +432,7 @@ macht eine Datei für das Audit unsichtbar.
|
||||
- Im **Showcase** erscheinen veröffentlichte Projekte mit bestandenem Audit und einer
|
||||
eingecheckten `.vch-description`.
|
||||
|
||||
## 13. Compose — die vier Regeln, an denen es sonst scheitert
|
||||
## 13. Compose — die fünf Regeln, an denen es sonst scheitert
|
||||
|
||||
1. **Der App-Dienst muss seinen Port als `ports: ["${VCH_PORT}:<intern>"]` veröffentlichen.**
|
||||
VCH setzt `VCH_PORT` und kann so einen Prüfling neben deiner laufenden Fassung starten.
|
||||
@@ -425,3 +447,18 @@ macht eine Datei für das Audit unsichtbar.
|
||||
4. **Der ganze Stapel startet.** Datenbanken, Caches und Ähnliches aus deinem Compose laufen
|
||||
automatisch mit — eine zusätzliche verwaltete Datenbank brauchst du dafür nicht. Dienste
|
||||
hinter einem `profiles:`-Schlüssel bleiben aus.
|
||||
5. **Gebaute Dienste bekommen kein `image:`, dauerhafte Daten liegen unter `/data` des
|
||||
`${VCH_PORT}`-Dienstes.** Für jeden Dienst mit `build:` vergibt VCH den Image-Namen selbst,
|
||||
je Commit — so starten Prüfling, Live-Stand und Rollback jeweils genau ihren Code. Ein
|
||||
eigenes `image:` bei einem gebauten Dienst teilt sich ein Image über alle Releases; ein
|
||||
Rollback startet dann den zuletzt gebauten Code. `VCH_DATA_DIR` gibt es **nur im Container**
|
||||
des `${VCH_PORT}`-Dienstes (als `/data`), nicht beim Einlesen der Compose-Datei:
|
||||
`${VCH_DATA_DIR:-.}/data` wird dort zu `./data` im Release-Ordner und ist beim nächsten
|
||||
Deploy weg. Ein zweiter Dienst, der dieselben Daten braucht, bekommt `volumes_from: [<app>]`;
|
||||
eigene Daten legt er in ein benanntes Volume (`volumes: [daten:/var/lib/…]`) — das überlebt
|
||||
Deploys, sichert VCH aber nicht mit. `vch-images.yml` wird bei jedem Build neu
|
||||
geschrieben oder entfernt, `vch-override.yml` bei jedem Start des Live-Stands geschrieben
|
||||
(sofern es einen `${VCH_PORT}`-Dienst gibt) — beide gehören VCH, keine eigenen Dateien dieses
|
||||
Namens.
|
||||
|
||||
<!-- Beleg: dockerCommands.ts composeImageRef/renderComposeImages, runtimeOps.ts composeStableUpCmds (#291); deployManifest.ts classifyServiceDataMount -->
|
||||
Reference in new issue
Block a user