Przejdź do głównej zawartości

🧪 Przewodnik po gałęzi deweloperskiej

Chcesz wypróbować najnowsze funkcje przed ich oficjalnym wydaniem? Gałąź dev zawiera najświeższe ulepszenia i funkcje eksperymentalne, które z czasem trafią do wydania głównego.

Oprogramowanie eksperymentalne

Gałąź dev jest eksperymentalna i może zawierać błędy, nieukończone funkcje lub zmiany niezgodne wstecznie. Używaj jej tylko wtedy, gdy akceptujesz możliwą niestabilność i chcesz pomóc ulepszać Libre WebUI.

🎯 Czym jest gałąź dev?​

Gałąź deweloperska (dev) służy do testowania nowych funkcji przed połączeniem ich ze stabilną gałęzią main. Zawiera:

  • Najnowsze funkcje, których nie ma jeszcze w stabilnych wydaniach
  • Poprawki błędów w trakcie testowania
  • Eksperymentalne ulepszenia interfejsu i działania
  • Optymalizacje wydajności w trakcie rozwoju

🚀 Korzystanie z gałęzi dev​

Konfiguracja Docker (zalecana)​

Deweloperskie pliki Compose montują gniazdo Docker hosta, więc Work działa domyślnie, gdy Docker jest dostępny. Kontenery zadań działają w demonie hosta i są widoczne w docker ps. W systemie Linux najpierw ustaw DOCKER_GID w .env.

Z zewnętrzną 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

Prosty 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

Ze źródeł​

# 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

Testowanie Work​

  1. Uruchom Docker i potwierdź, że docker info działa dla tego samego użytkownika, który uruchamia backend.
  2. Uruchom Libre WebUI ze źródeł poleceniem npm run dev.
  3. Zaloguj się jako administrator.
  4. Wybierz Work i użyj Ollama, Ollama Cloud lub skonfigurowanego modelu z wtyczki obsługującego narzędzia.

Uruchom ukierunkowane testy dostawców backendu i zasad kontenerów:

npm run test:work

Testy sprawdzają generowane zasady Docker, ograniczenie ścieżek, zachowanie cyklu życia i pojemności oraz adaptery narzędzi zgodne z OpenAI, Anthropic i Gemini. Pełną granicę środowiska wykonawczego opisuje Work: izolowane obszary robocze.

🔄 Aktualizowanie gałęzi​

Gałąź dev jest często aktualizowana. Aby pobrać najnowsze zmiany:

# 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

🐛 Znalazłeś błąd? Pomóż nam go naprawić!​

Twoje zgłoszenia błędów są niezwykle cenne. Aby skutecznie zgłosić problem:

Przed zgłoszeniem​

  1. Sprawdź istniejące zgłoszenia: przeszukaj GitHub Issues, aby uniknąć duplikatu
  2. Wypróbuj wersję stabilną: potwierdź, że błąd występuje wyłącznie w dev (a nie w gałęzi main)
  3. Odtwórz go powtarzalnie: czy potrafisz ponownie wywołać błąd?

Zgłaszanie błędów​

🐛 Zgłoś błąd w GitHub

Dołącz następujące informacje:

**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]

Sprawdzanie skrótu commita Git​

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

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

🏆 Współtworzenie i uznanie​

Używając gałęzi dev, stajesz się częścią naszej społeczności testerów. Wkład jest doceniany na kilka sposobów:

Uznanie dla współtwórców​

  • Wpis w CONTRIBUTORS.md
  • Wzmianka w informacjach o wydaniu za znaczący wkład
  • Atrybucja współautora w wiadomościach commitów
  • Specjalne podziękowania w ogłoszeniach projektu

Obecni współtwórcy​

W naszej wspaniałej społeczności są między innymi:

  • rob - Opiekun projektu
  • jm - Ulepszenie dostępu sieciowego
  • I kolejni współtwórcy! Zobacz pełną listę

Chcesz wnieść kod?​

  1. Utwórz fork repozytorium
  2. Utwórz gałąź funkcji z dev: git checkout -b feature/amazing-feature dev
  3. Wprowadź zmiany
  4. Prześlij Pull Request do gałęzi dev

Szczegółowe instrukcje znajdziesz w wytycznych współtworzenia, a zasady etyczne i model zarządzania projektu — w Community Charter.

Kontrole Pull Request​

Każdy pull request, także warstwowy pull request do pośredniej gałęzi funkcji lub poprawki, uruchamia przepływ Format & Lint. Jego niezależne zadania sprawdzają formatowanie, lint frontendu i backendu, typy TypeScript, testy pakietów i regresji oraz zestaw przeglądarkowy Playwright. Nieudane testy przeglądarkowe przesyłają wyniki Playwright do debugowania.

Przepływ Electron Dev Build pakuje również artefakty macOS, Windows i Linux. Kompilacje macOS dla pull requestów zachowują doraźny podpis projektu bez danych uwierzytelniających, aby można było zweryfikować spakowaną aplikację przed przesłaniem. Przepływ pull request nie otrzymuje danych Developer ID ani notaryzacji.

Przepływ Docker Build Test and Push buduje obrazy amd64 i arm64 dla każdego pull requestu, w tym warstwowych pull requestów do gałęzi pośrednich. Kompilacje pull requestów nie logują się do rejestru kontenerów, nie wypychają skrótów obrazów ani nie publikują manifestu wieloarchitekturowego.

Przed otwarciem pull requestu uruchom lokalnie te same kontrole na poziomie aplikacji:

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

⚠️ Ważne uwagi​

Bezpieczeństwo danych​

  • Utwórz kopię zapasową danych przed przełączeniem na gałąź dev
  • Pliki zadań Work znajdują się w osobnych nazwanych woluminach Docker libre-work-*. Utwórz ich oddzielne kopie zapasowe poza katalogiem danych SQLite, zanim przetestujesz destrukcyjne zmiany cyklu życia zadań lub użytkowników.
  • Użyj osobnego woluminu Docker do testowania dev: 
    # 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

Możliwe problemy​

  • Zmiany niezgodne wstecznie mogą wymagać aktualizacji konfiguracji
  • Funkcje mogą być nieukończone lub zmieniać się bez uprzedzenia
  • Wydajność może się różnić podczas testowania optymalizacji
  • Elementy interfejsu mogą wyglądać inaczej lub zachowywać się nieoczekiwanie

Kiedy używać wersji stabilnej​

Wróć do stabilnej gałęzi main, jeśli:

  • Potrzebujesz niezawodności do ważnej pracy
  • Napotykasz zbyt wiele błędów
  • Chcesz przetestowanego, stabilnego środowiska
# 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

🌟 Dołącz do społeczności​

Chcesz pomóc kształtować przyszłość Libre WebUI? 🚀

Twoje testy, opinie i wkład w gałąź dev bezpośrednio poprawiają środowisko wszystkich użytkowników. Dziękujemy, że jesteś częścią naszej społeczności deweloperskiej!