Změny provedené na Github nebyly podle očekávání
Nedávno se objevily zprávy, že GitHub změnil metodu generování souborů „.tar.gz“ a „.tgz“, které se automaticky generují na stránkách vydání.
Tato změna způsobila změny v kontrolních součtech a masivní selhání v automatizovaných systémech sestavení, které ověřují integritu souborů stažených z GitHubu oproti dříve uloženým kontrolním součtům, jako jsou ty umístěné v metadatech balíčků nebo skriptech sestavení.
Počínaje verzí 2.38 zahrnoval Git ve výchozím nastavení implementaci gzip, což sjednotilo kompatibilitu s touto metodou komprese napříč všemi operačními systémy a zlepšilo výkon při vytváření souborů. GitHub tuto změnu přijal po aktualizaci verze Gitu na své infrastruktuře.
Výchozí komprese souborů Git se nedávno změnila. V důsledku toho mohou mít soubory stažené z GitHubu různé kontrolní součty, i když se obsah úplně nezměnil.
GitHub nezaručuje stabilitu kontrolních součtů pro automaticky generované soubory. Ty jsou označeny slovy „Zdrojový kód (zip)“ a „Zdrojový kód (tar.gz)“ na kartě Verze. Pokud se potřebujete spolehnout na konzistentní kontrolní součet, můžete soubory nahrávat přímo do vydání GitHub.
Ty se zaručeně nezmění.
Problém byl v tom, že komprimované soubory generované vestavěnou implementací gzip v zlibu se liší od souborů generovaných utilitou gzip, což má za následek různé kontrolní součty pro soubory vytvořené různými verzemi gitu při spuštění příkazu „git archive“.
V důsledku toho se po aktualizaci gitu na GitHubu na stránkách s vydáním začaly objevovat mírně odlišné soubory , které neprošly ověřením s předchozími kontrolními součty.
Problém se projevil v různých sestavovacích systémech, systémech průběžné integrace a sadách nástrojů pro sestavování balíčků ze zdroje. Například bylo rozbito asi 5800 portů FreeBSD, jejichž zdroje byly staženy z GitHubu.
V reakci na počáteční stížnosti na selhání zástupci GitHubu zpočátku poukázali na to, že konzistentní kontrolní součty souborů nebyly nikdy zaručeny.
Poté, co se ukázalo, že vytváření systémů sestavení ovlivněných změnou bude vyžadovat značné množství práce na aktualizaci metadat napříč různými ekosystémy, GitHub změnil názor, vrátil změnu a vrátil se ke staré metodě generování souborů.
Jak se dalo očekávat, lidé si začali stěžovat . První reakce zaměstnance GitHubu (a hlavního přispěvatele Gitu) Briana M. Carlsona nebyla úplně soucitná:
Říkám, že politika nebyla nikdy správná a nikdy jsme nezaručili stabilní kontrolní součty pro soubory, stejně jako to Git nikdy nezaručil. Omlouvám se za to, že zde věci nefungují a v minulosti o tom nebyla srozumitelnější komunikace, ale naše zásady se za více než 4 roky nezměnily.
Vývojáři Gitu se zatím nerozhodli a pouze diskutují o možných postupech. Mezi zvažované možnosti patří návrat k výchozímu nástroji gzip; přidání příznaku `--stable` pro zachování kompatibility se staršími soubory; propojení vestavěné implementace se samostatným formátem souboru; použití gzip pro starší commity a vestavěné implementace pro commity od určitého data; a zajištění stability formátu pouze pro nekomprimované soubory.
Složitost rozhodnutí je vysvětlena skutečností, že návrat k externímu volání obslužného programu zcela nevyřeší problém invariance kontrolního součtu, protože změna v externím programu gzip může také způsobit změnu souboru.
V současné době existuje sada oprav ke kontrole, která se vrací k výchozímu chování (vyvolání externího nástroje gzip) a používá vestavěnou implementaci, když nástroj gzip není v systému přítomen. Záplaty také přidávají do dokumentace poznámku, že není zaručeno, že výstup "git archive" bude stabilní a že formát se v budoucnu může změnit.
A konečně, pokud se chcete o tomto tématu dozvědět více , podrobnosti naleznete na následujícím odkazu.