طلب ذو صلة: # 2566

لقد بدأت العمل على هذا.
بالنظر إلى التعليقات الموجودة على # 2566 ، هل نبحث عن - قيم أم - مجموعة (أو كليهما؟)

تم وصف حالة استخدام لطيفة في الإصدار الذي فتحته (# 3198) ، والذي أود أن أكون قادرًا على القيام به:

helm package --version 1.2.3 --set image.tag 1.2.3

بهذه الطريقة يكون إصدار المخطط وإصدار صورة عامل الإرساء واحدًا واحدًا.

لقد أكملت للتو المسودة الأولى ونشرت إعلانًا عامًا لهذا الغرض.

ngeor ، sslavic يضيف العلاقات العامة التي أرسلتها كلاً من خيارات الضبط والقيم ، هل يمكنك إلقاء نظرة من فضلك؟

مرحبًا adshmh ، تبدو جيدة ؛ للأسف لا أعرف Go ولكني أرى أنك قمت بتغطيتها بحالات الاختبار وكلها ، لذلك ربما تفعل ما تقول :) شكرًا!

متى ستكون هذه الميزة متاحة؟ في 2.9.0؟

فات 3471 الموعد النهائي لـ 2.9 لذا سيكون في 2.10.

إعادة فتح هذا ، لأن # 3471 يحتاج إلى دعم.

ماذا يفعل هذا للتعليقات / وما إلى ذلك في حزمة الأرشيف؟ على سبيل المثال ، هل تم تجريدهم أو تركهم وشأنهم أم ؟؟

أحاول حاليًا أن أفعل نفس الشيء مع yq لكنه يفرغ القيم النهائية بعد المعالجة. على سبيل المثال ، اختفت جميع التعليقات والأسطر الفارغة للتنظيم وما إلى ذلك.

قام 3471 بتجريد جميع التعليقات ، ولهذا السبب احتجنا إلى دعم هذا العلاقات العامة. راجع https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 لمزيد من المعلومات

تم الإرجاع من 2.10 "إنجازًا: add --set and --values ​​options to 'helm package" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

بعض الأخبار حول هذا؟
شكرا

نفس ما ورد أعلاه ؛ لم يعمل أحد على متابعة لإصلاح الخلل في 3471 # لذلك لم يتم تنفيذ ذلك. أنت أكثر من مرحب بك لتقسيم Helm والتجميع مقابل # 3471 إذا كنت على ما يرام مع التعليقات التي يتم تجريدها من ملف القيم.

هل تم ذلك؟ حاولت على الإصدارات 2.11.0 و 2.12.0 لا يبدو أن أيًا منهما يحتوي على helm package --set...

+1. سيساعدنا حقًا في CI في إيقاف تمرير القيم وترقيتها قبل التعبئة.

+1

يمكن أن تكون --set-string مفيدة أيضًا ، فلماذا لا تسمح بكل خيارات التجاوز الموجودة في التثبيت / الترقية.
ما عليك سوى تنفيذ نفس الكود المستخدم لتجاوز قيم أمر الحزمة ، فمن المنطقي أن تحتوي الحزمة على قيم التجاوز - يجب مشاركة هذه العلامات تمامًا كما هو الحال مع التثبيت / الترقية.

لا يحتوي 2.13.1 على هذه الميزة أيضًا ، فهل يوجد أي جدول زمني لها؟

كما ذكرنا سابقًا ، لا أحد يعمل حاليًا على هذا ولا يوجد جدول زمني لموعد توفر الإصلاح. لا تتردد في أخذ هذا. الق نظرة على # 3471 للأفكار.

تم تنفيذه في حلم 3 . إغلاق!

بالنظر إلى الكود ، يبدو أنه # 3471 شق طريقه بطريق الخطأ إلى Helm 3 ، لكن لم يتم سحبه أبدًا كما فعلنا مع Helm 2 بسبب هذا التعليق: https://github.com/helm/helm/pull/3471#issuecomment -381779783

أقوم بإعادة فتح طلب الميزة هذا لأننا نزيل علامتي --set و --values ​​في Helm 3 باستخدام https://github.com/helm/helm/pull/7201. لم يعملوا أبدًا على أي حال ... أي شيء تم تعيينه عبر --set أو --values لم يتم إدخاله مطلقًا في الحزمة ، وقد أدخل بعض الانحدارات القاتلة مع helm package ، أي حقيقة أنه تم تجريده الخروج من التعليقات من القيم yaml ، والتي يستخدمها العديد من أعضاء المجتمع كتوثيق.

ربما أنا أسيء الفهم ، لكني كنت سعيدًا باستخدام - مع حزمة لتعيين القيم وقد عملت بشكل رائع من 3.0.0 إلى 3.0.2 ، وبالتأكيد ليس "no-op" كما هو موضح في # 7201.

خطوط الأنابيب الخاصة بي معطلة منذ 3.0.3. كان هذا يعمل في 3.0.2. لماذا لا يعتبر هذا مفيدًا ، إذا كان لدينا الإصدار و app-version. كيف يُفترض بنا أن نعدل الصورة والعلامة لتتناسب مع إصدار التطبيق؟ باش؟

بالنظر إلى الكود مرة أخرى ، فأنت على صواب lukaslarson وmaxhillaert. ومع ذلك ، كانت هذه الميزة لا تزال تهدف إلى التراجع لأنها جردت جميع التعليقات من ملف قيم الحزمة. تمت إزالته في Helm 2 ، لكنه شق طريقه بطريق الخطأ إلى Helm 3. ولم يكن من المفترض أن يتم شحنه مطلقًا.

إذا أراد شخص ما العمل على إعادة تنفيذ رقم 3471 الذي يحتفظ بالتعليقات ، فسيسعدنا إلقاء نظرة على العلاقات العامة.

bacongobbler هذا كسر بعض الأشياء بالنسبة لنا. سأكون مهتمًا بالعمل في العلاقات العامة ، على الرغم من أنها تبدو غير تافهة ، لذا أود التحقق من النهج.

يبدو أن gopkg.in/yaml.v3 يدعم الاحتفاظ بالتعليقات عند الذهاب ذهابًا وإيابًا. اقتراحي هو جعل Values a yaml Node . بعد ذلك ، عند دمج القيم ، اسلك شجرة الإخراج المحلل بدلاً من الخرائط المتداخلة. هذا بالتأكيد أقل راحة ولكنه أفضل طريقة للحفاظ على التعليقات.

هذه مشكلة صغيرة لأننا نستخدم sigs.k8s.io/yaml في كل مكان مثبت في v2 من lib الأساسي. الحد الأدنى ، سيتطلب هذا تقديمه كتبعية منفصلة ، وهو نوع من اليأس. لست متأكدًا من أفضل نهج هنا هو تجنب لمس كل ما يتعامل مع yaml.

يبدو أن الخيار الأفضل هو الانتقال إلى yaml.v3 ، لذلك يبدو أنك على المسار الصحيح.

إذا كنت ترغب في بدء العمل على PoC / fork of Helm الذي يستخدم yaml.v3 بدلاً من sig.k8s.io/yaml ، فسيكون هذا طريقًا جيدًا للأمام. بهذه الطريقة يمكننا البدء في تقييم وظائفها مقارنة بما هو موجود في master .

بمجرد أن نثبت أن yaml.v3 هو أفضل مسار للمضي قدمًا ، يمكننا معرفة كيفية المضي قدمًا من وجهة نظر SDK.

هل يساعد ذلك في فك الحظر؟

jmcelwain هل تعمل بنشاط على هذا؟ سأقوم بكل سرور بهذا الأمر إذا لم يكن كذلك.

@ sreya92 مشغول في العمل. هنا حيث توقفت: كان التبديل إلى yaml.v3 سهلًا في الغالب ، باستثناء هذا الجزء هنا . لم أكن متأكدًا من أفضل طريقة للتعامل مع هذا الأمر دون الذهاب إلى أبعد من بيع التبعية وتحديثها إلى الإصدار 3 هناك.

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

رأيي الشخصي هو أن هذا مانع لهذه المشكلة ، ما لم يشعر القائمون على الصيانة أن حمل نسختين من libs المتشابهة يستحق العناء. لست متأكدًا من ماهية LoE هنا ، ولكن من المحتمل أن نعمل على الحصول على github.com/ghodss/yaml إلى الإصدار 3 والحصول على ترقية الإصدار المباع في k8s أيضًا. هذا من شأنه أن يجعل كل هذا أسهل بكثير.

تم فتح https://github.com/ghodss/yaml/issues/61 للاستعلام عن إمكانية وجود مسار ترقية هناك. سوف ننتظر لسماع رد منهم قبل متابعة أي شيء آخر - ترقية التبعيات هي الطريقة المفضلة للخيارات الأخرى IMO.

jmcelwain لا توجد كمية كبيرة من التعليمات البرمجية في https://github.com/ghodss/yaml ، هناك طلبات سحب غير مُلقاة من عام 2017: https://github.com/ghodss/yaml/pulls ، والرمز هو MIT مرخص.

هل هذه التبعية تسحب ثقلها حقًا؟ إنها عبارة عن عدد قليل من مساعدي التنظيم ولكنها تمكنت من إيقاف مشكلة قد تؤدي عند حلها إلى تحسين قدرة العديد من المشاريع على تعيين الإعدادات الافتراضية للحزمة ديناميكيًا في وقت الإنشاء (يجب ألا تضطر حالة الاستخدام الخاصة بنا إلى الاحتفاظ بأماكن متباعدة متعددة لتخزين علامات الإصدار شيء من هذا القبيل --set image.tag=${GIT_TAG} لإصدارات الرسوم البيانية والصورة لمشروع ما).

هل يمكنني أن أقترح ألا ننتظر أكثر من ذلك ونقوم فقط بنسخ الكود الضروري في الدفة (لن أزعجني في بيعه فقط بامتصاصه والتكيف معه حسب الضرورة). أعتقد أنه مشروع كبير بما يكفي للتعامل مع صيانة هذا الغلاف وأن تنظيم YAML هو كفاءة أساسية (لا يعني أنه يجب عليك الحفاظ على المحلل اللغوي الخاص بك ، ولكن ...!)

نظرًا لأن هذا يسبب لنا الألم في الوقت الحالي (ويوقفنا عن الترقية من الإصدار 3.0.2) ، سأكون سعيدًا بأخذ طعنة في ذلك.

أفضل تجنب هذا الموقف. لا يوجد عدد كافٍ من المشرفين للحفاظ على كلٍ من مدير الحزم ومحلل YAML. سيؤدي ذلك إلى عبء صيانة كبير على الفريق.

bacongobbler إنه _not_ محلل yaml. يستخدم gopkg.in/yaml.v2 لإجراء التحليل الفعلي. إنه حوالي 900 سطر من كود غلاف reflect حول هذا المحلل اللغوي. المشكلة هي أنهم لا يستخدمون gopkg.in/yaml.v3 لحل هذه المشكلة.

يبدو لي أن عبء الصيانة الناتج عن استخدام هذا الوسيط البسيط لاعتمادك الفعلي يمثل عبئًا أكبر يحافظ على هذا الجزء من الكود.

كما ذكرنا سابقًا في الموضوع ، لا تتردد في اقتراح PR upstream لتحديث ghodss / yaml إلى yaml.v3. إذا لم يقبلوا ذلك ، فلا تتردد في تفرع المشروع والحفاظ عليه إذا شعرت أنه يمكنك تحمل عبء الصيانة.

اسمحوا لي أن أكون واضحًا على الرغم من ذلك: لن نقبل طلبات السحب التي تفرزها والبائع ghodss / yaml إلى Helm. لا يمكننا تحمل عبء الصيانة الإضافي لمكتبة Go بأكملها لدعم ميزة واحدة فقط.

bacongobbler ، يرجى إلقاء نظرة على العلاقات العامة الخاصة بي هنا: https://github.com/helm/helm/pull/7963

إنه 900 سطر من التعليمات البرمجية مع الاختبارات المضمنة وإزالة الوظائف الزائدة.

أنت الآن تعتمد على ما يبدو كمكتبة غير مدارة نسبيًا ذات مساحة أكبر بكثير مما أضفته هناك.

مكتبة Go كاملة فقط لدعم ميزة واحدة

أنت تستخدم كل وظيفة واحدة من مكتبة Go بأكملها ، ومن أجل القيام بذلك ، بذلت جهدًا لإنشاء مفترق دائم يحجب مصدر الشفرة.

لا تتردد في تفرع المشروع وصيانته إذا شعرت أنه يمكنك تحمل عبء الصيانة.

أعني أنك تدير بالفعل تفرعًا منفردًا لهذا الرمز. إذا تم التخلي عن المشروع ، فأنت لا تستفيد فعليًا من أي صيانة من المؤلف الأصلي.

إذا كنت ترغب في ذلك ، يمكنني أخذ هذا المقدار الصغير من الكود في العلاقات العامة الخاصة بي ووضعه في الريبو وأقول إنني سأحتفظ به (وسأحاول القيام بذلك) ، لكنه يبدو سخيفًا إلى حد ما.

اسمحوا لي أن أكون واضحًا على الرغم من ذلك: لن نقبل طلبات السحب التي تفرزها والبائع ghodss / yaml إلى Helm.

للتسجيل ، كنت قد دفعت بالفعل إلى تلك العلاقات العامة بحلول الوقت الذي قرأت فيه هذا ، لذلك آمل أن تعيد النظر لأنني أعتقد أن لديك فكرة مخبأة حول "البيع" و "مكتبة Go بأكملها" (والتي قد أتفق معها غالبًا ) دون النظر إلى الكود المتضمن. لكن دعونا نناقش الكود الفعلي المعني في العلاقات العامة. يسعدني أن أكون مالك رمز لهذا الرمز إذا كان ذلك يساعد. دعنا نتخيل أنني كتبته كمساهمة ... لقد فعلت ذلك نوعًا ما.

ربما سيقومون بدمجه: https://github.com/ghodss/yaml/pull/62

كان البديل الآخر الذي استكشفته باختصار هو إمكانية استبدال تحويل YAML إلى JSON عبر بعض التبعية الأخرى أو التسلسل من خلال بعض التنسيقات الوسيطة. لست على دراية كافية بنظام Go الإيكولوجي لمعرفة ما إذا كان هذا مسارًا قابلاً للتطبيق - لقد فوجئت إلى حد ما بأني لم أجد المزيد من libs من نوع التسلسل عندما نظرت لفترة وجيزة.

أي فكرة عن الوقت الذي يمكننا فيه الحصول على - العودة لأننا نستخدم هذا لأتمتة تغليف الدفة. كان في Helm 3.0.2 والآن منذ التحديث لم يعد مدعومًا.

ما زلنا ممنوعين من دمج https://github.com/ghodss/yaml/pull/62 .

بالنظر إلى الكود مرة أخرى ، فأنت على صواب lukaslarson وmaxhillaert. ومع ذلك ، كانت هذه الميزة لا تزال تهدف إلى التراجع لأنها جردت جميع التعليقات من ملف قيم الحزمة. تمت إزالته في Helm 2 ، لكنه شق طريقه بطريق الخطأ إلى Helm 3. ولم يكن من المفترض أن يتم شحنه مطلقًا.

إذا أراد شخص ما العمل على إعادة تنفيذ رقم 3471 الذي يحتفظ بالتعليقات ، فسيسعدنا إلقاء نظرة على العلاقات العامة.

هل يهم إذا تمت إزالة التعليقات ، إذا كان هناك تحذير باستخدام - مجموعة لا أهتم بالتعليقات.

ما زلنا ممنوعين من دمج ghodss / yaml # 62 .

أعتقد أنهم عالقون في استخدام 3.0.2 :(

تم تجريد 3471 من التعليقات بغض النظر عما إذا كنت تستخدم --set أم لا ، لذا فقد حطمت المستخدمين الذين لم يستخدموا هذه الميزة مطلقًا. كسر التوافق مع الوراء للجميع. لذلك لا يمكن إعادة تقديمه مع تحذير ، ولهذا السبب ننتظر إصلاحًا مناسبًا في المنبع.

ولهذا السبب علينا التمسك بـ 3.0.2

ما زلنا ممنوعين من دمج ghodss / yaml # 62 .

ولكن نظرًا لأنه يبدو أن هذه التبعية لم تعد محفوظة ، فربما يكون من الأفضل استخدام نسخة متشعبة ، أليس كذلك؟

يعد التبديل فكرة جيدة - ولكن يجب تأجيله إلى Helm 4. يجب أن يقدم شخص ما مشكلة خاصة لتبديل موزعي YAML حتى نتمكن من تتبع ذلك لعملية Helm 4.

اسمحوا لي أن أكون واضحًا على الرغم من ذلك: لن نقبل طلبات السحب التي تفرزها والبائع ghodss / yaml إلى Helm. لا يمكننا تحمل عبء الصيانة الإضافي لمكتبة Go بأكملها لدعم ميزة واحدة فقط.

نظرًا لأنه يبدو أن https://github.com/ghodss/yaml لم يعد يتم الاحتفاظ به ، ولا توجد علامة على الحياة على https://github.com/ghodss/yaml/pull/62 ، فهل يستحق إعادة النظر في هذا الموقف ، و إعادة تقييم https://github.com/helm/helm/pull/7963 ؟

لسنا مهتمين بتحمل أعباء الصيانة لدعم مكتبة تحليل YAML كاملة لميزة واحدة فقط.

أود أن أحث المجتمع على التفكير في العمل مع المشرفين الحاليين على ghodss / yaml للعثور على مجموعة جديدة من المشرفين الراغبين في دعم المشروع ، أو تقسيم المشروع ، أو العثور على مكتبة جديدة يمكنها الاحتفاظ بالتعليقات.

إذن ماذا سيكون؟

• البحث عن مشرفين جدد لدعم ghodss / YAML!؟
• ابحث عن شخص ما لتفكيك ghodss / YAML واستخدم YAML.v3 (واستمر في دعمه) !!
• استخدم YAML.v3 مباشرة
• اقتراح تبديل موزعي YAML للدفة 4

مكتبة تحليل YAML كاملة

هذا يحرف نطاق الكود المتضمن هنا. إنه عدد قليل من الأغلفة حول الموزعين الآخرين.

لسنا مهتمين بتحمل أعباء الصيانة لدعم مكتبة تحليل YAML كاملة لميزة واحدة فقط.

ربما يفسر هذا الالتباس الكثير - المحلل اللغوي هو https://github.com/go-yaml/yaml وليس ghodss / YAML. من https://github.com/ghodss/yaml :

غلاف حول go-yaml

لذا فإن الحل البسيط هو: فقط توقف عن استخدام الغلاف.

"الأغلفة" لها تأثير عميق على بعض السلوكيات. بعد تبديل الموزعين (والمكتبات المجمعة) عدة مرات في وقت مبكر من المشروع ، يدرك المشرفون الأساسيون تمامًا الاختلافات الصغيرة بينهم ، وكيف ينتج عنهم مشكلات توافق عالية المستوى.

هناك احتمال أن نفكر في استخدام مفترق ghodss / yaml IF وفقط إذا كان مالكو تلك الشوكة ملتزمين بالصيانة المستمرة.

ربما يمكنني أن أكون أكثر دقة - توقف عن استخدام مكتبة الغلاف المهجورة ، وافعل سلوك التغليف المكافئ / المتطابق في الدفة ، وهو ما يفعله https://github.com/helm/helm/pull/7963 في حوالي 250 LOC plus الاختبارات.

نعم ، من الناحية المثالية بدلاً من ذلك ، قد يصلح شخص ما في ghodss / yaml ، لكن لم يعد يتم صيانته. بالتأكيد البديل لا ينتظر حتى هيلم 4؟

أعتقد أن التفرع هو الخيار الأفضل على الأرجح ، IMO ؛ لا يبدو أن ghodss كان لديه أي نشاط على GH منذ أوائل عام 2019 ، وكان آخر التزام في الريبو قبل عام ونصف (بواسطةbradfitz). كان الإصدار الأخير (فقط) في عام 2017. إذا كانت هناك أي مشكلات أمنية كامنة في الكود ، فلن يتم إصلاحها على main.

كنت أؤيد بشدة اعتماد شوكة إذا كان شخص ما على استعداد للالتزام بالحفاظ عليها ؛ لا أرى أي جوانب سلبية تتعلق بالاستمرار في استخدام حزمة محتضرة ومهجورة. أوافق على أن الانتقال إلى غلاف مختلف يكون أكثر منطقية باعتباره تغييرًا كبيرًا (يبدو أنه رفع ثقيل بدرجة كافية بحيث يمكن أن يكون شيئًا من طراز Helm 4 بسهولة ، لكنني لن أتوقع المزيد) ، لكنني أعتقد أنه يمكن حل هذا الأمر بخط replace في go.mod .

أنا على استعداد للالتزام بالمساعدة في الحفاظ على شوكة إذا كان هناك شخص آخر كذلك ؛ ليس لدي نطاق ترددي كافٍ للقيام بذلك بنفسي الآن ، ولكن لدي ما يكفي للمساهمة.

من المسلم به ، أنني مهتم في الغالب بهذا حتى أتمكن من التخلص من كومة النصوص الخاصة بي المكونة من sed لتعبئة مخططات Helm الخاصة بي ، ولكن إذا كان هذا هو ما يتطلبه الأمر ، فليكن.

أهلا بك
لقد قمت للتو بإنشاء مكون إضافي يسمح بتعيين القيم عند الحزم. في الوقت الحالي ، يدعم فقط العلم set (لأنني كنت بحاجة إلى ذلك: sweat_smile :) لكنني أنوي إضافة أعلام أخرى. لا تتردد في دفع العلاقات العامة إذا أردت أو أضف ملاحظات من أجل تحسينها.
شكرا لك

فقط في حالة عدم متابعة أي شخص ، كان هناك بعض التقدم في ghodss / yaml # 62 في الاتصال بمشرف ، لذلك نأمل أن نسمع بعض الأخبار الجيدة قريبًا!

تم وضع علامة على هذه المشكلة على أنها قديمة لأنها كانت مفتوحة لمدة 90 يومًا بدون أي نشاط. سيتم إغلاق هذا الموضوع تلقائيًا في غضون 30 يومًا إذا لم يحدث أي نشاط آخر.

بالتأكيد ليست قديمة. لقد كنت أحاول إيجاد الوقت للمتابعة مع https://github.com/ghodss/yaml/pull/62 ومعرفة ما إذا كان بإمكاننا المساعدة في دمجها لإلغاء حظر التقدم في هذه المشكلة. نظرًا لأن مؤسستي زادت من اعتمادنا على Helm ، فإننا لا نزال نرغب في أن نكون قادرين على جمع القيم في مخطط حزم بناء لكل CI.

لقد حذفت أي تعليقات طلبت تحديثًا للحالة لأنها لا تضيف أي شيء إلى المحادثة الحالية. قدم jmcelwain تحديثًا للحالة منذ ما لا يقل عن 5 أيام (شكرًا لك ، راجع للشغل) وهو جيد مثل أي تحديث. كما ذكرنا سابقًا ، فإن حل هذه المشكلة صعب ويتضمن تحديث العديد من التبعيات أو تفرغها ، لذلك هناك بعض العناية الواجبة المطلوبة.

عندما يكون لدينا المزيد من المعلومات لمشاركتها ، سنقوم بتحديث الموضوع.

كحل بديل ، استخدمت https://github.com/mikefarah/yq لتحديث مخطط دفتري قبل التعبئة والتغليف:

yq w -i values.yaml version $(Build.BuildNumber)

في CI الخاص بنا ، نبني صورة التطبيق / عامل الإرساء والمخطط في نفس خط الأنابيب (للتأكد من أن التطبيق والمخطط يتطوران مع نفس الإصدار). تعتمد القيم الافتراضية للمخطط على إصدار الصورة الذي تم إنشاؤه مسبقًا.

يمكن دمج حل yq بسهولة في خط الأنابيب ، ولكن يبدو من الغريب أن حالة الاستخدام هذه لم يتم تغطيتها بشكل صحيح بواسطة الدفة!

لذا فهي ليست طريقة متكاملة مع الدفة لتعيين علامة الصورة أثناء / قبل مرحلة الحزمة؟

تحرير : وجدنا هذا الحل في حالتي ، نحتاج إلى استخدام Chart.AppVersion لعلامة الصورة لأننا نحزم المخطط بنفس الإصدار.

تحرير 2 : Chart.AppVersion / لا تعمل مع الرسم البياني المشترك (اكتشف مخطط الإقلاع الربيعي المستخدم في مخططات مظلة متعددة)

استنتاجي : أحتاج حقًا إلى ضبط image.tag أثناء مرحلة الحزمة

أي أخبار عن هذه الميزة؟