1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • 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

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_DOMAINS y ALLOW_LOCALNETWORKS no se aplicaban correctamente en algunos casos excepcionales
    • Se aplica http.followRedirects=false para 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
  • 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_PROXIES sin modificar
      • Puerto web predeterminado :3000 expuesto 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 en REVERSE_PROXY_TRUSTED_PROXIES, debajo de [security]

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
  • 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 blame existente podía ubicar mal un comentario si el código objetivo se movía en commits posteriores
    • Internamente se usa git blame --reverse para 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

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 if y 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
    • Las expresiones cron admiten la sintaxis de especificación de zona horaria al estilo de GitHub, además del formato existente CRON_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/run devuelve la información de la ejecución de workflow a la que pertenece el token automático FORGEJO_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-test con los últimos cambios de la rama de desarrollo v16.0/forgejo y se despliegan en la instancia de prueba

1 comentarios

 
GN⁺ 4 시간 전
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.

    • A mí me pasa lo mismo, así que quisiera saber por qué.
    • Actualmente veo el enlace suggest en esta publicación y en la mayoría de las publicaciones de la página de inicio, y tampoco hay historial de acciones sobre la cuenta en https://lobste.rs/moderations. Parece un bug.
  • 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 $JOB no 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.