Nieuwe CI, nieuwe repo, een hernieuwde push voor 10.9.0

Onofficiële Beta-vertaling

Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →

De afgelopen weken heb ik hard gewerkt aan een grote opknapbeurt van onze CI, om onze releaseworkflow te verbeteren, de releasesnelheid te verhogen en de druk op mij als releasebeheerder te verminderen. Deze post beschrijft de doorgevoerde wijzigingen, hoe deze jullie als gebruiker of bijdrager kunnen beïnvloeden, en hoe we het 10.9.0-releaseproces aanpakken.

De samenvatting

1. We hebben een nieuwe repository browser UI met een nieuwe bestandsstructuur, draaiend op nieuwe masterrepository-hardware, gebouwd door nieuwe CI. Dit moet het makkelijker maken om te navigeren en snel te vinden wat je nodig hebt. Dit is nu in productie genomen maar is nog steeds werk in uitvoering, dus meld eventuele bugs aan ons! Let op: veel mappaden zijn gewijzigd (vooral alles onder /server), maar sommige blijven gelijk. Krijg je een 404 en vind je het niet via de browser? Neem dan contact op. Externe pakketbouwers die handmatig bestanden bij ons downloaden, worden geadviseerd contact op te nemen indien nodig.

2. We stoppen met niet-LTS Ubuntu-pakketten en onze eigen Fedora/CentOS-pakketten. In plaats daarvan gebruiken we voortaan RPMFusion builds. Daarnaast voegen we GHCR als containerrepository toe voor onze Docker-images.

3. Voor 10.9.0 maken we geen expliciete "beta"-releases. In plaats daarvan testen we met onze nieuwe wekelijkse Unstable builds. Zodra de master-branch stabiel genoeg is, releasen we 10.9.0 rechtstreeks vanaf daar (via ons standaard releasebranch-proces).

4. De feature freeze voor 10.9.0 (alleen nog bugfix-PR's na dit punt) begint voorlopig op maandag 18 maart. We hopen dat bovenstaande wijzigingen dan gereed zijn, zodat het verkrijgen van Unstable builds voor testen eenvoudig is.

5. De 10.9.0-release zelf is voorlopig gepland voor het laatste weekend van april. Aan alle externe partijen die pakketten van onze releases bouwen: lees vooral door tot het einde voor een belangrijke opmerking over deze release.

Lees verder voor meer details.

- Joshua

Waarom een nieuwe CI bouwen?

Onze oude CI werd in 2019 in elkaar gezet door enkele toegewijde teamleden (vooral @EraYan) met Azure DevOps. Hoewel dit een enorme verbetering was ten opzichte van mijn zelfgebouwde pure-BASH-systeem uit het eerste jaar, had het nog steeds nadelen:

1. Het was wat moeilijk te begrijpen en leunde op een extern systeem (Microsoft Azure).

2. Het was nog steeds afhankelijk van een complex, ingewikkeld en foutgevoelig BASH-script om builds af te ronden, omdat...

3. Het de Server- en Web-onderdelen van Jellyfin apart bouwde, apart getriggerd door verschillende repository-taggebeurtenissen, waarna allerlei kunstgrepen nodig waren om de resultaten te combineren tot gebruiksvriendelijke pakketten.

Los van de CI zelf speelde ook het probleem van Unstable builds. Deze werden lange tijd na elke gemergde PR gebouwd - handig om snel te testen of dingen werkten, maar feitelijk onbruikbaar voor gewone gebruikers omdat ze zo vaak veranderden. Ook dit wilden we aanpakken.

Destijds bestond GitHub Actions nog niet, en hoewel we alles werkend kregen, was de CI als geheel log en foutgevoelig. Grote releases kostten me vaak meer dan 20 manuren aan voorbereiding en uitvoering, terwijl puntreleases minstens 4-6 uur in beslag namen. Dit was een enorme belasting als release manager, en ook erg omslachtig om te fixen als dingen op obscure manieren braken, vooral na de tag, omdat alle CI in de coderepos zat.

Dit alles betekende dat onze releasesnelheid extreem traag was, omdat er nooit een duidelijke flow was tussen het testen van de master en de voorbereidingen voor de volgende release.

In plaats van deze opzet incrementeel aan te passen, startten @ferferga en @h1dden-da3m0n (die inmiddels verder is gegaan) ongeveer 2 jaar geleden een project om naar GitHub Actions te migreren. Hoewel ze veel voorbereidend werk deden, liep dat project uiteindelijk vast en werd het effectief stopgezet. Eerder dit jaar nam ik de taak op me om dit alsnog te voltooien voor 10.9.0, en lukte het me om het goed werkend te krijgen op een veel begrijpelijker en hopelijk consistentere manier.

Meer automatisering

Naast de CI zelf is een automatiseringbot de volgende stap. Zoals gezegd kostten releases veel tijd, maar slechts een fractie daarvan ging naar Azure. De rest was administratief werk: changelogs bouwen, repos synchroniseren, bump-version-scripts draaien, releasedrafts maken, ze 3x controleren en toch iets missen, een releasepost schrijven voor ons Forum, etc. Dit alles resulteerde in een aanzienlijke tijdsinvestering waar ik zelden zin in had, wat onze snelheid niet ten goede kwam.

Geen enkel project zou zo afhankelijk moeten zijn van één persoon, maar dat waren we lange tijd wel. Een doel van deze CI-verbetering is om ook deze aspecten te stroomlijnen met een extra stuk automatisering: een privé-chatbot.

Het doel is dat we onze chatbot vertellen dat we klaar zijn voor een release, waarna deze automatisch alle teksten voorbereidt, en we na controle kunnen aangeven dat het klaar is voor verzending. Dit vereenvoudigt niet alleen het proces voor mij, maar kan ook door anderen uitgevoerd worden. En met betrouwbaardere CI hopen we op een "instellen en vergeten"-releaseproces dat onze snelheid aanzienlijk verhoogt.

Hoewel de bot nog niet helemaal af is, staat de basisstructuur er, en we verwachten zeker dat hij op tijd klaar is voor de daadwerkelijke 10.9.0-release.

Pakketten unificeren

Een groot nadeel van de vorige CI was de aparte behandeling van Jellyfins server- en webcomponenten. Dit kwam omdat deze componenten inderdaad gescheiden zijn: verschillende GitHub-repos met verschillende eigenaren. Maar gebruikers consumeren Jellyfin niet zo - ze willen één pakket, installer of archief om direct te gebruiken. Daarom moesten we veel complexe trucs uithalen om pakketten te combineren.

Niet meer. Met de geüpdatete CI is al onze packaging samengevoegd en ondergebracht in zijn eigen toegewijde repository. Deze repo verwerkt de twee coderepos via submodules en een simpel Python-script om versies te synchroniseren voor een build. Een ander Python-script handelt het bouwen af, aangeroepen vanuit GitHub Actions. Het blijft wat complex, maar dat is onvermijdelijk bij onze verpakkingscomplexiteit. We hopen dat Python - een robuuste maar toegankelijke taal - dit proces transparanter maakt dan voorheen.

Dit betekent verschillende dingen afhankelijk van het verpakkingsformaat. Voor Debian en Ubuntu betekent dit dat er nu één Debian-bronpakket is voor de drie resulterende binaire pakketten (metapakket, web en server) en dat alle drie tegelijk gebouwd kunnen worden met één dpkg-buildpackage-commando. Voor archieven betekent dit dat zowel server- als webcomponenten sequentieel gebouwd worden en tijdens de build gecombineerd worden tot één archief, in plaats van lukraak achteraf - een proces dat vaker faalde dan we konden tellen. Voor installatieprogramma's betekent dit dat het proces nu eenvoudiger is en geautomatiseerd kan worden. En voor Docker betekent dit dat we nu één enkele image jellyfin/jellyfin aanbieden die in één keer gebouwd is en niet afhankelijk is van twee tussentijdse images, een ander foutgevoelig proces.

Hieraan gerelateerd, en als onderdeel van de geünificeerde builds, heeft elke Debian- en Ubuntu-versie nu een eigen specifiek pakket met versieachtervoegsels zoals -deb12 of -ubu2204. Dit zorgt voor een soepelere afhandeling van afhankelijkheden voor gedeelde bibliotheken zoals LibSSL. Dit is vooral relevant als je .deb-pakketten rechtstreeks uit de repository downloadt: zorg dat je de juiste versie voor jouw release kiest.

Als eindgebruiker merk je hier niets van: je installeert de pakketten nog steeds op dezelfde manier via onze repositories. Maar voor iedereen die eigen builds maakt, raden we nu aan om bovenstaande repository te gebruiken. Alle niet-ontwikkelingsverpakkingen (zoals de debian/ en fedora/ mappen, de deployment/ map, etc.) worden namelijk verwijderd uit de hoofdrepositories. Alleen een eenvoudige Dockerfile blijft over voor snelle test- en ontwikkelingsimages.

Een nieuwe repository-master voor een nieuw CI-systeem

De volledig nieuwe CI en geünificeerde pakketten maken een veel schonere repositorystructuur mogelijk. Onze vorige structuur was gebaseerd op combinatievereisten, vol eigenaardigheden en geneste mappen om dat eenvoudiger te maken. Nu we die niet meer nodig hebben, konden we een veel logischere indeling kiezen en dus ook een gloednieuwe masterserver voor een soepele overgang.

Dit omvat ook een vernieuwde browserpagina om eenvoudig bij de gewenste bestanden te komen, met een gebruiksvriendelijkere navigatie door de nieuwe mappenstructuur.

De nieuwe browser en repository-master zijn sinds publicatie live op https://repo.jellyfin.org. Terwijl we toewerken naar de 10.9.0-release blijven ook de stabiele pakketten in de nieuwe structuur beschikbaar. Dus zoals in de inleiding aangegeven: test het vooral uit en laat ons weten als je problemen, gebroken links of andere issues tegenkomt.

Onstabiele releases

Zoals eerder genoemd was onze oude aanpak van "alles bouwen bij elke pull request" erg onhandig omdat functionaliteit snel veranderde en testers bijhouden bijna onmogelijk was tijdens drukke periodes. In het verleden hadden we dagelijkse builds geprobeerd, maar zelfs die voelden te snel voor ons huidige ontwikkeltempo én voor gebruikers om bij te blijven.

Daarom schakelen we nu over op wekelijkse onstabiele releases. De builds gebeuren maandagochtend rond middernacht Eastern tijd (UTC-5/4-met-zomertijd), een willekeurig gekozen tijdstip dat wel garandeert dat elke week met een frisse build begint. Dit proces is volledig geautomatiseerd en de resulterende builds verschijnen kort daarna op alle gebruikelijke plekken.

We hopen dat dit rustigere tempo gebruikers van onze onstabiele builds meer ruimte geeft om de huidige staat van Jellyfin echt te testen zonder overweldigd te raken door de releasesnelheid, terwijl het toch snel genoeg beweegt om de nieuwste functies en fixes te kunnen proberen.

Tot slot, zoals hieronder verder uitgelegd, zullen deze wekelijkse onstabiele builds dienen als onze pre-release-testing voor 10.9.0: er komen geen aparte "beta"- of "rc"-releases deze cyclus. Dit voorkomt de enorme belasting die we bij 10.8.0 ervoeren met het constant backporten van fixes voor de aankomende release naar master, terwijl we ook fixes in de tegenovergestelde richting moesten doorvoeren wanneer ze per ongeluk verkeerd getarget waren.

Opruimen wat we bouwen

Zoals genoemd in de TL;DR, maken we drie grote veranderingen in wat we bouwen, zowel voor de Unstable-releases als de komende 10.9.0-release:

1. We stoppen met alle niet-LTS Ubuntu-releases in onze officiële APT-pakketrepository.

   De reden is simpel: het is een enorme belasting om Ubuntu's 6-maandelijkse releaseschema bij te houden, alleen om ondersteuning te bieden voor wat in de praktijk kleine versies zijn met een levensduur van 9 maanden. Hoewel we begrijpen dat mensen Jellyfin mogelijk op desktops willen draaien of ervoor willen zorgen dat hun servers "de nieuwste" software hebben, is dit op de lange termijn niet houdbaar voor ons. Dus, vanaf nu richten onze pakketten zich alleen op de LTS-releases, te beginnen met 20.04 "Focal", en inclusief 22.04 "Jammy" en de nieuwe 24.04 "Noble" die in april uitkomt.

   Als je een niet-LTS-versie van Ubuntu gebruikt, heb je nog steeds opties. Ten eerste kun je altijd upgraden naar 24.04 en die voortaan gebruiken. Maar let op: 24.04 zal de laatste release zijn waarvoor we bouwen totdat 26.04 uitkomt. Als alternatief, als je je systeem op het 6-maandelijkse updatepad wilt houden, kun je migreren naar onze Docker-images, en deze hebben het bijkomende voordeel van extra stabiliteit op de lange termijn, zelfs als je basisbesturingssysteem verandert.

2. We stoppen met onze eigen "officiële" RPM-builds voor Fedora en CentOS(-achtige) distributies ten gunste van RPMFusion:

   Deze builds waren altijd een beetje een stiefkind voor ons. Ze werden slecht onderhouden (ondanks enkele moedige inspanningen en bijdragen van de gemeenschap), braken vaak, en dit kwam allemaal tot een hoogtepunt toen we begonnen met een gecombineerde specificatie.

   Gelukkig heeft een gemeenschapslid (@mooninite) al een stabiele gecombineerde RPMFusion-build van Jellyfin onderhouden. Dit leek het perfecte moment om daarnaar over te stappen, wat een ander deel van de pakketbeheerlast van ons wegneemt, en (eindelijk) een "echte" repository biedt voor onze RPM-gebruikers. De RPMFusion-build is nu de officiële Fedora/CentOS-build die op onze downloadpagina staat en zal dat ook in de toekomst zijn. We nemen ook stappen om een verpakte FFmpeg-build daar te krijgen, dus houd het in de gaten.

   Unstable-gebruikers op Fedora/CentOS wordt aangeraden om in plaats daarvan bij de Docker-container te blijven, omdat deze zowel vandaag FFmpeg bundelt als zorgt voor snelle upgrades.

3. We voegen eindelijk GHCR (ghcr.io)-ondersteuning toe voor onze Docker-images. Dit helpt ervoor te zorgen dat, zelfs als er iets met Docker Hub gebeurt, er een andere bron is voor onze Docker-images. Als je wilt, kun je deze bron direct gebruiken voor Unstable-builds, en voor 10.9.0 wanneer deze wordt uitgebracht.

De 10.9.0-releasecyclus

Zoals we in deze GitHub-discussie hebben geschetst, betekenen al deze veranderingen dat er grote veranderingen komen in hoe we de 10.9.0-releasecyclus aanpakken. Om dingen te verduidelijken, zal het exacte proces als volgt zijn:

1. Vanaf nu, en voor onbepaalde tijd voor alle toekomstige releases, zullen de wekelijkse Unstable-builds fungeren als de "beta"-versies. Dat wil zeggen, als je ons wilt helpen testen of gewoon op de hoogte wilt blijven van de nieuwste en beste functies, gebruik dan de Unstable-releases. De instructies op onze downloadpagina zijn nog steeds van toepassing voor het inschakelen van Unstable-builds, en ook voor het overzicht van al onze ondersteunde Unstable-platformen.

2. Naarmate we de geplande releasedatum naderen, beginnen we met een feature freeze. Tijdens de feature freeze worden alleen bugfix-PR's geaccepteerd. We verwachten dat dit 3 tot 5 weken duurt. Momenteel is de voorlopige start maandag 18 maart. Tijdens de freeze moeten de Unstable-builds consistent en werkend zijn, waarbij alleen kleine fixes worden samengevoegd.

3. Als gebruikers, wees alsjeblieft ijverig in het melden van bugs in de Unstable-releases. Ons Triage-team is de afgelopen maanden zeer ijverig geweest in het zorgen dat problemen worden gesorteerd en bekeken, dus het is van vitaal belang dat iedereen die de Unstable-releases gebruikt, hun bugs goed meldt!

4. Naarmate we stabiliteit naderen, dus na de 3-5 weken van bevroren bugfixes, zullen we de definitieve release uitbrengen. Ik hoop persoonlijk dit te realiseren in het weekend van 27-28 april, maar dit kan wijzigen afhankelijk van het verloop tijdens de stabilisatiefase.

5. De release zal daadwerkelijk plaatsvinden. We zullen een nieuwe release-branch aanmaken, de versie taggen en - met behulp van de nieuwe CI - de release uitvoeren. We vragen expliciet aan derde partijen die mogelijk reageren op Tag-events in onze repositories om dit voor deze release uit te schakelen, omdat we verwachten minstens één à twee obstakels tegen te komen tijdens dit "echte" proces. Zodra de rook is opgetrokken, zorgen we dat jullie releases gebouwd worden, voor het geval we drastische maatregelen moeten nemen zoals hertagging. Op langere termijn ontwikkelen we een betere afstemmingsprocedure, dus we willen graag samenwerken met onderhouders van derde partijen - neem contact met ons op.

6. Op dat moment hervat de master-branch normale activiteiten en starten we de stabiele bugfixcyclus voor 10.9.0. Met de verbeteringen hopen we dat 10.10.0 daarna niet ver weg zal zijn, mogelijk binnen 3-6 maanden, waarna dit proces opnieuw begint.

We zijn er bijna, na ruim twee jaar ontwikkeling, dus we willen deze plannen zo breed mogelijk verspreiden - vooral om meer mensen te motiveren de nieuwe Onstabiele builds te testen ter voorbereiding op de definitieve release!

Tot slot

Dit samenvat mijn huidige visie, zowel over het traject naar 10.9.0 als de verbeteringen in ons releaseproces. Fijn kijken!