Verpakkingsupdates voor 10.6.0
Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →
Het verpakken en bouwen van binaire bestanden voor releases en tests is al lang een uitdaging voor ons. Van het worstelen met lapmiddel-en-kleerhangerscripts, tot het testen van brekende wijzigingen, tot het finetunen van officiële releases - onze werkwijze van de afgelopen anderhalf jaar vroeg om verbetering.
Gelukkig zijn deze vandaag allemaal voltooid. In dit artikel bespreek ik de wijzigingen en wat deze betekenen voor onze gebruikers.
Kort samengevat: voor de meeste gebruikers van onze stabiele releases verandert er weinig, en kun je naar 10.6.0 upgraden zoals je gewend bent. Voor testers met nightlies, geavanceerde setups of gewoon nieuwsgierigen: lees verder!
Gesplitste Builds
Het eerste belangrijke onderdeel van de verpakkingswijzigingen zijn gesplitste builds. Voorheen vertrouwden we op flinke hacks om zowel de Web UI (https://github.com/jellyfin/jellyfin-web) als de Server (https://github.com/jellyfin/jellyfin) te bouwen en in één pakket te combineren. Door het enorme aantal wijzigingen in beide repositories, het hoge updatetempo en ons uiteindelijke doel om beide componenten voor releases te ontkoppelen, was deze aanpak niet langer houdbaar. Dit blijkt wel uit het grotendeels onzichtbare werk dat nodig was om 10.5.4 en 10.5.5 überhaupt te kunnen bouwen.
Met gesplitste pakketten worden de repositories nu volledig onafhankelijk gebouwd voor alle platformen. Bouw je de jellyfin-web repository, dan krijg je een Docker image, .deb-pakketten, .rpm-pakketten of een .tar.gz-archief met alleen de Web UI. Evenzo levert het bouwen van de jellyfin repository de bekende Docker, .deb, .rpm, .tar.gz en .zip-archieven op.
Het belangrijkste verschil is de naamgeving - de binaire bestanden van jellyfin-web heten nu jellyfin-web, en die van jellyfin heten jellyfin-server. Neem Debian als voorbeeld: waar eerst jellyfin was, zijn er nu jellyfin-web en jellyfin-server. Maar geen zorgen, jellyfin is niet verdwenen - daar komen we zo op terug.
Azure Pipelines-builds
Onze vorige build-infrastructuur bestond uit een ware spaghetti-fabriek van Bash-, Python- en Docker-scripts die werden uitgevoerd op onze buildserver, een DigitalOcean droplet. Het werkte meestal, maar het proces was erg fragiel, ondoorzichtig (ik weet zelf niet eens zeker of ik altijd begreep hoe het allemaal werkte, en ik heb het allemaal geschreven!) en resource-intensief.
Toen we steeds meer functies naar Azure verhuisden voor testen, verificatie, linten etc., werd duidelijk dat Azure Pipelines veel flexibiliteit bood en bijna al onze buildstappen kon uitvoeren. Dit elimineerde minstens 2/3 van de buildserver en biedt een extra optie: unstable builds, waar ik zo op terugkom.
De Azure Pipelines-build regelt het daadwerkelijke bouwen van alle archieven voor beide repositories, uploadt de binaire artefacten naar de buildserver en start vervolgens een enkel script voor de laatste 1/3 van het proces. Dit maakt alles veel transparanter, duidelijker en zichtbaar voor iedereen op onze Azure-projectpagina.
Metapakketten en Meta-images
Ik heb eerder vermeld dat het pakket dat voorheen jellyfin heette nu jellyfin-server wordt genoemd en niet de Web UI bevat. Dus hoe krijg je alles? En hoe zullen upgrades naadloos verlopen? Het antwoord is metapakketten, meta-archieven en meta-images! Deze nieuwe componenten vind je op deze repository-pagina, specifiek de Docker-images die vanaf nu de bron van waarheid zijn voor deze configuraties. Hieronder leg ik uit hoe elk platform werkt.
Voor Docker creëren de gesplitste builds in Azure Pipelines docker-images genaamd jellyfin/jellyfin-server en jellyfin/jellyfin-web. Op zichzelf zijn ze niet erg nuttig, maar ze bestaan om de volgende stap mogelijk te maken. Wanneer een Azure-build klaar is en deze images heeft geüpload, start een script op onze build-server dat de jellyfin/jellyfin "metaimage" bouwt. Deze combineert de twee afzonderlijke images tot één Docker-image samen met alle benodigde componenten zoals jellyfin-ffmpeg, en pusht het resultaat. Het eindresultaat is een enkele image, jellyfin/jellyfin, zoals er altijd is geweest, maar nu worden de builds onafhankelijk uitgevoerd in plaats van te vertrouwen op git clone/archiefdownloads in de build-stappen en andere trucjes.
Voor Debian en Ubuntu creëren de gesplitste Azure Pipelines-builds aparte .deb-pakketten voor elke component. In tegenstelling tot Docker zijn deze zelfstandig bruikbaar, en je kunt Jellyfin 10.6.0+ installeren met apt install jellyfin-server jellyfin-web als je dat wilt. Het metapakket is een apart .deb-bestand genaamd jellyfin, wiens enige functie is afhankelijkheden te hebben naar deze twee componentpakketten. Dus het installeren van jellyfin installeert automatisch jellyfin-server en jellyfin-web, samen met andere vereiste afhankelijkheden. Zo verlopen upgrades naadloos vanaf vorige versies: upgraden van het oude jellyfin naar het nieuwe jellyfin haalt automatisch de twee nieuwe subpakketten binnen en verwijdert het oude, zonder onderbrekingen.
Voor Fedora en CentOS is de opzet vergelijkbaar met Debian/Ubuntu, met als enige verschil dat het metapakket een onderdeel is van de jellyfin-server-repository en dus alleen wordt herbouwd wanneer die repository verandert. Omdat we echter geen "echte" repository bieden voor deze pakketten zoals bij Debian/Ubuntu, is de impact vrij klein en zal deze bij stabiele releases niet merkbaar zijn.
Voor Windows-installatieprogramma's en MacOS .app-pakketten blijft het proces wat complexer en een werk in uitvoering (WIP), maar deze blijven werken bij release.
Voor de overige platformen, inclusief archiefpakketten voor Windows, MacOS, Linux en .NET portable, neemt het proces de twee aparte .tar.gz- / .zip-archieven uit het bouwproces en combineert ze tot één jellyfin-archief van hetzelfde type. Hierbij komen de twee componenten op hun respectievelijke plaatsen. Net als bij alle andere hierboven genoemde methoden zou deze wijziging onzichtbaar moeten zijn voor gebruikers door de "gecombineerde" versie van de archieven te downloaden.
Onstabiele builds
Een van de coole dingen die deze nieuwe opzet mogelijk maakt zijn "onstabiele" builds. Al geruime tijd bieden we (wanneer niet kapot) "nightly" builds aan, die zoals de naam al zegt elke nacht worden gebouwd als er PR's waren samengevoegd. Deze hadden echter verschillende nadelen. Ten eerste braken ze vaak; ten tweede kon op een drukke dag een dozijn aparte PR's het nightly-changeset vormen; ten derds konden ze vaak volledig verstoord zijn qua inhoud, bijvoorbeeld als de ongesplitste build de verkeerde Web-versie pakte.
De nieuwe gesplitste builds, Azure-builds en metapakketten/meta-images stellen ons in plaats daarvan in staat iets veel beters te doen: 'unstable'-releases bouwen voor elke samengevoegde PR. We hoeven ons geen zorgen te maken over resourcegebruik (Azure regelt dit), schijfruimte of andere aspecten van het bouwproces. We kunnen direct zien of er iets breekt. En het belangrijkste: iedereen kan onze master branch op een zeer duidelijke manier testen, waarbij je precies weet welke versie van de repository je gebruikt en wat de laatst samengevoegde PR was als er iets misgaat.
Onstabiele builds krijgen een versienummer op basis van de Azure-build-ID, in het formaat "[datum].[id]", bijvoorbeeld "20200620.12" voor de 12e build op 20 juni 2020. Deze versieaanduiding geeft precies aan welke Azure-build de binaire bestanden heeft gegenereerd, en dus welke pull-request in welke repository dit heeft getriggerd. Voor binaire bestanden met changelogs (momenteel alleen .deb- en .rpm-pakketten) bevat de changelog ook expliciet de pull-request-ID.
Onstabiele builds gebruiken
Het gebruik van onstabiele builds wijkt iets af van de vorige nightly-builds. Voorheen hadden pakketten/images namen als jellyfin-nightly of jellyfin:nightly (voor Docker) en stonden ze in dezelfde repositories. Dit is nu enigszins veranderd. Hieronder beschrijf ik de wijzigingen per platform. Let op: tot de release van 10.6.0 blijven we nightly-images bouwen zoals voorheen, daarna worden deze uitgeschakeld ten gunste van uitsluitend unstable-builds. Als je graag de allernieuwste versies gebruikt, lees dit deel dan aandachtig door en pas de benodigde wijzigingen zo snel mogelijk toe.
Voor Docker zijn de nieuwe onstabiele builds beschikbaar met de unstable-tag, bijvoorbeeld jellyfin/jellyfin:unstable, of met een specifieke versietag zoals jellyfin/jellyfin:20200620.12-unstable. Door de hoofd-unstable-tag te volgen, haal je altijd de nieuwste onstabiele build op, terwijl versiespecifieke tags je in staat stellen specifieke builds te testen of te debuggen.
Voor Debian en Ubuntu is de opslaglocatie van onstabiele images gewijzigd. Voorheen maakten ze deel uit van het main-gedeelte van de repository onder de alternatieve naam jellyfin-nightly, maar dit is voor onstabiele builds niet langer het geval. In plaats daarvan is er een aparte repository-"component" genaamd unstable aangemaakt. Om deze extra component in te schakelen, voeg je een regel toe aan je /etc/apt/sources.list.d/jellyfin.list die identiek is aan de bestaande regel, maar met main vervangen door unstable: deb [arch=amd64] https://repo.jellyfin.org/debian buster unstable. Door de versienummering krijg je na het toevoegen van deze bron altijd de unstable-pakketten met hun "zeer hoge" versienummers in plaats van de stabiele releases. Om onstabiele builds uit te schakelen, moet je deze extra regel verwijderen, apt update uitvoeren, de oude pakketten verwijderen en vervolgens de stabiele versie installeren.
Voor alle andere releases verandert er weinig, aangezien de bron altijd bestanden waren die werden gedownload van onze repository-site. Download in plaats van de nightly/-map nu uit de unstable/-map. Let op: door de gesplitste builds bevatten deze mappen nu aparte submappen voor server, web en combined; meestal wil je combined. Deze archieven kun je vervolgens gebruiken zoals je gewend bent.
Conclusies
Bedankt voor het lezen van deze uitleg over onze buildwijzigingen. We blijven deze uitgebreid testen om eventuele bugs op te sporen, maar als je vragen of feedback hebt, stuur ons dan een bericht op Matrix!
We hopen je zeer binnenkort te zien voor versie 10.6.0 en vele toekomstige releases met dit nieuwe formaat!