Actualizaciones de empaquetado para 10.6.0
Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →
El empaquetado y construcción de binarios para lanzamientos y pruebas ha sido un problema persistente para nosotros. Desde lidiar con scripts improvisados, probar cambios disruptivos, hasta ajustar lanzamientos oficiales, nuestra forma de trabajar durante el último año y medio necesitaba mejoras.
Afortunadamente, hoy ya están completadas. En esta publicación detallaré los cambios y lo que implican para nuestros usuarios.
Para un resumen rápido: para la mayoría de usuarios de nuestras versiones estables, casi nada cambiará, y actualizarán a 10.6.0 como siempre. Para quienes usen versiones nocturnas para pruebas, configuraciones avanzadas, o simplemente sean curiosos: ¡continúen leyendo!
Compilaciones separadas
El primer componente clave de los cambios es la separación de compilaciones. Anteriormente dependíamos de soluciones improvisadas para construir tanto la interfaz web (https://github.com/jellyfin/jellyfin-web) como el servidor (https://github.com/jellyfin/jellyfin) y combinarlos en un solo paquete. Finalmente, con el gran volumen de cambios en ambos repositorios y la velocidad de actualizaciones, junto con nuestro objetivo de desacoplar ambos componentes para lanzamientos, esta solución alcanzó sus límites. Esto se ejemplifica mejor con el trabajo casi invisible que requirió hacer funcionar las versiones 10.5.4 y 10.5.5.
Con paquetes separados, ambos repositorios ahora se compilan completamente de forma independiente para todas las plataformas. Si compilas el repositorio jellyfin-web, obtienes una imagen Docker, paquetes .deb, .rpm o un archivo .tar.gz que solo contiene la interfaz web. Similarmente, al compilar jellyfin, obtienes las diversas imágenes Docker, paquetes .deb, .rpm, archivos .tar.gz y .zip que conoces.
La diferencia principal está en la nomenclatura: los binarios de jellyfin-web se llaman jellyfin-web, y los de jellyfin se denominan jellyfin-server. Tomando Debian como ejemplo: donde antes existía jellyfin, ahora hay jellyfin-web y jellyfin-server. Pero no te preocupes, jellyfin no desapareció - lo explicaremos pronto.
Compilaciones con Azure Pipelines
Nuestra infraestructura de compilación anterior consistía en una auténtica fábrica de espaguetis de scripts Bash, Python y Docker que se ejecutaban en nuestro servidor de compilación, un droplet de DigitalOcean. En general, funcionaba, pero el proceso era muy frágil, opaco (¡ni siquiera yo estoy seguro de entender cómo funcionaba todo siempre, y yo lo escribí todo!) y consumía muchos recursos.
Al migrar cada vez más funciones a Azure para pruebas, verificación, linting, etc., resultó evidente que Azure Pipelines ofrece gran flexibilidad y podría ejecutar casi todos nuestros pasos de compilación. Esto eliminó al menos 2/3 del servidor de compilación y nos brinda otra ventaja: compilaciones inestables, que mencionaré pronto.
Azure Pipelines maneja la construcción real de todos los archivos para ambos repositorios, sube los artefactos binarios al servidor de compilación, y ejecuta un único script para el último tercio del proceso, haciendo todo más transparente, comprensible y con resultados visibles para todos en nuestra página de proyecto de Azure.
Meta-paquetes y Meta-imágenes
Anteriormente mencioné que el paquete que solía llamarse jellyfin ahora se llama jellyfin-server y no incluye la interfaz web. Entonces, ¿cómo se obtiene todo? ¿Y cómo serán las actualizaciones transparentes? La respuesta son los metapaquetes, metaarchivos y metaimágenes! Estos nuevos componentes se encuentran en esta página del repositorio, específicamente las imágenes Docker que ahora serán la fuente de verdad para esas configuraciones. A continuación detallo cómo funciona cada plataforma.
Para Docker, las compilaciones separadas de Azure Pipelines crean imágenes llamadas jellyfin/jellyfin-server y jellyfin/jellyfin-web. Por sí solas no son muy útiles, pero existen para habilitar el siguiente paso. Cuando una compilación de Azure finaliza y ha subido estas imágenes, se ejecuta un script en nuestro servidor de compilación que construye la "metaimagen" jellyfin/jellyfin, que toma las dos imágenes separadas y las combina en una sola imagen Docker junto con todos los componentes para ejecutarlos, como jellyfin-ffmpeg, luego sube la imagen resultante. El resultado final es una única imagen, jellyfin/jellyfin, como siempre ha existido, pero las compilaciones se realizan de forma independiente en lugar de depender de git clone/descargas de archivos dentro de los pasos de compilación y otras artimañas.
Para Debian y Ubuntu, las compilaciones separadas de Azure Pipelines crean paquetes .deb separados para cada componente. A diferencia de Docker, estos son completamente funcionales por sí solos, y se puede instalar Jellyfin en 10.6.0+ con apt install jellyfin-server jellyfin-web si se desea. El metapaquete es un .deb separado, llamado jellyfin, cuya única función es tener dependencias de estos dos paquetes componentes. Por lo tanto, instalar jellyfin instalará automáticamente jellyfin-server y jellyfin-web, junto con las otras dependencias requeridas de cada uno. Así es como las actualizaciones serán transparentes desde versiones anteriores: actualizar desde el antiguo jellyfin al nuevo jellyfin incluirá automáticamente los dos nuevos subpaquetes y eliminará el antiguo, sin interrupciones.
Para Fedora y CentOS, la configuración es similar a Debian/Ubuntu, con la única diferencia de que el metapaquete es un componente del repositorio jellyfin-server y, por lo tanto, solo se recompila cuando ese repositorio lo hace. Sin embargo, dado que no proporcionamos un repositorio "adecuado" para estos paquetes como hacemos para Debian/Ubuntu, el impacto debería ser bastante bajo y será inexistente para las versiones estables.
Para los instaladores de Windows y los paquetes .app de macOS, el proceso sigue siendo un poco más complicado y está en desarrollo, pero seguirán funcionando en el lanzamiento.
Para las plataformas restantes, incluidos los paquetes de archivos para Windows, macOS, Linux y .NET portable, el proceso toma los dos archivos .tar.gz/.zip separados del proceso de compilación y los combina en un único archivo jellyfin del mismo tipo, que coloca los dos componentes en sus respectivos lugares. Por lo tanto, como todos los demás mencionados anteriormente, el cambio debería ser invisible para los usuarios al descargar la versión "combinada" de los archivos.
Compilaciones inestables
Una de las ventajas que permite esta nueva configuración son las compilaciones "inestables". Durante bastante tiempo, hemos estado proporcionando (cuando no estaban rotas) compilaciones "nocturnas", que como su nombre indica se compilan cada noche si hubo PRs fusionados el día anterior. Sin embargo, estas tenían varios inconvenientes. Primero, fallaban mucho; segundo, en un día ajetreado podía haber hasta una docena de PRs separados que formaban el conjunto de cambios nocturno; tercero, a menudo podían estar completamente desconfigurados en términos de contenido, por ejemplo si la compilación no separada tomaba la versión incorrecta de Web.
Las nuevas compilaciones separadas, las compilaciones de Azure y los metapaquetes/metaimágenes, en cambio, nos permiten hacer algo muy superior: construir lanzamientos "inestables" para cada PR fusionado. Ya no tenemos que preocuparnos por el uso de recursos (Azure lo proporciona), el espacio en disco u otros aspectos del proceso de compilación. Podemos saber de inmediato si algo se rompe. Y lo más importante, permite que cualquiera pruebe nuestra rama master de una manera muy clara, sabiendo exactamente qué versión del repositorio está utilizando y cuál fue el último PR fusionado si algo sale mal.
Las compilaciones inestables se versionan según el ID de compilación de Azure, que tiene el formato "[fecha].[id]", por ejemplo "20200620.12" para la 12ª compilación del 20 de junio de 2020. Así, esta cadena de versión te indicará exactamente qué compilación de Azure generó el binario y, por tanto, qué PR en qué repositorio la activó. Para aquellos binarios con registros de cambios (solo paquetes .deb y .rpm por ahora), los datos del registro de cambios también incluyen explícitamente el ID del PR.
Uso de compilaciones inestables
Usar compilaciones inestables es un poco diferente a los nightlies anteriores. Para esos, los paquetes/imágenes se llamaban jellyfin-nightly o jellyfin:nightly (en Docker) y se almacenaban en los mismos repositorios. Esto ha cambiado un poco ahora, y detallaré los cambios para cada plataforma a continuación. Ten en cuenta que, al menos hasta que se lance la versión 10.6.0, continuaremos construyendo imágenes nightly como siempre, después de lo cual se desactivarán en favor exclusivo de las compilaciones unstable, así que si te gusta vivir al límite, revisa esta sección en detalle y realiza los cambios necesarios lo antes posible.
Para Docker, las nuevas compilaciones inestables están disponibles con la etiqueta unstable, por ejemplo jellyfin/jellyfin:unstable, o con una etiqueta de versión específica, como jellyfin/jellyfin:20200620.12-unstable. Seguir la etiqueta principal unstable garantizará que siempre puedas obtener la última compilación inestable, mientras que las etiquetas versionadas te permiten descargar compilaciones específicas para pruebas o depuración.
Para Debian y Ubuntu, ha cambiado dónde se almacenan las imágenes inestables. Como se mencionó, antes formaban parte de la sección main del repositorio con el nombre alternativo jellyfin-nightly, y esto ya no es así para las inestables. En su lugar, se ha creado un "componente" de repositorio separado llamado unstable para albergar las compilaciones inestables, y no se renombran. Para habilitar este componente adicional, añade una línea en tu /etc/apt/sources.list.d/jellyfin.list como la siguiente, idéntica a la línea existente pero reemplazando main por unstable: deb [arch=amd64] https://repo.jellyfin.org/debian buster unstable. Debido al funcionamiento del versionado, una vez que habilites esta fuente adicional, siempre obtendrás los paquetes unstable con sus números de versión "muy altos" sobre las versiones estables, así que para desactivar las compilaciones inestables debes eliminar esta línea adicional, ejecutar apt update, eliminar el/los paquete(s) antiguos y luego instalar la versión estable.
Para todas las demás versiones, dado que la fuente siempre fueron archivos descargados de nuestro sitio de repositorio, no cambiará mucho: en lugar de descargar archivos de la carpeta nightly/ de tu plataforma, descarga de la carpeta unstable/. Ten en cuenta que estas carpetas contendrán, debido a las compilaciones divididas, subcarpetas separadas para server, web y combined; generalmente querrás combined. Luego puedes usar estos archivos como siempre lo has hecho.
Conclusiones
Gracias por leer esta descripción de nuestros cambios de compilación. Continuamos probándolos exhaustivamente para solucionar cualquier error, pero si tienes preguntas o comentarios, ¡déjanos un mensaje en Matrix!
¡Esperamos verte muy pronto para la versión 10.6.0 y muchas futuras versiones con este nuevo formato!