الخلاصة

  • يحتفظ GitHub بملفات الأعمال وسجلاتها 90 يوماً افتراضياً. تغيير المدة في المستودع ينطبق على الملفات الجديدة؛ القديمة تحتفظ بموعد انتهائها الأصلي.
  • فوق الحصة المضمنة، يُحسب التخزين بساعات غيغابايت. حذف ملف قديم يوقف تراكم الساعات التالية ويخفض المساحة الحالية، بينما تبقى الساعات السابقة في دورة الفاتورة.

زر الحفظ لا ينظف الرف القديم

يراجع فريق التطوير إعدادات المستودع ويكتشف أن ملفات البناء تبقى أطول من حاجته. يقلص المدة وينجح التعديل. تبدأ الملفات المقبلة بعمر أقصر، لكن ما وُضع على الرف قبل التعديل يسير نحو موعد الانتهاء الذي سُجل عند إنشائه. هذا فرق بين سياسة الاستقبال ومخزون موجود فعلاً.

تحدد وثائق GitHub الوضع الافتراضي بتسعين يوماً. يسمح للمستودعات العامة بمدة بين يوم و90 يوماً، وللخاصة بين يوم و400 يوم وفق حدود المؤسسة. المدة المعدلة تخص الملفات والسجلات الجديدة فقط. تعرض واجهة البرمجة قيمة expires_at للملف الموجود، ويمكن حذفه قبل موعده. الحذف نهائي؛ لذا يحتاج ملف إصدار أو تحقيق في عطل إلى قرار من الجهة التي تعتمد عليه، لا إلى تنظيف آلي بناءً على الحجم وحده.

أما الفاتورة فتقيس وقت إشغال المساحة. يفرق GitHub بين التخزين الحالي والاستخدام الذي تراكم خلال الدورة. عندما يُحذف ملف، ينخفض الرقم الأول وتتوقف زيادته المستقبلية في الثاني. الساعات السابقة لا تختفي. يشرح GitHub الحساب بمثال 10 غيغابايت حُفظت عشرة أيام ثم حُذفت في اليوم الحادي عشر: يبقى 2400 غيغابايت-ساعة في سجل الدورة. المثال يشرح طريقة الحساب.

وتتأخر شاشة استخدام تخزين الملفات من ست إلى اثنتي عشرة ساعة، بحسب GitHub. لذلك لا تكفي قراءة واحدة بعد التعديل. يلزم حصر الملفات القديمة ومواعيد انتهائها، ثم متابعة المساحة الحالية والساعات المتراكمة. ملفات الأعمال تتشارك الحصة المضمنة مع GitHub Packages؛ لذاكرة التخزين المؤقت في Actions حصة مستقلة.

المصادر