Ändringarna som gjordes på Github var inte som förväntat
Det har nyligen rapporterats att GitHub har ändrat metoden för att generera filer Autogenererade ".tar.gz" och ".tgz" på startsidor.
Denna förändring orsakade ändringar i kontrollsummor och massiva krascher i byggsystem automatiserad, som verifierar integriteten hos filer som laddats ner från GitHub mot tidigare lagrade kontrollsummor, såsom de som placerats i paketmetadata eller byggskript.
Från och med version 2.38 av Git, ingår som standard integrerad implementering av gzip, Detta gjorde det möjligt att förena stödet för denna komprimeringsmetod över alla operativsystem och förbättra prestanda för filskapande. GitHub tog upp förändringen efter att ha uppgraderat git-versionen på deras infrastruktur.
Standardkomprimeringen för Git-filer har nyligen ändrats. Som ett resultat kan filer som laddas ner från GitHub ha olika kontrollsummor även om innehållet inte har förändrats helt.
GitHub garanterar inte stabiliteten hos kontrollsummor för automatiskt genererade filer. Dessa är markerade med orden "Källkod (zip)" och "Källkod (tar.gz)" på fliken Versioner. Om du behöver förlita dig på en konsekvent kontrollsumma kan du ladda upp filer direkt till GitHub Releases.
Dessa kommer garanterat inte att förändras.
Problemet var än filer genererade surfplattor av gzip-implementeringen zlib build är olika binärer av filerna som genereras av gzip-verktyget, vilket resulterar i olika kontrollsummor för arkiv skapade av olika versioner av git när kommandot "git archive" körs.
Följaktligen, efter att ha uppdaterat git på GitHub, lite olika filer började dyka upp på releasesidorna som misslyckades med verifieringen med ovanstående kontrollsummor.
Problemet manifesterade sig i olika byggsystem, kontinuerliga integrationssystem och verktygssatser för att bygga paket från källkod. Till exempel var cirka 5800 portar av FreeBSD trasiga, vars källor laddades ner från GitHub.
Som svar till de första klagomålen om misslyckanden, GitHub-representanter noterade initialt att kontrollsummor aldrig garanterades konstanter för filer.
Efter att det visades att att bygga system som påverkas av förändringen skulle kräva en betydande mängd arbete för att uppdatera metadata över de olika ekosystemen, fick GitHub en förändring i hjärtat, återställde förändringen och återgick till den gamla filgenereringsmetoden. .
Som förväntat, folk började klaga. Det första svaret från GitHub-anställd (och främsta Git-bidragsgivare) brian m. Carlson var mindre än helt förstående:
Jag säger att policyn aldrig har varit korrekt och vi har aldrig garanterat stabila kontrollsummor för filer, precis som Git aldrig har garanterat det. Jag ber om ursäkt för att saker och ting inte fungerar här och det har inte varit tydligare kommunikation om detta tidigare, men vår policy har inte ändrats på över fyra år.
Git-utvecklare de har inte fattat något beslut än och diskuterar bara möjliga åtgärder. den Alternativ som övervägs inkluderar att använda gzip-verktyget standard; lägga till flaggan "–stable" för att bevara kompatibiliteten med äldre filer; länka den inbyggda implementeringen till ett separat filformat; använda gzip-verktyget för gamla commits och den inbyggda implementeringen för commits från ett visst datum; garanterar formatets stabilitet endast för okomprimerade filer.
Komplexiteten i beslutet förklaras av det faktum att återgång till det externa verktygsanropet inte helt löser kontrollsummanvariansproblemet, eftersom en ändring i det externa gzip-programmet också kan orsaka en ändring i filen.
För närvarande finns det en korrigeringsfil för granskning som återgår till standardbeteendet (anropar ett externt gzip-verktyg) och använder den inbyggda implementeringen när gzip-verktyget inte finns på systemet. Patcharna lägger också till en notering till dokumentationen att utdata från "git archive" inte garanteras vara stabil och att formatet kan komma att ändras i framtiden.
Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.