Problemen in FVM oplossen met open source gedachtegoed!

FVM 3.0.0 is deze maand uitgekomen, en voor dat ik het zelf heb uitgeprobeerd kreeg ik al wat waarschuwingen op Twitter, Slack en Discord van mensen die problemen hebben met hun FVM installaties. Ik was hier voorzichtig mee en besloot om FVM 2 te blijven gebruiken tot de meeste problemen waren opgelost. Dit is normaliter een slimme aanpak.

Maar, onze geniale infrastructuur tovenaar Tom had met onze toestemming onze CI machine geupdate. Zonder er bij stil te staan was hiermee FVM geupdate van versie 2 naar versie 3! En toen was het raak: 'the morning after' kleurde al onze Flutter pipelines dieprood! ❌

De gemakkelijke oplossing zou zijn om te doen of m'n neus bloedt en de FVM versie terug te draaien naar versie 2, maar dat klonk niet als de beste oplossing op de lange termijn. Uiteindelijk willen we toch naar FVM 3 upgraden, dus het lijkt beter om de issues te fixen in plaats van terug te gaan naar een oude versie. Dus tijd om ons even goed uit te rekken en dan duiken we er regelrecht in!

Het probleem

Bij het draaien van FVM op onze build machine bleven we steken met het volgende probleem: No pubspec.yaml detected in this directory

Maar ik was vrij zeker dat we FVM draaiden in een folder waarin we een pubspec.yaml file hadden! Na dit niet dubbel maar driedubbel gecontroleerd te hebben op onze build machine (we bouwen onze apps op een dedicated server ergens in een datacenter) ben ik online naar dit probleem gaan zoeken. Ik vond een open ticket wat leek op het probleem wat ik tegen kwam;

https://github.com/leoafarias/fvm/issues/638

De beschrijving van dit probleem was enigszins onduidelijk, maar het leek overeen te komen met wat wij ervaren. Toen ik dit probleem aan het onderzoeken was, was dit nog een open ticket. Ik schreef een comment op het ticket met dat ik het probleem ook ondervond en bood aan om te helpen bij het reproduceren van het probleem. Maar op dat moment schoot het jaardoel van Dutch Coding Company in mijn hoofd: het bijdragen aan open source! Dit was mijn kans om te helpen met een open source project.

Ik trok FVM lokaal binnen op mijn machine en begon met rond zoeken. Ik kwam er achter dat het te maken had met een functie die was uitgecomment in FVM3. Deze functie in de findAncestor functie vind waar de huidige FVM installatie precies staat. Door deze regel terug aan te zetten werkte FVM weer voor mij. Ik bood een pull request aan om dit probleem op te lossen, maar Leo, de ontwikkelaar van FVM, gaf aan dat dit een probleem zou opleveren bij het ondersteunen van mono repositories.

Na wat heen en weer gechat tussen Leo en mij (je kan de berichten lezen onder het issue wat ik eerder linkte), vonden we uit dat het probleem ontstond door een FVM configuratie die hoger in de folderstructuur was gedefinieerd. Door deze configuratie te verwijderen werkte de pipeline weer! Leo heeft op basis van mijn informatie nog wat extra fixes gemaakt en de uitgecommentte regels nu echt verwijderd. Fantastisch! 🎉

En daarmee dacht ik dat al mijn problemen waren opgelost en ik weer op weg kon gaan met het bouwen van mijn apps. Tot de derde stap van onze pipeline stuk ging, en me dit slack bericht liet typen uit pure waanzin;

AAAAAAAH! Flutter SDK 3.19.0_x86_64 is not valid Flutter version! Weer terug bij af...

Het Probleem 2: Electric Boogaloo

Laat me je eerst wat uitleggen over deze specifieke versie van Flutter. In onze Flutter projecten gebruiken we Golden Tests. Dit zijn testen waarin gedeeltes van de app worden getekend in een test engine en vergeleken worden met schermafbeeldingen van die rendering. Dit zorgt ervoor dat elke widget er altijd hetzelfde en precies zoals bedoeld uitziet, en we kunnen ze controleren tegen de verificatie afbeeldingen. Als een widget verandert kunnen we deze verificatie afbeeldingen gemakkelijk bijwerken. Echter, door een heel klein verschil in het renderen van Flutter op andere processor architecturen bleven we problemen hebben met een heel klein verschil in afbeeldingen.

Dit is waarom we een script hebben geschreven die een x86_64 versie installeert van Flutter tijdens het test proces en deze wordt gebruikt door de build machine, zelfs als het een Apple Silicon machine is. Op deze manier wordt er ongeacht de processor architectuur op elke machine dezelfde versie van Flutter gebruikt. Dit werkte fantastisch voor ons!...

... Tot FVM 3!

FVM 3.0.0 heeft een boel quality of life verbetering; inclusief deze. Als je een specifieke versie van Flutter selecteert, controleert FVM of de meegegeven Flutter versie 'klopt'. Onze gekke Flutter versie naam was natuurlijk geen kloppende Flutter versie; het is een custom naam. En het woord 'custom' is het sleutelwoord hier. Ik vond uit dat als je custom_ aan de voorkant van de Flutter naam toevoegt, FVM het beschouwt als een custom versie van Flutter! Dit klinkt fantastisch, het leek mij logisch dat FVM niet op de versie naam zou controleren van een custom versie van Flutter. Fout! ❌. FVM bleef controleren op versienaam. En wat als we de --force parameter toevoegen om het door de vragen heen te forceren? Dan zou er geen vraag gesteld worden over de Flutter versie, toch? Toch?

Nou je kan het vast wel raden, dit was niet de oplossing voor ons probleem.

Ik vond persoonlijk dat het wél zo zou moeten werken. Dus ik opende een nieuwe tichet op Github, maakte een fork van FVM en begon aan een oplossing. Na een aantal uur proberen vond ik een goede oplossing en bood ik een pull requets aan om het probleem op te lossen 🙂!

En hiermee begon het wachten. Leo is snel in het reageren op Github, maar we werken in compleet verschillende tijdzones. Dus Leo sliep nog! Ondertussen had ik mijn oplossing op onze build machine geïnstalleerd om uit te proberen, en al onze pipelines leken hiermee weer te werken!

Na het oplossen van wat goede feedback heeft Leo mijn pull request goedgekeurd en een paar dagen later was mijn oplossing beschikbaar voor de rest van de wereld. :)

Ik vond het erg gaaf om aan tools te werken waarvan ik denk dat ze essentieel zijn voor het ontwikkelen in Flutter. Ik gebruik FVM letterlijk elke dag en het maakt het dragelijk om aan verschillende projecten met verschillende versies te werken.

Bonus Probleem - handige meldingen

Voor we afronden heb ik nog een laatste probleem dat ik tegen kwam terwijl ik deze blogpost aan het schrijven was. Ik was een project aan het uitrollen wat al een tijdje klaar stond om gemerged te worden; alle pipelines waren al lang en breed uitgevoerd en stonden op groen. Maar in de tussentijd is FVM geüpdatet, maar dat hadden we opgelost toch? Toch?

Zoals je hierboven ziet, vergeet .fvm niet toe te voegen aan je .gitignore file :').

Bedankt! Je hebt het gehaald tot de afsluiting van mijn blog! Als je nog vragen hebt over mijn bijdrage aan FVM of over wat dan ook, voel je vrij om me een berichtje te sturen op X (@Bassiuz), en als je het leuk vind om te lezen over mijn avonturen binnen Flutter dan zou je kunnen overwegen om mij te volgen! Tot de volgende keer! 👋🏼