التغييرات التي تم إجراؤها على Github لم تكن كما هو متوقع
تم مؤخرا الإبلاغ عن ذلك قام GitHub بتغيير طريقة إنشاء الملفات يتم إنشاؤه تلقائيًا ".tar.gz" و ".tgz" على صفحات الإطلاق.
هذا التغيير تسبب في تغييرات في المجاميع الاختبارية وأعطال هائلة في أنظمة البناء آلي ، والذي يتحقق من سلامة الملفات التي تم تنزيلها من GitHub مقابل المجاميع الاختبارية المخزنة مسبقًا ، مثل تلك الموضوعة في البيانات الوصفية للحزمة أو إنشاء البرامج النصية.
اعتبارًا من الإصدار 2.38 من Git ، متضمن بشكل افتراضي التنفيذ المتكامل لـ gzip ، هذا جعل من الممكن توحيد الدعم لطريقة الضغط هذه عبر جميع أنظمة التشغيل وتحسين أداء إنشاء الملفات. التقط GitHub التغيير بعد ترقية إصدار git على بنيتهم التحتية.
تم تغيير الضغط الافتراضي لملفات Git مؤخرًا. نتيجة لذلك ، قد تحتوي الملفات التي تم تنزيلها من GitHub على مجاميع اختبارية مختلفة على الرغم من أن المحتوى لم يتغير تمامًا.
لا يضمن GitHub استقرار المجاميع الاختبارية للملفات التي يتم إنشاؤها تلقائيًا. يتم تمييزها بالكلمات "كود المصدر (الرمز البريدي)" و "كود المصدر (tar.gz)" في علامة التبويب الإصدارات. إذا كنت بحاجة إلى الاعتماد على مجموع اختباري متسق ، فيمكنك تحميل الملفات مباشرة إلى إصدارات GitHub.
هذه مضمونة لعدم التغيير.
المشكلة كانت من الملفات الأجهزة اللوحية التي تم إنشاؤها بواسطة تطبيق gzip zlib build هي ثنائيات مختلفة من الملفات التي تم إنشاؤها بواسطة الأداة المساعدة gzip ، مما ينتج عنه مجاميع اختبارية مختلفة للأرشيفات التي تم إنشاؤها بواسطة إصدارات مختلفة من git عند تنفيذ الأمر "git archive".
وبالتالي ، بعد تحديث git على GitHub، بدأت ملفات مختلفة قليلاً في الظهور على صفحات الإصدار التي فشلت في التحقق مع الاختباري أعلاه.
تجلت المشكلة في أنظمة البناء المختلفة وأنظمة التكامل المستمر ومجموعات الأدوات لبناء الحزم من المصدر. على سبيل المثال ، تم كسر حوالي 5800 منفذ من FreeBSD ، تم تنزيل مصادرها من GitHub.
كرد إلى الشكاوى الأولى حول الإخفاقات ، لاحظ ممثلو GitHub في البداية أن المبالغ الاختبارية لم يتم ضمانها أبدًا ثوابت للملفات.
بعد أن تبين أن إنشاء أنظمة بناء متأثرة بالتغيير سيتطلب قدرًا كبيرًا من العمل لتحديث البيانات الوصفية عبر النظم البيئية المختلفة ، غيّر GitHub موقفه ، وأعاد التغيير والعودة إلى طريقة إنشاء الملفات القديمة.
كما هو متوقع ، بدأ الناس يشكون. الاستجابة الأولية من موظف GitHub (وأكبر مساهم في Git) brian m. كان كارلسون أقل من يفهم تمامًا:
أنا أقول أن هذه السياسة لم تكن صحيحة أبدًا ولم نضمن مطلقًا وجود مجاميع اختبارية مستقرة للملفات ، تمامًا مثلما لم يضمنها Git أبدًا. أعتذر عن الأشياء التي لا تعمل هنا ولم يكن هناك اتصال أوضح حول هذا في الماضي ، لكن سياستنا لم تتغير منذ أكثر من 4 سنوات.
مطورو جيت لم يتخذوا قرارًا حتى الآن ويناقشون فقط الإجراءات الممكنة. ال تشمل الخيارات التي تم النظر فيها اللجوء إلى استخدام الأداة المساعدة gzip تقصير؛ إضافة علامة "–stable" للحفاظ على التوافق مع الملفات القديمة ؛ ربط التنفيذ الداخلي بتنسيق ملف منفصل ؛ استخدام الأداة المساعدة gzip للالتزامات القديمة والتنفيذ المدمج للالتزامات من تاريخ معين ؛ ضمان استقرار التنسيق فقط للملفات غير المضغوطة.
يفسر تعقيد القرار حقيقة أن الرجوع إلى استدعاء الأداة الخارجية لا يحل تمامًا مشكلة ثبات المجموع الاختباري ، نظرًا لأن التغيير في برنامج gzip الخارجي يمكن أن يتسبب أيضًا في تغيير الملف.
حاليًا ، هناك مجموعة تصحيح للمراجعة تعود إلى السلوك الافتراضي (استدعاء أداة gzip خارجية) وتستخدم التنفيذ المدمج عندما لا تكون الأداة المساعدة gzip موجودة على النظام. تضيف التصحيحات أيضًا ملاحظة إلى الوثائق مفادها أن إخراج "أرشيف git" غير مضمون وأن التنسيق عرضة للتغيير في المستقبل.
أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها، يمكنك التحقق من التفاصيل في الرابط التالي.