تضمين التبعيات محليًا باستخدام helm dependency update

لقد أدرجت تبعياتك في Chart.yaml. والآن يعمل helm dependency update على جلبها فعليًا ووضعها داخل مخططك.

تصل المخططات الفرعية التي جلبتها إلى مجلد charts/ بجوار قوالبك. يضم Helm كل ما يوجد هناك ويصيّره مع مخططك.

تُخزَّن كل تبعية افتراضيًا كأرشيف مضغوط .tgz في charts/. ويفك Helm ضغطها تلقائيًا عند التثبيت والتصيير.

ينشئ التحديث ملف Chart.lock الذي يثبت الإصدارات المحلولة وملخصات التجزئة الدقيقة. وهو ملف القفل الذي يجعل عمليات البناء قابلة لإعادة الإنتاج.

ينبغي لك إضافة Chart.lock إلى Git. عندئذٍ يحل أعضاء الفريق وCI الإصدارات نفسها تمامًا، بدلًا من أن ينحرف كل منهم إلى إصدارات مختلفة.

يثبّت helm dependency build الإصدارات المثبتة مسبقًا في Chart.lock. أما update فيعيد الحل انطلاقًا من Chart.yaml ويعيد كتابة ملف القفل.

في CI، تفضّل عادةً استخدام dependency build. فهو يثق بملف القفل المضاف إلى المستودع، ولذلك لا تقوم البنية تلقائيًا بترقية مخطط فرعي من دون علمك.

شغّل helm dependency list لرؤية كل تبعية معلنة وحالتها. يوضح الأمر ما إذا كان مجلد charts/ يطابق Chart.yaml.

يتصل update بكل repository لتنزيل المخططات. وبالنسبة إلى مستودعات HTTP، قد تحتاج أولًا إلى تشغيل helm repo add حتى يتمكن Helm من حل @alias.

إما أن تضع الفرق أرشيفات charts/ في المستودع لإجراء عمليات بناء دون اتصال، أو تتجاهلها عبر gitignore ثم تعيد بناءها من Chart.lock في CI. اختر أسلوبًا واحدًا والتزم به.

كلما غيّرت إصدارًا في Chart.yaml، أعد تشغيل dependency update. وإلا فسيظل charts/ وChart.lock قديمين وغير متزامنين.

يجب أن تبني CI الإصدارات الدقيقة للمخططات الفرعية التي أضافها أحد أعضاء الفريق. ما الأمر الأنسب؟

تعلمت أن dependency update يملأ charts/ وينشئ Chart.lock، بينما يعيد build تطبيق ذلك القفل. أضف ملف القفل إلى المستودع لضمان عمليات تثبيت قابلة لإعادة الإنتاج. 🔒