أحاول تقديم إضافة، وأواجه هذا الفشل عند فك ضغط redis.
هل قد تكون --long=30 هي المشكلة؟ لست متأكدًا تمامًا من كيفية محاولة تصحيح هذا…
إعجاب واحد (1)
أعتقد أن الخطأ يقول إنه لا يمكنه تنفيذ zstd. هل لديك هذه الحزمة مثبتة؟
لا. ربما تغير شيء ما في صورة Docker الأساسية، أو نظام التشغيل الذي تم إنشاؤه به ويحتاج إلى إضافته هناك. لست متأكدًا حقًا من أين يجب أن يحدث ذلك، لكنني متأكد تمامًا من أنه ليس في المكون الإضافي الخاص بي. 
متطلب zstd يأتي من حزمة redis (التي تم تنزيلها في لقطة الشاشة الخاصة بك) والتي تم ضغطها بواسطة zstd. إذا لم يكن zstd مطلوبًا من قبل، فمن المحتمل أن طريقة الضغط قد تغيرت من جانب shogo82148/actions-setup-redis.
إعجاب واحد (1)
إذا كنت تستخدم صورة أساسية خاصة بنا، فلا يجب عليك إعداد أي Redis، لأنه موجود بالفعل.
أنا دائمًا أحاول فعل كل شيء بطريقتكم. 
أنا أستخدم صورة الأساس والعملية الموصوفة في:
لقد نجحت الأسبوع الماضي. لا يوجد التزام جديد في تلك التدفقات في شهرين. لا أعتقد أن هناك أي شيء يمكنني فعله في المكون الإضافي الخاص بي لكسر هذا بهذه الطريقة المحددة.
ألم يتم تحديث تلك العملية في 15 سبتمبر لإزالة إجراء Redis هذا؟
إعجاب واحد (1)
هذا كل شيء! هل هناك طريقة سهلة وموصى بها لتجنب حدوث ذلك وعدم الظهور بهذا المظهر السخيف؟
إعجاب واحد (1)
لست متأكدًا بصراحة 
الصراع الأبدي بين تلك المشاريع الهيكلية والتحديثات المستمرة شائع جدًا، وبينما يمكن حلها عن طريق بعض تركيب ملفات التكوين في بعض الأماكن، إلا أنك ستحتاج أحيانًا إلى مقارنتها يدويًا.
إنها مشكلة مستمرة في توزيعة لينكس الحالية لدي، لذا أتفهمك.
إعجاب واحد (1)
ها! على الأقل أنا في صحبة جيدة. هذا يساعد كثيرًا.
نعم. استغرق الأمر حوالي 15 دقيقة اليوم لمعرفة كيفية ترقية node.js.
إعجاب واحد (1)
لست على دراية بالعمليات المتعلقة باستخدام هذا المشروع الهيكلي ولكن هل يمكنك الاستفادة من الأسماء المستعارة للصدفة على الإطلاق؟ على سبيل المثال، بدلاً من استخدام docker whizzy things، درب نفسك على استخدام اسم مستعار خاص بك مثل alias dwt="git pull; docker whizzy things"
للأسف لا. قد تتضمن حيلة مجنونة روابط صلبة بين المكون الإضافي الخاص بي والمكون الإضافي الهيكلي وطريقة آلية لسحب أحدث الالتزامات من الهيكل. أخشى أن يكون حل “الانتظار حتى يتعطل وتذكر التحقق من تدفقات عمل GitHub” هو الحل المناسب.
شكرا.
إذا كنت أفسر الأمر بشكل صحيح، أعتقد أن لديك نسخة من المشروع الهيكلي (مع استبدال كل الأشياء المهمة بسحر المكون الإضافي الخاص بك) والمشكلة هي أن ملفات سير العمل في تلك النسخة تصبح قديمة.
هل يمكنك إضافة المستودع الهيكلي كوحدة فرعية ثم استبدال ملفات سير العمل في المستودع الخاص بك بروابط رمزية في الوحدة الفرعية؟ سيؤدي تعيين git config submodule.recurse true إلى تحديث الوحدة الفرعية عند إجراء سحب.
لا أعتقد أن نهج الرابط الرمزي كان سيعمل بناءً على العثور على بعض الأشخاص يناقشون مؤخرًا سبب عدم نجاحه. لقد قدمت طلب سحب يجب أن يتعامل مع هذا من خلال الاستفادة من سير العمل القابل لإعادة الاستخدام.
لا. بالتأكيد لا، لكنني اعتقدت (وأعتقد؟) أن الروابط الصلبة ستعمل.
نعم. أعتقد أن حل الرابط الصلب قد ينجح. أعتقد أنه يمكنني إنشاء رابط صلب من المستودع الهيكلي إلى المستودعات الأخرى ثم أقوم بتنفيذ git pull على الهيكل ثم سيتم تحديث جميع الملفات المرتبطة بها بالإصدار الجديد، ولا أعتقد أن git سيلاحظ أن ملفات متعددة مرتبطة هناك.
والآن هناك فكرة جديدة لا أفهمها تمامًا… [تعديل] ولكنني أفهمها تقريبًا الآن. . .
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.