Zum Hauptinhalt springen

🧪 Leitfaden zum Entwicklungsbranch

Der Branch dev enthält neue und experimentelle Funktionen vor der offiziellen Veröffentlichung.

Experimentelle Software

dev kann Fehler, unvollständige Funktionen und Breaking Changes enthalten. Nutze ihn nur, wenn du Instabilität akzeptierst.

🎯 Was ist der Dev-Branch?​

Neue Funktionen werden dort vor main getestet: neueste Funktionen, Fehlerkorrekturen, UI-Experimente und Optimierungen.

🚀 Dev-Branch verwenden​

Docker-Einrichtung (empfohlen)​

Compose bindet den Host-Socket ein; Work-Container erscheinen in docker ps. Setze unter Linux DOCKER_GID. Speichere den Wert in .env.

Mit externem Ollama:

# Clone the repository
git clone https://github.com/libre-webui/libre-webui.git
cd libre-webui

# Switch to dev branch
git checkout dev

# Start the dev image with external Ollama
docker compose -f docker-compose.dev.external-ollama.yml up -d

Einfaches Docker:

# Use the dev branch image
docker run -d -p 3000:3001 -v libre-webui:/app/backend/data --name libre-webui-dev --restart always ghcr.io/libre-webui/libre-webui:dev

Aus dem Quellcode​

# Clone and switch to dev branch
git clone https://github.com/libre-webui/libre-webui.git
cd libre-webui
git checkout dev

# Install dependencies
npm install

# Start development server
npm run dev

Vite kann fertig sein, bevor das Backend seine Startprüfungen abschließt. Bei lokalem Backend wartet der Entwicklungsproxy bis zu 10 Sekunden auf dessen Listener, bevor er eine API-Anfrage weiterleitet. Er leitet jede Anfrage genau einmal weiter, auch Schreibzugriffe, und wiederholt fehlgeschlagene Anfragen nicht. Bleibt das Backend nicht erreichbar, antwortet der Proxy mit HTTP 503 und einem Hinweis auf einen erneuten Versuch. Statische Frontend-Dateien bleiben währenddessen verfügbar.

Chat verbindet sich nach kurzen Backend-Ausfällen erneut, mit Wartezeiten bis höchstens 30 Sekunden. Eine erfolgreiche Verbindung setzt die Wartezeit zurück; das Abmelden bricht ausstehende Versuche ab. Authentifizierungsfehler beenden die automatische Neuverbindung.

Work testen​

  1. Docker starten und docker info als Backend-Benutzer prüfen.
  2. npm run dev starten.
  3. Als Administrator anmelden.
  4. Work mit einem toolfähigen Ollama-, Cloud- oder Pluginmodell wählen.
npm run test:work

Die Tests prüfen Docker-Policy, Pfade, Lebenszyklus, Kapazität und OpenAI-/Anthropic-/Gemini-Adapter. Siehe Work: isolierte Workspaces.

🔄 Aktuell bleiben​

# Update your local dev branch
git pull origin dev

# Refresh the dev Compose stack
docker compose -f docker-compose.dev.external-ollama.yml pull
docker compose -f docker-compose.dev.external-ollama.yml up -d

# Or restart simple Docker
docker pull ghcr.io/libre-webui/libre-webui:dev
docker stop libre-webui-dev && docker rm libre-webui-dev
docker run -d -p 3000:3001 -v libre-webui:/app/backend/data --name libre-webui-dev --restart always ghcr.io/libre-webui/libre-webui:dev

🐛 Fehler gefunden? Hilf uns!​

Vor dem Melden​

  1. Bestehende Issues durchsuchen.
  2. Prüfen, ob der Fehler nur in dev auftritt.
  3. Reproduzierbarkeit bestätigen.

Fehler melden​

🐛 Auf GitHub melden

Diese Informationen angeben:

**Environment:**

- Branch: dev
- Version: [git commit hash or date]
- OS: [Windows/macOS/Linux]
- Browser: [Chrome/Firefox/Safari version]
- Setup: [Docker/Source/etc.]
- Docker: [version and whether `docker info` succeeds, for Work issues]
- Work model/provider: [exact route, when applicable]

**Bug Description:**
Clear description of what went wrong

**Steps to Reproduce:**

1. Go to...
2. Click on...
3. See error...

**Expected Behavior:**
What should have happened

**Actual Behavior:**
What actually happened

**Screenshots/Logs:**
[If applicable, add screenshots or error logs]

**Work Activity:**
[Relevant tool call/result or preview output, with secrets removed]

Git-Commit-Hash ermitteln​

# Find your current dev branch commit
git rev-parse HEAD

# Or get a short version
git rev-parse --short HEAD

🏆 Beiträge und Anerkennung​

Anerkennung für Beitragende​

  • Eintrag in CONTRIBUTORS.md
  • Erwähnung in Release Notes
  • Co-Autor-Zuordnung
  • Besonderer Dank

Aktuelle Beitragende​

Code beitragen​

  1. Repository forken.
  2. Von dev erstellen: git checkout -b feature/amazing-feature dev.
  3. Änderungen durchführen.
  4. Pull Request gegen dev senden.

Siehe Beitragsrichtlinien und Community-Charta.

Pull-Request-Prüfungen​

Jeder Pull Request, auch ein gestapelter Pull Request in einen Feature- oder Fix-Zwischenbranch, führt den Workflow Format & Lint aus. Seine unabhängigen Jobs prüfen Formatierung, Frontend- und Backend-Linting, TypeScript-Typen, Paket- und Regressionstests sowie die Playwright-Browsersuite. Chromium führt die vollständige Browsersuite aus. WebKit und Firefox führen zusätzlich die kritischen Abläufe für Authentifizierung, Streaming, Dialoge, Tabs, Automatisierungen, Speicher, Work und Sprachwiedergabe aus. Jede Engine läuft in einem eigenen CI-Job, und fehlgeschlagene Läufe laden getrennte Testergebnisse hoch.

Das getestete npm-Tarball wird unter Linux, macOS und Windows mit Node 22.22 und mit Node 24 in ein neues Consumer-Verzeichnis installiert. Diese Prüfungen installieren echte Produktionsabhängigkeiten, ohne die node_modules des Checkouts mitzubenutzen, und prüfen dann CLI-Start, Bereitschaft, Frontend-Auslieferung und den Erhalt der Daten über einen Neustart hinweg. Führe dieselbe Prüfung lokal nach npm run build mit npm run test:package-install aus; übergib ein Tarball oder ein Verzeichnis mit genau einem Tarball, um ein bestimmtes Artefakt zu testen. Eine saubere Installation braucht Zugriff auf die Registry und, wenn keine vorkompilierte Abhängigkeit verfügbar ist, die üblichen Voraussetzungen der Plattform für den Build nativer Module.

Ein separater Work-Computer-Job baut das GUI-Image aus der fixierten Basis der Laufzeitumgebung und führt den echten Interaktions-Regressionstest aus. Mit TEST_WORK_COMPUTER=1 schlägt die Prüfung fehl, statt übersprungen zu werden, wenn der Docker-Daemon oder das Image fehlt. Zum lokalen Nachstellen setzt du dieses Flag, setzt WORK_COMPUTER_TEST_IMAGE auf ein separat gebautes Test-Image und führst dann npm run test:work-computer aus. Ohne den Pflichtmodus melden lokale Läufe weiterhin ein Überspringen, wenn die optionale GUI-Fixture fehlt.

Diese Matrix ergänzt Prüfungen für die unterstützten Oberflächen; sie aktiviert keine nicht unterstützten Kombinationen. Knotenlokale CLI-Zugangsdaten bleiben für externe Team-Worker nicht verfügbar.

CodeQL prüft bei jedem Pull Request JavaScript/TypeScript-, Python- und Workflow-Code. Die ausführbaren Python-Anbieterserver unter examples/ sind in .gitattributes ausdrücklich als Code eingestuft, damit die Spracherkennung von GitHub sie einbezieht. Die separate verwaltete Code Quality-Konfiguration sollte sowohl JavaScript/TypeScript als auch Python umfassen. Bleiben nach einer Korrektur historische Befunde bestehen, prüfe die analysierte Revision und die Sprachabdeckung und aktualisiere die betreffende Analyse, nachdem die Änderung veröffentlicht ist. Verwirf keine gültigen Befunde und ändere kein korrektes asynchrones Verhalten, nur um eine angezeigte Bewertung zu verbessern.

Der Workflow Electron Dev Build paketiert außerdem Artefakte für macOS, Windows und Linux. macOS-Builds für Pull Requests behalten die zugangsdatenfreie Ad-hoc-Signatur des Projekts, damit die paketierte Anwendung vor dem Hochladen geprüft werden kann. Der Pull-Request-Workflow erhält keine Developer-ID- oder Notarisierungszugangsdaten.

Der Workflow Docker Build Test and Push baut für jeden Pull Request amd64- und arm64-Images, auch für gestapelte Pull Requests in Zwischenbranches. Pull-Request-Builds melden sich bei keiner Container-Registry an, pushen keine Image-Digests und veröffentlichen kein Multi-Architektur-Manifest.

Führe vor dem Öffnen eines Pull Requests dieselben Prüfungen auf Anwendungsebene lokal aus:

npm run format:check
npm run lint
npm run test:package
npm run test:e2e

⚠️ Wichtige Hinweise​

Datensicherheit​

  • Vor Wechsel sichern.
  • libre-work-*-Volumes getrennt von SQLite sichern.
  • Eigenes Dev-Volume verwenden: 
    # Use different volume name for dev
    docker run -d -p 3000:3001 -v libre-webui-dev:/app/backend/data --name libre-webui-dev ghcr.io/libre-webui/libre-webui:dev

Mögliche Probleme​

  • Breaking Changes, unvollständige Funktionen, schwankende Leistung und unerwartete UI.

Wann Stable verwenden?​

Bei wichtigen Arbeiten, zu vielen Fehlern oder gewünschter Stabilität zu main zurückkehren:

# Switch back to stable
git checkout main
docker compose -f docker-compose.external-ollama.yml pull
docker compose -f docker-compose.external-ollama.yml up -d

🌟 Community beitreten​

Bereit, Libre WebUI mitzugestalten? 🚀

Tests, Feedback und Beiträge verbessern die Erfahrung für alle.