GitHub ŝanĝis la manieron kiel ĝi generas aŭtomate generitajn ".tar.gz" kaj ".tgz" arkivojn sur eldonpaĝoj, kio kaŭzis ŝanĝojn en iliaj ĉeksumoj kaj masivaj fiaskoj en aŭtomatigitaj konstrusistemoj kiuj kontrolas arkivojn elŝutitajn de GitHub kontraŭ antaŭaj por konfirmi integrecon. stokitaj ĉeksumoj, ekzemple, metitaj en pakajn metadatumojn aŭ en konstruskriptojn.
Komencante kun la eldono 2.38, la ilaro Git inkluzivis enkonstruitan efektivigon de gzip defaŭlte, kio ebligis unuigi subtenon por ĉi tiu kunprema metodo trans operaciumoj kaj plibonigi rendimenton de kreado de arkivoj. GitHub reprenis la ŝanĝon post ĝisdatigo de la versio de git en sia infrastrukturo. La problemo estis kaŭzita de la fakto, ke la kunpremitaj arkivoj generitaj de la enkonstruita zlib-bazita gzip-efektivigo estas binaraj malsamaj de la arkivoj kreitaj de la gzip-utilo, kio rezultigis malsamajn kontrolsumojn por arkivoj kreitaj de malsamaj versioj de git dum la ekzekuto de la komando "git archive".
Sekve, post ĝisdatigo de git en GitHub, iomete malsamaj arkivoj komencis montriĝi sur la eldonpaĝoj, kiuj ne pasigis konfirmon per la malnovaj kontrolsumoj. La problemo manifestiĝis en diversaj konstrusistemoj, kontinuaj integrigaj sistemoj kaj iloj por konstrui pakaĵojn el fontkodo. Ekzemple, la kunigo de ĉirkaŭ 5800 FreeBSD-havenoj, kies fontkodoj estis elŝutitaj de GitHub, estis rompita.
En respondo al komencaj plendoj pri la misfunkciadoj, GitHub komence citis la fakton, ke konstantaj kontrolsumoj por arkivoj neniam estis garantiitaj. Post kiam estis montrite, ke grandega laboro estos postulata por ĝisdatigi la metadatumojn en diversaj ekosistemoj por restarigi la funkciecon de la tuŝitaj konstrusistemoj, GitHub-reprezentantoj ŝanĝis opinion, revertis la ŝanĝon kaj resendis la malnovan metodon por generi arkivojn.
La programistoj de Git ankoraŭ ne decidis kaj nur diskutas eblajn agojn. Opcioj konsideritaj inkluzivis reveni al uzado de la defaŭlta gzip ilo; aldonante la flagon "--stable" por konservi kongruon kun malnovaj arkivoj; ligi la enkonstruitan efektivigon al aparta arkivformato; uzante la gzip-utilon por malnovaj komitaĵoj kaj la enlinia efektivigo por komitaĵoj ekde certa dato; garantiante formatstabilecon nur por nekunpremitaj arkivoj.
La malfacileco fari decidon klarigas per la fakto, ke reveni al voko al ekstera utileco ne tute solvas la problemon de neŝanĝebleco de ĉeksumo, ĉar ŝanĝo en la ekstera gzip-programo ankaŭ povas konduki al ŝanĝo en la arkiva formato. Nuntempe, aro de flikoj estis proponita por revizio, kiu resendas la malnovan konduton defaŭlte (vomante eksteran gzip-ilaĵon) kaj uzas la enkonstruitan efektivigon en foresto de gzip-ilaĵo en la sistemo. La flikoj ankaŭ aldonas al la dokumentado mencion ke la stabileco de la "git archive" eligo ne estas garantiita kaj la formato eble ŝanĝiĝos estonte.
fonto: opennet.ru