GitHub બિલ્ડ સિસ્ટમ્સ પર ક્રેશ થઈ રહ્યું છે 

એવું તાજેતરમાં જાણવા મળ્યું છે GitHub એ ફાઇલો બનાવવાની પદ્ધતિ બદલી છે લોન્ચ પૃષ્ઠો પર ".tar.gz" અને ".tgz" સ્વતઃ-જનરેટ થાય છે.

આ ફેરફાર ચેકસમમાં ફેરફાર અને બિલ્ડ સિસ્ટમમાં મોટા પાયે ક્રેશ થવાનું કારણ બને છે સ્વયંસંચાલિત, જે અગાઉ સંગ્રહિત ચેકસમ સામે GitHub માંથી ડાઉનલોડ કરેલી ફાઇલોની અખંડિતતાને ચકાસે છે, જેમ કે પેકેજ મેટાડેટા અથવા બિલ્ડ સ્ક્રિપ્ટ્સમાં મૂકવામાં આવેલી.

ગિટના સંસ્કરણ 2.38 મુજબ, મૂળભૂત રીતે સમાવેશ થાય છે gzip નું સંકલિત અમલીકરણ, આનાથી બધી ઓપરેટિંગ સિસ્ટમોમાં આ કમ્પ્રેશન પદ્ધતિ માટે સમર્થનને એકીકૃત કરવાનું શક્ય બન્યું અને ફાઇલ બનાવટની કામગીરીમાં સુધારો કરવો. GitHub એ તેમના ઇન્ફ્રાસ્ટ્રક્ચર પર ગિટ સંસ્કરણને અપગ્રેડ કર્યા પછી ફેરફાર પસંદ કર્યો.

Git ફાઇલો માટે ડિફૉલ્ટ કમ્પ્રેશન તાજેતરમાં બદલાયું છે. પરિણામે, સામગ્રી સંપૂર્ણપણે બદલાઈ ન હોવા છતાં GitHub પરથી ડાઉનલોડ કરેલી ફાઇલોમાં અલગ અલગ ચેકસમ હોઈ શકે છે.

GitHub આપમેળે જનરેટ થયેલ ફાઇલો માટે ચેકસમની સ્થિરતાની બાંયધરી આપતું નથી. આને વર્ઝન ટેબમાં "સોર્સ કોડ (ઝિપ)" અને "સોર્સ કોડ (tar.gz)" શબ્દોથી ચિહ્નિત કરવામાં આવ્યા છે. જો તમારે સતત ચેકસમ પર આધાર રાખવાની જરૂર હોય, તો તમે ફાઇલોને સીધી GitHub રિલીઝ પર અપલોડ કરી શકો છો.
આમાં ફેરફાર ન થવાની ખાતરી આપવામાં આવે છે.

સમસ્યા હતી ફાઇલો કરતાં જનરેટેડ ગોળીઓ gzip અમલીકરણ દ્વારા zlib બિલ્ડ વિવિધ દ્વિસંગી છે gzip યુટિલિટી દ્વારા જનરેટ કરેલી ફાઇલોમાંથી, જે વિવિધ ચેકસમમાં પરિણમે છે જ્યારે "ગીટ આર્કાઇવ" આદેશ ચલાવવામાં આવે ત્યારે ગિટના વિવિધ સંસ્કરણો દ્વારા બનાવેલ આર્કાઇવ્સ માટે.

પરિણામે, GitHub પર ગિટ અપડેટ કર્યા પછી, પ્રકાશન પૃષ્ઠો પર થોડી અલગ ફાઇલો દેખાવા લાગી જે ઉપરોક્ત ચેકસમ સાથે ચકાસણી કરવામાં નિષ્ફળ ગયા.

આ સમસ્યા વિવિધ બિલ્ડ સિસ્ટમ્સ, સતત એકીકરણ સિસ્ટમ્સ અને સ્રોતમાંથી પેકેજો બનાવવા માટેની ટૂલકિટ્સમાં પોતાને પ્રગટ કરે છે. ઉદાહરણ તરીકે, ફ્રીબીએસડીના લગભગ 5800 પોર્ટ તૂટી ગયા હતા, જેના સ્ત્રોતો GitHub પરથી ડાઉનલોડ કરવામાં આવ્યા હતા.

જવાબમાં નિષ્ફળતાઓ વિશેની પ્રથમ ફરિયાદો માટે, GitHub પ્રતિનિધિઓએ શરૂઆતમાં નોંધ્યું હતું કે ચેકસમની ક્યારેય ખાતરી આપવામાં આવતી નથી ફાઈલો માટે સ્થિરાંકો.

ફેરફારથી પ્રભાવિત બિલ્ડ સિસ્ટમ્સ બનાવવા માટે વિવિધ ઇકોસિસ્ટમ્સમાં મેટાડેટાને અપડેટ કરવા માટે નોંધપાત્ર પ્રમાણમાં કાર્યની જરૂર પડશે તે દર્શાવ્યા પછી, GitHub એ પરિવર્તનને પાછું ફેરવ્યું અને જૂની ફાઇલ જનરેશન પદ્ધતિ પર પાછું ફેરવ્યું.

અપેક્ષા મુજબ, લોકો ફરિયાદ કરવા લાગ્યા. GitHub કર્મચારી (અને ટોચના Git ફાળો આપનાર) તરફથી પ્રારંભિક પ્રતિસાદ બ્રાયન એમ. કાર્લસન સંપૂર્ણપણે સમજણ કરતા ઓછો હતો:

હું કહું છું કે નીતિ ક્યારેય સાચી રહી નથી અને અમે ક્યારેય ફાઇલો માટે સ્થિર ચેકસમની બાંયધરી આપી નથી, જેમ ગિટ ક્યારેય તેની ખાતરી આપી નથી. હું અહીં કામ ન કરતી વસ્તુઓ માટે ક્ષમા ચાહું છું અને ભૂતકાળમાં આ વિશે સ્પષ્ટ સંદેશાવ્યવહાર થયો નથી, પરંતુ 4 વર્ષથી અમારી નીતિ બદલાઈ નથી.

ગિટ ડેવલપર્સ તેઓએ હજુ સુધી કોઈ નિર્ણય લીધો નથી અને માત્ર સંભવિત ક્રિયાઓની ચર્ચા કરી રહ્યા છે. આ ધ્યાનમાં લેવામાં આવેલા વિકલ્પોમાં gzip ઉપયોગિતાનો ઉપયોગ કરવાનો સમાવેશ થાય છે મૂળભૂત; જૂની ફાઈલો સાથે સુસંગતતા જાળવવા માટે “–સ્થિર” ધ્વજ ઉમેરવું; બિલ્ટ-ઇન અમલીકરણને અલગ ફાઇલ ફોર્મેટ સાથે લિંક કરો; જૂની કમિટ માટે gzip યુટિલિટીનો ઉપયોગ કરીને અને ચોક્કસ તારીખથી કમિટ માટે બિલ્ટ-ઇન અમલીકરણ; માત્ર બિનસંકુચિત ફાઇલો માટે ફોર્મેટની સ્થિરતાની ખાતરી આપે છે.

નિર્ણયની જટિલતા એ હકીકત દ્વારા સમજાવવામાં આવી છે કે બાહ્ય ઉપયોગિતા કૉલ પર પાછા ફરવાથી ચેકસમ ઇન્વેરિઅન્સ સમસ્યા સંપૂર્ણપણે હલ થતી નથી, કારણ કે બાહ્ય gzip પ્રોગ્રામમાં ફેરફાર પણ ફાઇલમાં ફેરફારનું કારણ બની શકે છે.

હાલમાં, સમીક્ષા માટે એક પેચ સેટ છે જે ડિફૉલ્ટ વર્તણૂક પર પાછા ફરે છે (બાહ્ય gzip ઉપયોગિતાને બોલાવે છે) અને જ્યારે gzip ઉપયોગિતા સિસ્ટમ પર હાજર ન હોય ત્યારે બિલ્ટ-ઇન અમલીકરણનો ઉપયોગ કરે છે. પેચો દસ્તાવેજોમાં એક નોંધ પણ ઉમેરે છે કે "ગીટ આર્કાઇવ" નું આઉટપુટ સ્થિર હોવાની ખાતરી નથી અને તે ફોર્મેટ ભવિષ્યમાં બદલાઈ શકે છે.

છેલ્લે જો તમને તેના વિશે વધુ જાણવામાં રસ છે, તમે માં વિગતો ચકાસી શકો છો નીચેની કડી