Nueva CI, Nuevo Repo: Un Impulso Renovado para 10.9.0

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Durante las últimas semanas, he liderado un esfuerzo importante para renovar y mejorar nuestra CI (Integración Continua), con el objetivo de optimizar nuestro flujo de lanzamientos, aumentar la velocidad de publicación y reducir la carga que representan para mí como gestor de versiones. Esta publicación detallará los cambios implementados, cómo podrían afectarte como usuario o colaborador, y cómo planeamos avanzar con el ciclo de lanzamiento de la 10.9.0.

En resumen

1. Contamos con una nueva interfaz de navegación de repositorios junto con una estructura de archivos renovada, en una nueva máquina maestra de repositorio, construida por una nueva CI. Esto facilitará encontrar lo que necesitas. Ya está en producción, aunque sigue siendo un trabajo en progreso, así que ¡reporta cualquier error que encuentres! Ten en cuenta que muchas rutas habrán cambiado (especialmente bajo /server), aunque algunas permanecerán iguales. Si recibes un error 404 y no lo encuentras en la interfaz, verifica con nosotros. Los empaquetadores de terceros que descarguen archivos manualmente deben contactarnos si lo necesitan.

2. Dejaremos de ofrecer paquetes Ubuntu no LTS, eliminaremos nuestros propios paquetes Fedora/CentOS en favor de compilaciones RPMFusion, y añadiremos GHCR como repositorio de contenedores para nuestras imágenes Docker.

3. Para la 10.9.0, no publicaremos versiones "beta" explícitas. En su lugar, realizaremos pruebas usando nuestras nuevas compilaciones inestables semanales. Cuando la rama master alcance suficiente estabilidad, lanzaremos la 10.9.0 directamente desde allí (mediante nuestro proceso estándar de rama de lanzamiento).

4. La congelación de características para la 10.9.0 (solo se aceptarán PRs de corrección de errores después de esta fecha) comenzará tentativamente el lunes 18 de marzo. Esperamos que todos los cambios anteriores estén listos para entonces, facilitando la obtención de compilaciones inestables para pruebas.

5. El lanzamiento de la 10.9.0 está planificado tentativamente para el último fin de semana de abril. A todos los terceros que empaquetan nuestras versiones: lean hasta el final para una nota importante sobre este lanzamiento.

Continúa leyendo para más detalles.

- Joshua

¿Por qué construir una nueva CI?

Nuestra antigua CI fue configurada allá por 2019 por miembros dedicados del equipo (principalmente @EraYan) usando Azure DevOps. Si bien fue una gran mejora frente a mi sistema de compilación propio basado en BASH puro que usamos el primer año, aún presentaba inconvenientes:

1. Era algo compleja de entender y dependía de un sistema externo (Microsoft Azure).

2. Seguía requiriendo un script BASH muy complejo y propenso a errores para finalizar las compilaciones, porque...

3. Compilaba los componentes Servidor y Web de Jellyfin de forma independiente, activados por eventos de etiquetas en repositorios distintos, lo que obligaba a complicados procesos para combinar los resultados en paquetes unificados y amigables.

Existía además, aunque no era un defecto del sistema de CI en sí, el tema de las compilaciones inestables. Durante mucho tiempo se generaban con cada PR fusionado, lo que ayudaba a verificar rápidamente los cambios, pero las hacía prácticamente inutilizables para usuarios normales al actualizarse constantemente. Esto también queríamos solucionarlo.

En ese momento, GitHub Actions aún no existía, y aunque logramos que todo funcionara, la CI en conjunto era engorrosa y propensa a fallos. Los lanzamientos importantes solían llevarme más de 20 horas-hombre de preparación y ejecución, mientras que las versiones menores requerían al menos 4-6 horas. Era una carga enorme como gestor de lanzamientos, y también muy engorroso solucionar problemas cuando algo fallaba de formas oscuras, especialmente después de la etiqueta, porque toda la CI estaba en los repositorios de código.

Todo esto significaba que nuestra velocidad de lanzamiento era extremadamente lenta, ya que nunca existió un flujo claro entre las pruebas en la rama master y la preparación del siguiente lanzamiento.

En lugar de seguir ajustando incrementalmente esta configuración, hace unos 2 años @ferferga y @h1dden-da3m0n (que desde entonces se ha retirado) iniciaron un proyecto para migrar a GitHub Actions. Aunque sentaron gran parte de las bases, ese proyecto finalmente se estancó y quedó abandonado. A principios de este año, retomé la iniciativa para completarlo en preparación para la 10.9.0, logrando que funcione bien de una forma mucho más comprensible y, esperemos, considerablemente más consistente.

Más automatización

El siguiente paso, más allá de la CI en sí, es un bot de automatización. Como mencioné, los lanzamientos tomaban mucho tiempo, pero solo una fracción se dedicaba realmente a Azure. El resto era trabajo administrativo: construir changelogs, asegurar la sincronía de repositorios, ejecutar scripts de bump-version, crear borradores de lanzamiento, revisarlos 3 veces y aún así pasar algo por alto, redactar anuncios para nuestro Foro, etc. Todo esto sumaba una inversión de tiempo significativa que rara vez tenía ganas de realizar, lo cual a su vez perjudicaba nuestra velocidad.

Ningún proyecto debería depender tanto de una sola persona, pero fue nuestro caso durante mucho tiempo. Parte del objetivo con esta mejora de la CI es optimizar todos estos aspectos mediante otra pieza de automatización: un chatbot privado.

La meta es que podamos decirle a nuestro chatbot que estamos listos para un lanzamiento, que él prepare automáticamente todo el texto y, tras revisión, indicarle que está listo para publicar. Esto no solo facilita el proceso para mí, sino que otros pueden ejecutarlo fácilmente. Y con una CI más confiable, esperamos lograr un proceso de lanzamiento de "configurar y olvidar" que nos ayude a aumentar masivamente la velocidad.

Aunque el bot aún no está completamente terminado, los cimientos están listos y definitivamente esperamos que esté operativo para el lanzamiento real de la 10.9.0.

Unificación de paquetes

Un gran inconveniente que mencionamos de la CI anterior era cómo trataba por separado los componentes de servidor y web de Jellyfin. Esto se debía a que ambos componentes efectivamente están separados en el código, en repositorios GitHub distintos y con diferentes grupos liderándolos. El problema es que así no consume Jellyfin el usuario final. Los usuarios quieren un solo paquete, instalador o archivo que instalen y funcione inmediatamente. Así que debíamos hacer muchos malabarismos complejos para combinar los paquetes.

Eso se acabó. Con la CI actualizada, todo nuestro empaquetado está unificado y separado en su propio repositorio dedicado. Este repositorio gestiona los dos repositorios de código mediante submódulos y un sencillo script en Python que sincroniza qué versión se extrae de cada uno antes de una compilación. Luego, otro script de Python maneja la compilación real, que a su vez se invoca desde GitHub Actions. Sigue siendo un poco enrevesado, pero esto es inevitable dada la complejidad final de empaquetar nuestro software, y la esperanza es que tener esto en Python (un lenguaje robusto pero fácil de entender) garantice que el proceso no sea tan opaco como antes.

Lo que esto significa depende de los diferentes tipos de empaquetado. Para Debian y Ubuntu, ahora existe un único paquete fuente Debian para los tres paquetes binarios resultantes (metapaquete, web y servidor), por lo que los tres pueden construirse simultáneamente con un único comando dpkg-buildpackage. Para los archivos comprimidos, significa que ambos componentes (servidor y web) se compilan secuencialmente y se combinan en un solo archivo durante la construcción, en lugar de hacerlo de forma desordenada después, un proceso que falló más veces de las que podíamos contar. Para los instaladores, el proceso ahora es más simple y puede automatizarse. Finalmente, para Docker, significa que ahora ofrecemos una única imagen, jellyfin/jellyfin, construida de una sola vez sin depender de dos imágenes intermedias, otro proceso muy propenso a errores.

Relacionado con esto, y como parte de las compilaciones unificadas, cada versión de Debian y Ubuntu ahora tiene su propio paquete diferenciado, con sufijos de versión como -deb12 o -ubu2204. Esto ayudará a garantizar un manejo fluido de dependencias para bibliotecas compartidas como LibSSL. Esto solo debería importar si descargas paquetes .deb directamente del repositorio: asegúrate de descargar el adecuado para tu distribución.

Como usuario final normal, no deberías notar diferencias por esto: seguirás instalando los paquetes igual que siempre a través de nuestros repositorios. Pero para quienes construyan sus propias versiones, ahora se recomienda usar el repositorio mencionado, ya que todo el empaquetado no relacionado con desarrollo (por ejemplo, las carpetas debian/ y fedora/, la carpeta deployment/, etc.) se eliminará de los repositorios principales, dejando solo un Dockerfile simple para construir imágenes de prueba y desarrollo rápidamente.

Un nuevo repositorio maestro para un nuevo sistema de CI

Una ventaja que permite la CI reconstruida desde cero y los paquetes unificados es una estructura de repositorio mucho más limpia. Nuestra estructura anterior se basaba en requisitos de combinación, llena de peculiaridades extrañas y directorios anidados para intentar simplificarlo. Al eliminar esos obstáculos, pudimos establecer un diseño mucho más agradable y, por lo tanto, un nuevo servidor maestro para alojarlos y facilitar la transición.

Parte de esto también incluye una página de navegación renovada para facilitar el acceso a los archivos que necesitas, recorriendo el árbol del nuevo diseño de forma mucho más intuitiva.

El nuevo navegador y repositorio maestro ya está activo al momento de esta publicación en https://repo.jellyfin.org, y aún incluye los paquetes de lanzamientos estables en el nuevo formato para tu conveniencia hasta que se lance la versión 10.9.0. Así que, como se mencionó en el preámbulo, por favor pruébalo y avísanos si encuentras algún problema, enlaces rotos o inconvenientes similares.

Lanzamientos inestables

Como se mencionó antes, nuestro anterior enfoque de "construir con cada fusión de pull request" era muy engorroso de usar, ya que los cambios ocurrían muy rápidamente y mantener a los probadores actualizados era casi imposible durante períodos de alta actividad. En los primeros días, habíamos probado compilaciones diarias antes de adoptar este modelo, pero incluso esas resultaban demasiado rápidas tanto para nuestro ritmo de desarrollo actual como para que los usuarios se mantuvieran adecuadamente actualizados.

En cambio, de ahora en adelante adoptaremos un ciclo semanal para los lanzamientos inestables. Las compilaciones se realizarán los lunes alrededor de la medianoche, hora del Este (UTC-5/4-con-horario-de-verano), un horario elegido arbitrariamente pero que asegura que cada semana comience con una nueva compilación inestable. Este proceso está completamente automatizado, y los resultados estarán disponibles poco después en todos nuestros canales habituales.

Esperamos que este ritmo más pausado ayude a que los usuarios que ejecutan nuestras compilaciones inestables tengan más oportunidades de probar el estado actual de Jellyfin sin sentirse abrumados por la velocidad de los lanzamientos, al mismo tiempo que proporciona un movimiento lo suficientemente rápido para probar verdaderamente las últimas características y correcciones de errores.

Una nota final, mencionada con más detalle a continuación, es que estas compilaciones inestables semanales servirán como nuestras pruebas pre-lanzamiento para la 10.9.0: no habrá lanzamientos etiquetados como "beta" o "rc" en este ciclo. Esto se hace para evitar la gran carga que encontramos con la 10.8.0 al intentar portar continuamente las correcciones del próximo lanzamiento estable a la rama principal, mientras también portábamos correcciones de errores en sentido contrario cuando se asignaban incorrectamente.

Limpieza de lo que construimos

Como se mencionó en el TL;DR, estamos haciendo tres cambios importantes en lo que construimos, tanto para las versiones Inestables (Unstable) como para la próxima versión 10.9.0:

1. Estamos eliminando todas las versiones no LTS de Ubuntu de nuestro repositorio oficial de paquetes APT.

   La razón es simple: es una gran carga mantener el ritmo del ciclo de lanzamientos de 6 meses de Ubuntu, solo para admitir versiones menores con una vida útil de 9 meses. Si bien entendemos que la gente puede querer ejecutar Jellyfin en escritorios o asegurarse de que sus servidores tengan "lo último", esto simplemente no es sostenible para nosotros a largo plazo. Por lo tanto, en adelante, nuestros paquetes solo tendrán como destino las versiones LTS, comenzando con 20.04 "Focal", e incluyendo 22.04 "Jammy" y la nueva 24.04 "Noble" que se lanzará en abril.

   Si estás usando una versión no LTS de Ubuntu, aún tienes opciones. Primero, siempre puedes actualizar a 24.04 y usarla en adelante. Sin embargo, ten en cuenta que 24.04 será la última versión para la que construiremos hasta que salga 26.04. Alternativamente, si aún deseas mantener tu sistema en la ruta de actualización de 6 meses, puedes migrar a nuestras imágenes de Docker, que tienen el beneficio adicional de una estabilidad a largo plazo incluso cuando cambie tu sistema operativo base.

2. Estamos abandonando nuestras compilaciones RPM "oficiales" para distribuciones Fedora y CentOS (y similares) en favor de RPMFusion:

   Estas compilaciones siempre han sido un poco problemáticas para nosotros. Estaban poco mantenidas (a pesar de algunos esfuerzos valientes y contribuciones de la comunidad), se rompían con frecuencia, y todo esto llegó a un punto crítico cuando comenzamos a trabajar en una especificación combinada.

   Afortunadamente, un miembro de la comunidad (@mooninite) ya ha estado manteniendo una compilación estable combinada de Jellyfin en RPMFusion. Este parecía el momento perfecto para cambiar a eso, reduciendo otra carga de empaquetado para nosotros, y además (finalmente) proporcionando un repositorio "real" para nuestros usuarios basados en RPM. La compilación de RPMFusion ahora es la compilación oficial de Fedora/CentOS que aparece en nuestra página de descargas y lo será en el futuro. También estamos tomando medidas para obtener una compilación empaquetada de FFmpeg allí, así que estad atentos.

   Se recomienda a los usuarios de versiones Inestables en Fedora/CentOS que sigan usando el contenedor Docker, ya que este incluye FFmpeg actualmente y ayuda a garantizar actualizaciones rápidas.

3. Finalmente, estamos agregando soporte para GHCR (ghcr.io) para nuestras imágenes de Docker. Esto ayudará a garantizar que, incluso si algo le sucediera a Docker Hub, haya otra fuente para nuestras imágenes de Docker. Si lo deseas, puedes usar esta fuente inmediatamente para las compilaciones Inestables, y para la 10.9.0 cuando se lance.

El ciclo de lanzamiento de la versión 10.9.0

Como describimos en esta discusión de GitHub, todos estos cambios significan que habrá algunos cambios importantes en cómo abordamos el ciclo de lanzamiento de la versión 10.9.0. Para aclarar, el proceso exacto será el siguiente:

1. A partir de ahora, y de forma indefinida para todos los lanzamientos futuros, las compilaciones Inestables Semanales (Weekly Unstable) actuarán como las versiones "beta". Es decir, si quieres ayudarnos a probar, o simplemente mantenerte al día con las funciones más recientes, usa las versiones Inestables. Las instrucciones que se encuentran en nuestra página de Descargas siguen siendo aplicables para habilitar las compilaciones Inestables, y también se enumeran todas nuestras plataformas Inestables admitidas.

2. A medida que nos acerquemos a la fecha de lanzamiento planificada, comenzaremos una congelación de características. Durante la congelación de características, solo se aceptarán PRs de corrección de errores. Esperamos que esto dure entre 3 y 5 semanas. Actualmente, la fecha tentativa de inicio es el lunes 18 de marzo. Durante la congelación, las compilaciones Inestables deberían ser consistentes y funcionales, con solo las correcciones menores que se fusionen.

3. Como usuarios, por favor sean diligentes al informar errores en las versiones Inestables. Nuestro equipo de Clasificación (Triage) ha sido muy diligente en los últimos meses asegurándose de que los problemas se clasifiquen y examinen, ¡por lo que es de vital importancia que cualquier persona que use las versiones Inestables informe correctamente sus errores!

4. A medida que nos acerquemos a la estabilidad, es decir, tras las 3-5 semanas de corrección exclusiva de errores, tomaremos la decisión de realizar la versión final definitiva. Personalmente, espero completar esto durante el fin de semana del 27-28 de abril, aunque podría cambiar según cómo avancemos durante la fase de congelación.

5. El lanzamiento finalmente ocurrirá. Crearemos una nueva rama de release, etiquetaremos la versión y -usando el nuevo sistema de CI mencionado- realizaremos la publicación. Queremos asegurarnos de que cualquier tercero que utilice eventos de Tag en nuestros repositorios por favor desactive esta función para este lanzamiento, ya que anticipamos encontrar al menos uno o dos obstáculos al ejecutar el proceso "realmente". Una vez que la situación se estabilice, garantizaremos que vuestros lanzamientos se construyan, especialmente si necesitamos acciones drásticas como re-etiquetar la versión. A largo plazo, implementaremos un mejor proceso de coordinación, por lo que queremos colaborar con los mantenedores externos - contactadnos.

6. En ese momento, la rama master reanudará su funcionamiento normal e iniciaremos el ciclo de corrección de errores estable para 10.9.0. Esperamos que con estas mejoras, 10.10.0 no tarde mucho en llegar después, quizás en 3-6 meses, momento en que este proceso comenzará de nuevo.

¡Estamos muy cerca, tras más de 2 años de trabajo! Por eso queríamos asegurarnos de difundir este plan ampliamente, especialmente para incentivar que más personas prueben las nuevas compilaciones inestables y reporten errores mientras preparamos el lanzamiento final.

Reflexiones finales

Esto resume básicamente mis ideas actuales, tanto sobre la hoja de ruta hacia 10.9.0 como sobre las mejoras que estamos implementando y ya hemos realizado en el proceso de lanzamiento. ¡Feliz visualización!