Das Projekt veröffentlichen und prüfen

Für Entwickler, die einen Client mit OpenBot verbinden oder den Server erweitern. Die Beispiele brauchen die auf dieser Seite genannten Rechte. Beginne mit dem Entwicklerhandbuch.

Für Mitwirkende, die OpenBot ändern oder veröffentlichen.

GitHub Actions

Der Workflow .github/workflows/ci.yml hat zwei Jobs. Der zweite Job läuft nur, wenn der erste erfolgreich ist.

Job	Was er tut
check	Führt pnpm build, pnpm typecheck und pnpm -r test in devenv shell aus.
images	Baut, prüft, scannt und veröffentlicht die Docker-Images.

Beide Jobs laufen auf ubuntu-latest. Sie installieren Nix mit dem Determinate Nix Installer und danach devenv 2.4.0. Magic Nix Cache speichert Nix-Build-Ergebnisse im Cache von GitHub Actions. So bauen spätere Läufe sie nicht noch einmal. Die Jobs laden auch fertig gebaute devenv-Pakete von devenv.cachix.org. Der Job check speichert den pnpm-Store in einem Cache.

Der Job images macht diese Schritte:

1. hadolint und docker buildx bake lint prüfen das Dockerfile. Der zweite führt die Docker-Build-Prüfungen aus.
2. Docker Bake baut beide Images. Die Build-Schichten bleiben im Cache von GitHub Actions, mit einem Cache pro Image. So bauen spätere Läufe nur, was sich geändert hat.
3. deploy/docker/check.sh prüft die Images. Siehe Die Images prüfen.
4. dive prüft, dass die Image-Schichten keinen Platz verschwenden.
5. Trivy scannt beide Images. Der Job schlägt fehl, wenn ein Image eine bekannte Schwachstelle der Stufe HIGH oder CRITICAL hat, für die es eine Korrektur gibt. Trivy sieht die Node.js-Version nicht, denn Node.js wird in das Image kopiert und nicht als Paket installiert.
6. Der Job speichert beide Images als Artefakt images-<commit-sha> für sieben Tage.
7. Bei Pushes veröffentlicht der Job die Images. Er nutzt den Build-Cache und baut also nicht noch einmal.

Der Workflow läuft für Pull Requests, Pushes auf main und Tags wie v1.2.3. Er veröffentlicht Images nur bei Pushes:

Ereignis	Veröffentlichte Tags
Ein Push auf main	<commit-sha> und latest
Ein Tag wie v1.2.3	<commit-sha> und v1.2.3

Die Images landen in der GitHub Container Registry, unter ghcr.io/openbot-build/openbot und ghcr.io/openbot-build/openbot/protocol-test. Der Workflow bringt OpenBot nicht in Betrieb. Wenn du ein veröffentlichtes Image mit Compose nutzen willst, lade es herunter und gib ihm den Tag openbot:<tag>.

Die Doku-Seite veröffentlichen

Der Workflow .github/workflows/docs.yml veröffentlicht die Doku-Seite auf GitHub Pages unter docs.openbot.build. Er läuft bei jedem Push auf main. Du kannst ihn auch von Hand im Tab „Actions“ starten.

Job	Was er tut
build	Führt pnpm --filter "@openbot-build/docs..." build in devenv shell aus. Das baut die Doku und die Pakete, die sie braucht.
deploy	Schickt packages/docs/dist an GitHub Pages.

Der Job build setzt DOCS_URL auf https://docs.openbot.build. Astro nutzt den Wert für vollständige Seitenlinks, zum Beispiel in der Sitemap. Es läuft immer nur ein Deploy auf einmal.

Die Einstellungen des Repositorys müssen GitHub Actions als Quelle für Pages nutzen, mit docs.openbot.build als eigener Domain. Setze ihren DNS-CNAME auf openbot-build.github.io. Dieser Actions-Workflow nutzt keine CNAME-Datei im Quellcode. Das englische Handbuch beginnt unter /, das chinesische unter /zh-cn/ und das deutsche unter /de/. Die erzeugte API-Referenz beginnt unter /api/. Siehe Manage a custom domain.

Die Images prüfen

deploy/docker/check.sh startet compose.production.yaml mit Test-Einstellungen. Die zusätzliche Datei compose.check.yaml entfernt die Host-Ports und fügt einen zweiten OpenBot-Knoten sowie Einrichtung und Prüfungen hinzu. Beide Knoten teilen Datenbank und Geheimnisse. Jeder hat einen eigenen privaten Host. setup läuft nach migrate, bevor die Knoten starten. Der Dienst check führt die Prüfungen aus. check.env enthält die Test-Einstellungen. Keine davon ist ein echtes Geheimnis.

Der Dienst check führt check.mjs im Compose-Netzwerk aus, sobald beide OpenBot-Knoten und der Protokolltest-Dienst gesund sind. Er prüft, dass:

• /v1/chats ohne Schlüssel und mit falschem Schlüssel 401 zurückgibt,
• /openapi.json auf beiden Knoten funktioniert,
• private RPC-Aufrufe ohne oder mit falschem Geheimnis scheitern,
• jeder Knoten den anderen mit dem gemeinsamen Geheimnis erreichen kann,
• der Catalog des Protokolltests den richtigen öffentlichen Origin hat,
• die MCP-Erkennung auf dem Protokolltest-Dienst funktioniert.

Das Skript prüft auch eine leere Datenbank, eine wiederholte Migration, beide Runner-Adressen und die Sperre gegen Migration bei laufenden Servern. Jeder Lauf nutzt ein eigenes Compose-Projekt und entfernt es mit der Test-Datenbank am Ende. Die Pakettests prüfen Wiederaufnahme und Knotenausfall. Die Image-Prüfung prüft die Verbindungen und den Start im Produktivaufbau.

Führe dieselben Prüfungen auf deinem Computer aus:

devenv shell -- pnpm images
devenv shell -- pnpm images:check
devenv shell -- hadolint deploy/docker/Dockerfile
devenv shell -- dive --ci --source docker openbot:local
devenv shell -- trivy image --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed openbot:local