Konstruktsioonisüsteemide tõrked, mis on põhjustatud GitHubi arhiivide kontrollsummade muutumisest.

GitHub on muutnud automaatsete .tar.gz ja .tgz arhiivide loomise meetodit väljaannete lehtedel, mis on põhjustanud nende kontrollsummade muutumise ja massilised tõrked automatiseeritud kogumissüsteemides, mis kontrollivad allalaaditud GitHubi arhiivide terviklikkust eelnevalt salvestatud kontrollsummadega, näiteks pakettide metainfotest või kogumisskriptidest.

Alates versioonist 2.38 on Git tööriistakomplekti sisse lülitatud vaikimisi sisseehitatud gzip teostus, mis võimaldab ühtlustada selle kompressioonimeetodi toetust erinevates operatsioonisüsteemides ning suurendada arhiivide loomise tõhusust. GitHub võttis muudatuse kasutusele pärast git versiooni värskendamist oma infrastruktuuris. Probleemi põhjustas see, et sisseehitatud gzip teostuse, mis põhineb zlib-il, genereeritud arhiivid on binaarselt erinevad võrreldes gzip utiliidiga loodud arhiividega, mis viis kontrollsummade erinevusteni erinevate git versioonide kasutamisel käsu „git archive“ täitmisel.

Seetõttu, pärast git'i värskendamist anti GitHubis välja veidi erinevad arhiivid, mis ei läbinud vanade kontrolsummade kontrolli. Probleem ilmnes erinevates ehitussüsteemides, pideva integreerimise süsteemides ja paketihalduse tööriistades, mis sõltusid lähtekoodist. Näiteks tekkis probleeme umbes 5800 FreeBSD sadama ehitusega, mille lähtekood laaditi GitHubist.

Esimesele kaebusele tekkinud tõrgete kohta viitasid GitHubi esindajad alguses sellele, et püsivad kontrolsummad arhiivide jaoks pole kunagi garanteeritud. Pärast seda, kui näidati, et ehitussüsteemide taastamiseks, mida muudatus mõjutas, on vajalik tohutu töö metainformatsiooni uuendamiseks erinevates ökosüsteemides, muutsid GitHubi esindajad oma arvamust, tühistades muudatuse ja naasdes vanasse arhiivide genereerimise meetodisse.

Git arendajad pole veel mingit lahendust leidnud ja arutavad vaid võimalikke tegevusi. Arutelu alla on võetud sellised võimalused nagu tagasi minemine vaikimisi gzip utiliidi kasutamise juurde; lisada lipp «—stable», et säilitada ühilduvus vanade arhiividega; siduda sisseehitatud teostus eraldiseisva arhiiviformaadiga; kasutada gzip utiliiti vanade commitide puhul ja sisseehitatud teostust commitide puhul, alates teatud kuupäevast; tagada formaadi stabiilsus ainult tihendamata arhiivide jaoks.

Otsuse langetamise keerukus tuleneb sellest, et tagasiviimine välise utiliidi kutsumise juurde ei lahenda probleem kontrollsummade muutumatuse osas, kuna ka muudatus välises gzip programmis võib viia arhiiviformaadi muutumiseni. Praegu on ülevaatamiseks esitatud komplekt patše, mis taastab vaikimisi vanade käitumise (välise gzip utiliidi kutsumise) ja kasutab sisseehitatud teostust juhul, kui süsteemis ei ole gzip utiliiti. Patchid lisavad ka dokumentatsiooni märkuse, et «git archive» väljundi stabiilsust ei tagata ning vorming võib tulevikus muutuda.

Allikas: opennet.ru