- Forgejo v16.0, lanzado el 16 de julio de 2026, amplía el control de notificaciones por repositorio, el progreso de migraciones, las revisiones de pull requests, Actions y las funciones de API
- Reforzó la defensa contra SSRF bloqueando las redirecciones HTTP de los mirrors de Git; los repositorios remotos cuyo nombre o propietario haya cambiado deberán actualizar manualmente la dirección del mirror
- Si usas autenticación mediante proxy inverso en contenedores, debes especificar los rangos de direcciones de proxies confiables; algunas configuraciones existentes que exponían el puerto web predeterminado a redes no confiables dejarán de funcionar
- Se agregaron revisiones de varias líneas, seguimiento de ubicación de comentarios basado en
git blame --reverse, prioridad de ejecución de Actions, Authorized Integrations basadas en JWT, y APIs de logs, artefactos y cancelación de workflows - v16.0 es una versión no LTS, con soporte hasta el 29 de octubre de 2026; antes de actualizar, se debe crear una copia de seguridad completa y revisar todos los cambios de compatibilidad
Lanzamiento y actualización
- Forgejo v16.0 es una plataforma de colaboración de código autohospedada, ligera y desarrollada por la comunidad, lanzada el 16 de julio de 2026
- La lista completa de cambios está disponible en las notas de la versión, y también se ofrece una instancia de prueba dedicada
- Antes de actualizar, debes crear una copia de seguridad completa siguiendo la guía de actualización y revisar todos los cambios de compatibilidad
- La actualización consiste en reemplazar el binario o la imagen de contenedor por una versión compatible con v16.0
- Se ofrecen los binarios de Forgejo v16.0.0 y las imágenes de contenedor
- Si usas la etiqueta
16.0del contenedor, podrás seguir automáticamente la versión de parche16.0.Ymás reciente
Cambios de compatibilidad y refuerzo de seguridad
-
Defensa contra SSRF en mirrors de Git
- Se corrigió un problema por el cual
[migrations].ALLOWED_DOMAINS,LOCKED_DOMAINSyALLOW_LOCALNETWORKSno se aplicaban correctamente en algunos casos excepcionales - Se aplica
http.followRedirects=falsepara evitar que Git siga redirecciones al acceder a repositorios HTTP(S) y eluda la configuración - En los repositorios Forgejo remotos que hayan cambiado de nombre o se hayan transferido a un nuevo propietario, las redirecciones se tratarán como errores, por lo que los mirrors existentes deben actualizarse a la nueva dirección del repositorio
- Se corrigió un problema por el cual
-
Eliminación de la función para quitar EXIF de avatares
- La función de eliminación de metadatos EXIF de imágenes de avatar, agregada en v13.0, fue eliminada por un problema de licencia derivado del uso incorrecto de una biblioteca AGPL
- Mientras se evalúa otro enfoque de implementación, se eliminó la función para recuperar el cumplimiento de licencias
-
Configuración de proxies confiables en contenedores
- Los contenedores existentes de Forgejo usaban
REVERSE_PROXY_TRUSTED_PROXIES = *como valor predeterminado - Si se cumplían todas las siguientes condiciones, un usuario no autorizado podía hacerse pasar por otro usuario usando el encabezado
X-WebAuth-User- Despliegue en contenedores basados en Docker o Podman
- Configuración de
[service].ENABLE_REVERSE_PROXY_AUTHENTICATION=true - Valor predeterminado
*de[security].REVERSE_PROXY_TRUSTED_PROXIESsin modificar - Puerto web predeterminado
:3000expuesto a una red no confiable, lo que permitía eludir el proxy inverso de autenticación
- v16 ya no respeta la configuración de proxy inverso en este tipo de despliegues, por lo que se deben especificar los rangos de direcciones de proxies confiables por donde ingresa el tráfico
- Un ejemplo de configuración con variables de entorno es
FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES=127.0.0.0/8,::1/128,172.16.X.X/X - En
app.ini, se configura la misma lista de direcciones enREVERSE_PROXY_TRUSTED_PROXIES, debajo de[security]
- Los contenedores existentes de Forgejo usaban
Usabilidad de repositorios y organizaciones
- Las notificaciones de repositorio se pueden suscribir por separado en tres categorías: Issues, pull requests y releases
- El backend de notificaciones rediseñado servirá como base para admitir configuraciones más granulares en el futuro
- El objetivo es dar a los usuarios control sobre las notificaciones sin exponer una cantidad excesiva de opciones
- La pantalla de migración de repositorios muestra el progreso del traslado por lotes de issues y pull requests desde el origen, lo que permite verificar si una operación larga se detuvo
- El tamaño de lote predeterminado es de 45 elementos, y la cantidad mínima de elementos para mostrar el progreso también es 45
- En lugares donde no se necesita el tamaño completo, se generan dos avatares reducidos para disminuir el uso de ancho de banda y el tiempo de carga
- Desde la lista de miembros de una organización, se puede abrir directamente un cuadro de diálogo para agregar un nuevo miembro y asignarlo a varios equipos de una sola vez
- Git revisa y rechaza múltiples inconsistencias en los objetos recibidos, evitando que el repositorio quede en un estado inconsistente o dañado
- Los archivos de hooks de ejemplo de Git ya no se generan en el repositorio backend, y los hooks de Git comunes a la instancia se almacenan de forma centralizada en lugar de duplicarse en cada repositorio
- Se ahorran aproximadamente 20 KiB por repositorio
- Los archivos de ejemplo y los archivos duplicados generados automáticamente en repositorios existentes pueden eliminarse siguiendo la guía de actualización
- Se corrigió un bug presente desde v7.0.0 que impedía mostrar a los usuarios nuevos la indicación para activar más funciones del repositorio, y también se hizo más fácil encontrar la configuración para desactivar esa indicación
- La indicación “Enable more” aparece solo cuando un administrador o el propietario del repositorio desactivó explícitamente algunas funciones del repositorio
Pull requests y revisión de código
- La lista de commits en la página de pull request cambió a un nuevo layout más legible y adaptable al tamaño de pantalla
- Por ahora solo se aplica a la página de pull request, con planes de extenderlo gradualmente a otras pantallas de listas de commits
- Se admiten revisiones de varias líneas, que vinculan varias líneas modificadas a un solo comentario de revisión
- Si mantienes presionada la tecla
Shift, haces clic en el botón de suma junto a la primera línea y arrastras hasta la última, las líneas seleccionadas se vinculan a un único comentario
- Si mantienes presionada la tecla
- Se corrigieron problemas en los que los comentarios de revisión aparecían en el diff o la posición de pantalla incorrectos, o perdían la asociación con el diff
- El
git blameexistente podía ubicar mal un comentario si el código objetivo se movía en commits posteriores - Internamente se usa
git blame --reversepara rastrear los cambios del código hasta su ubicación actual - La ubicación del comentario se calcula no solo con el HEAD del pull request actual, sino también con la base y el head que el revisor está viendo realmente, y con el commit del código mostrado
- En el caso de líneas eliminadas, se identifica el momento de la eliminación y se verifica si en la misma posición del diff actual también están eliminadas; luego se coloca el comentario o se marca como comentario antiguo
- El
Forgejo Actions e integración con JWT
-
Prioridad de ejecución y gestión de workflows
- Las ejecuciones individuales de workflows pueden marcarse manualmente para procesarse con prioridad, y Forgejo Actions las procesa antes que las ejecuciones normales
- Cuando es posible, Forgejo evalúa directamente las condiciones
ify no envía la tarea a Forgejo Runner, lo que permite iniciar la ejecución más rápido - Las ejecuciones de workflow finalizadas, junto con sus logs y artefactos, pueden eliminarse desde la UI o la API HTTP
- Solo pueden eliminarlas administradores del repositorio o tokens de acceso con permiso
write:repository
- Solo pueden eliminarlas administradores del repositorio o tokens de acceso con permiso
- Las expresiones
cronadmiten la sintaxis de especificación de zona horaria al estilo de GitHub, además del formato existenteCRON_TZ - Las comprobaciones omitidas que en versiones anteriores se mostraban como exitosas se muestran como skipped a partir de v16
-
Authorized Integrations
- Tras agregar en v15 la generación de JWT para que sistemas externos pudieran usarlos en la autenticación, v16 ofrece Authorized Integrations para autenticar el acceso a la API de Forgejo y a Git mediante JWT
- Puede usarse en Forgejo Actions locales, o configurando reglas para que Forgejo valide JWT arbitrarios
- Cuando se necesita acceso más allá de los permisos normales de
${{ forgejo.token }}, ya no hace falta configurar un token de acceso estático ni rotarlo en el futuro - No expone una función que permita a los autores de workflows otorgarse permisos inesperados por su cuenta
- Puede usarse en múltiples repositorios de Forgejo
- Los sistemas externos que cumplan los requisitos técnicos pueden acceder directamente a la API de Forgejo y a los repositorios Git mediante la Authorized Integration del usuario, sin secretos estáticos entre sistemas
- Algunos ejemplos son Amazon Web Services, GitHub Actions y GitLab CI/CD
Actions y API de administración
- Se agregó una API para obtener los logs de una ejecución completa de workflow o de un trabajo individual
- Se ofrecen endpoints para listar, descargar y eliminar artefactos
- El endpoint documentado para la carga de artefactos queda pendiente para trabajos futuros
- Se agregó una API para cancelar una ejecución individual de workflow
/actions/rundevuelve la información de la ejecución de workflow a la que pertenece el token automáticoFORGEJO_TOKEN- Otros cambios de API incluyen los siguientes
- Se agregó la hora de creación al modelo de organización devuelto por varios endpoints
- La búsqueda de pull requests permite filtrar por nombre de rama base y head
- Los administradores de instancia pueden listar, emitir y eliminar tokens de acceso de usuarios
- La lista de usuarios se puede filtrar por estado de 2FA
Periodo de soporte y builds de prueba
- Las versiones mayores salen cada 3 meses, y las versiones de parche se publican con mayor frecuencia según la gravedad de los bugs o correcciones de seguridad incluidas
- v16.0 es una versión no LTS y tendrá soporte hasta el 29 de octubre de 2026
- El soporte de v11.0 LTS finalizó el 16 de julio de 2026
- v15.0 LTS tendrá soporte hasta el 15 de julio de 2027
- v17.0 está prevista para el 15 de octubre de 2026 y se espera que tenga soporte hasta el 28 de enero de 2027
- Se generan builds diarios
16.0-testcon los últimos cambios de la rama de desarrollov16.0/forgejoy se despliegan en la instancia de prueba- Se ofrecen la imagen OCI root, la imagen OCI rootless y los binarios
- El nombre del build se mantiene, pero se reemplaza por un build nuevo cada día
1 comentarios
Comentarios en Lobste.rs
@pushcx, ¿a dónde se fue el enlace suggest? Quería sugerir la etiqueta
vcs, pero ahora no veo el enlace en ninguna publicación.Gracias a todos los contribuidores, especialmente al equipo de merge. Personalmente, me enorgullece haber contribuido a la corrección de https://forgejo.org/2026-07-release-v16-0/#repository-units-hint
Durante varios días configuré y ajusté un Forge personal en https://forge.l3x.in y fui migrando gradualmente desde GitHub; el autohospedaje de Forgejo fue una experiencia muy satisfactoria y lo recomiendo mucho.
He oído que SourceHut también es bueno, pero no lo he probado directamente, y por ahora estoy concentrado en Forgejo.
Me alegra ver la función de revisiones de varias líneas y posicionamiento de comentarios de revisión. En
$JOBno hay revisiones de código, así que no estoy acostumbrado, y algunas veces malinterpreté a qué bloque de código se referían los comentarios cuando me revisaban parches enviados a proyectos libres y de código abierto.Me entusiasman mucho las opciones de suscripción granulares. Era una función que usaba en GitHub y la extrañaba muchísimo en Forgejo.
También en GitHub desde hace mucho quería una función para suscribirse cuando se crean nuevos issues y PR. Porque así podría seguir el desarrollo de proyectos a los que contribuyo solo de vez en cuando, sin tener que cancelar manualmente la suscripción al 90% de las notificaciones que no me interesan.
Registré una solicitud de función en el repositorio de Forgejo: https://codeberg.org/forgejo/forgejo/issues/13494
Llevo un tiempo operando Forgejo en mi homelab y estoy muy satisfecho. Migré unas 500 repositorios que tenía en Github.com, y el proceso casi no tuvo inconvenientes; estoy ejecutando Forgejo y runners dentro de k8s.
Me resultó especialmente práctico que Forgejo Runner use definiciones de workflow como las de GitHub Actions; solo tuve que crear las etiquetas correctas en el runner local.
Todavía no decido si dejar GitHub en modo solo lectura, eliminarlo o mantenerlo como un mirror equivalente. Sea como sea, ahora hago push directamente a mi instancia de Forgejo en vez de a GitHub, y todo el trabajo es mucho más rápido, en cuestión de segundos.