🧪 Guía de la rama de desarrollo
¿Quieres probar las últimas funciones antes de su publicación oficial? La rama dev contiene mejoras de vanguardia y funciones experimentales que acabarán llegando a la versión principal.
La rama dev es experimental y puede contener errores, funciones incompletas o cambios incompatibles. Úsala solo si aceptas una posible inestabilidad y quieres ayudar a mejorar Libre WebUI.
🎯 ¿Qué es la rama dev?
La rama de desarrollo (dev) es donde se prueban las funciones nuevas antes de integrarlas en la rama estable main. Incluye:
- Las últimas funciones, aún ausentes de las versiones estables
- Correcciones de errores en pruebas
- Mejoras experimentales de la interfaz y la funcionalidad
- Optimizaciones de rendimiento en desarrollo
🚀 Cómo usar la rama dev
Configuración con Docker (recomendada)
Los archivos Compose de desarrollo montan el socket Docker del host, por lo que Work funciona
de forma predeterminada cuando Docker está disponible. Los contenedores de tareas se ejecutan en el daemon
del host y aparecen en docker ps. En Linux, define primero DOCKER_GID en .env.
Con Ollama externo:
# 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
Docker sencillo:
# 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
Desde el código fuente
# 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
Probar Work
- Inicia Docker y confirma que
docker infofuncione para el mismo usuario que ejecuta el backend. - Inicia Libre WebUI desde el código con
npm run dev. - Inicia sesión como administrador.
- Selecciona Work y usa Ollama, Ollama Cloud o un modelo respaldado por un plugin configurado que admita herramientas.
Ejecuta las pruebas específicas del proveedor del backend y de la política de contenedores con:
npm run test:work
Las pruebas validan la política Docker generada, la contención de rutas, el ciclo de vida y la capacidad, y los adaptadores de herramientas compatibles con OpenAI, Anthropic y Gemini. Consulta Work: espacios de trabajo aislados para conocer todo el límite del entorno de ejecución.
🔄 Mantenerse al día
La rama dev se actualiza con frecuencia. Para obtener los últimos cambios:
# 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
🐛 ¿Has encontrado un error? ¡Ayúdanos a mejorar!
Tus informes son muy valiosos. Sigue estos pasos para informar eficazmente:
Antes de informar
- Consulta las incidencias existentes: busca en GitHub Issues para evitar duplicados
- Prueba la versión estable: confirma que el error solo exista en dev (no en main)
- Reprodúcelo de forma constante: ¿puedes hacer que vuelva a ocurrir?
Cómo informar de errores
🐛 Informar de un error en GitHub
Incluye esta información:
**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]
Obtener el hash del commit de Git
# Find your current dev branch commit
git rev-parse HEAD
# Or get a short version
git rev-parse --short HEAD
🏆 Contribuciones y reconocimiento
Usar la rama dev te convierte en parte de nuestra comunidad de pruebas. Las contribuciones se reconocen de varias formas:
Reconocimiento a colaboradores
- Inclusión en CONTRIBUTORS.md
- Mención en las notas de versión para contribuciones importantes
- Atribución como coautor en mensajes de commit
- Agradecimientos especiales en anuncios del proyecto
Colaboradores actuales
Nuestra fantástica comunidad incluye:
- rob - Mantenedor del proyecto
- jm - Mejora del acceso de red
- ¡Y más colaboradores! Consulta la lista completa
¿Quieres contribuir con código?
- Crea un fork del repositorio
- Crea una rama de función desde
dev:git checkout -b feature/amazing-feature dev - Realiza tus cambios
- Envía un Pull Request contra la rama
dev
Consulta nuestras directrices de contribución y el estatuto de la comunidad para conocer las directrices éticas y el modelo de gobernanza.
Comprobaciones de Pull Request
Cada Pull Request, incluso uno apilado contra una rama intermedia de función o corrección,
ejecuta el workflow Format & Lint. Sus trabajos independientes comprueban el formato,
el lint del frontend y backend, los tipos TypeScript, las pruebas de paquetes y regresión
y la suite del navegador Playwright. Las ejecuciones fallidas suben sus resultados Playwright.
El workflow Electron Dev Build también empaqueta artefactos para macOS, Windows y Linux.
Las compilaciones de macOS conservan la firma ad hoc sin credenciales para poder verificar
la aplicación antes de subirla. El workflow de Pull Request no recibe credenciales Developer ID ni de notarización.
El workflow Docker Build Test and Push compila imágenes amd64 y arm64 para cada Pull Request,
incluidos los apilados contra ramas intermedias. Estas compilaciones no inician sesión en ningún
registro, no envían digests ni publican un manifiesto multiarquitectura.
Ejecuta localmente las mismas comprobaciones antes de abrir un Pull Request:
npm run format:check
npm run lint
npm run test:package
npm run test:e2e
⚠️ Notas importantes
Seguridad de los datos
- Haz una copia de seguridad antes de cambiar a dev
- Los archivos de tareas de Work residen en volúmenes Docker con nombre
libre-work-*separados. Cópialos por separado del directorio SQLite antes de probar cambios destructivos del ciclo de vida. - Usa un volumen Docker distinto para las pruebas de dev:
# Use different volume name for devdocker run -d -p 3000:3001 -v libre-webui-dev:/app/backend/data --name libre-webui-dev ghcr.io/libre-webui/libre-webui:dev
Posibles problemas
- Los cambios incompatibles pueden exigir actualizar la configuración
- Algunas funciones pueden estar incompletas o cambiar sin aviso
- El rendimiento puede variar durante las pruebas de optimización
- Los elementos de la interfaz pueden verse o comportarse de forma inesperada
Cuándo usar la versión estable
Vuelve a la rama estable main si:
- Necesitas fiabilidad para trabajos importantes
- Encuentras demasiados errores
- Quieres una experiencia estable y probada
# 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
🌟 Únete a la comunidad
- Discusiones de GitHub: Comparte ideas y formula preguntas
- Incidencias: Informa de errores y solicita funciones
- Colaboradores: Descubre quién ayuda a crear Libre WebUI
¿Listo para ayudar a dar forma al futuro de Libre WebUI? 🚀
Tus pruebas, comentarios y contribuciones en la rama dev mejoran directamente la experiencia para todos. ¡Gracias por formar parte de nuestra comunidad de desarrollo!