Saltar al contenido principal

🧪 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.

Software experimental

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

  1. Inicia Docker y confirma que docker info funcione para el mismo usuario que ejecuta el backend.
  2. Inicia Libre WebUI desde el código con npm run dev.
  3. Inicia sesión como administrador.
  4. 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

  1. Consulta las incidencias existentes: busca en GitHub Issues para evitar duplicados
  2. Prueba la versión estable: confirma que el error solo exista en dev (no en main)
  3. 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?

  1. Crea un fork del repositorio
  2. Crea una rama de función desde dev: git checkout -b feature/amazing-feature dev
  3. Realiza tus cambios
  4. 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 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

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


¿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!