"أدوات Firebase": "4.1.1"
OS X و Bitbucket Pipelines CI
في Bitbucket pipelines CI ، باستخدام الوضع غير التفاعلي مع المتغيرات env
firebase use myproject
firebase deploy
مع 5 وظائف في index.js
_ في وقت لاحق PR_
firebase deploy
مع 4 وظائف فقط في index.js
Error: The following functions are found in your project but do not exist in your local source code:
... قائمة الوظائف ...
Aborting because deletion cannot proceed in non-interactive mode. To fix, manually delete the functions by running:
مرحبًا ، هذا سلوك متعمد ، نظرًا لتلقينا الكثير من التعليقات التي تفيد بأن المستخدمين لم يعجبهم كيفية حذف CLI لوظائفهم تلقائيًا. لذا نطلب الآن تأكيد المستخدم لعمليات الحذف ، وهو أمر لا يمكن إجراؤه بطريقة غير تفاعلية.
هذا هو السبب في أن الإصدار كان بمثابة نتوء رئيسي للإصدار ، للإشارة إلى تغيير جذري في السلوك.
هل يمكن إضافة علامة
هل يمكنك التوسع في تفسيرك المنطقي أكثر قليلاً؟ هل تقوم بحذف الوظائف كثيرًا أثناء CI؟
بالتأكيد: نعمل باستمرار على إعادة بناء الوظائف القديمة وغالبًا ما نستبدل (مبادلة https onRequest بـ onCall على سبيل المثال). يسهل علينا حذف الوظيفة القديمة وإضافة وظيفة جديدة. في بعض الأحيان ، لم نعد نستخدم الوظيفة بعد الآن ، ونريدها أن تختفي.
لن نحذف وظيفة كل أسبوع ، ولكن الآن بعد أن أصبح من غير الممكن القيام بذلك عبر CI ، فهذا يعني أنه يتعين علينا إضافة خطوة يدوية للمراجعة للحذف يدويًا قبل الدمج والنشر التلقائي. وهذا يعني أيضًا أن اثنين من المطورين على الأقل يحتاجان إلى الوصول للكتابة إلى وظائف الإنتاج لدينا ، والتي نحاول الابتعاد عنها لراحة البال.
إذا كان لدينا شيء مثل firebase deploy --allow-deletes
وحافظنا على عملية مراجعة جيدة ، يمكن لفريق التطوير بأكمله إنشاء / تحديث / حذف أي شيء بحرية دون انتظار فتح CLI للإنتاج على الكمبيوتر المحمول الخاص بي أثناء عملي على شيء ما آخر.
يمكنني أن أفهم سبب عدم الحذف الافتراضي ، لكننا مندهشون من أنه غير ممكن / محظور في الوضع غير التفاعلي ، على افتراض أن معظم الأشخاص في هذا الوضع يراجعون بدقة قبل النشر كما نحن؟
شكرًا على تعليقات آلان ، سأفتح المناقشة داخليًا حول هذا الموضوع.
شكرا لورين 🙌
لدينا نفس المشكلة بالضبط. من شأنه أن يساعد كثيرًا أيضًا. اضطررنا للتخلي عن عمليات النشر الآلية باستخدام Google Cloud Builder بسبب التحديث.
لست متأكدًا مما إذا كان أي شخص قد اقترحه بالفعل.
يبدو أن معظم المستخدمين يفضلون العلم حيث سيتم حذف الوظائف غير الموجودة.
هذا ليس دائمًا الخيار الذي يريده الجميع.
على سبيل المثال ، نود أن يكون لدينا علم ، والذي يسمح لنا فقط بتجاهل هذه الوظائف.
لذلك لن يتم تحديث الوظائف أو يتم حذفها.
على سبيل المثال ، إذا قام شخص ما بإنشاء وظيفة جديدة في فرع الميزة ونشرها باستخدام firebase deploy --only functions:functionName
لأغراض الاختبار.
لن يؤثر هذا على أي وظيفة أخرى في استخدام الإنتاج.
ثم يحاول شخص ما نشر إصدار جديد ، ثم يبدأ خط أنابيب CI الخاص بنا ويستدعي الأمر
firebase deploy --ignore-missing-functions
، عندها ستعمل عملية النشر على تحديث جميع الوظائف الحالية ، وإنشاء وظائف مفقودة ، ولكن لن يتم تحديث أو حذف الوظيفة functionName
.
أرى فائدة العلم لاستعادة السلوك القديم ، لذلك سيكون من الرائع الحصول على كلا السلوكين في رأيي.
إما حذف الوظائف المفقودة أو تجاهلها فقط.
كذلك هنا. نظرًا لأن لدينا الكثير من المشغلات وغالبًا ما نحتاج إلى نقل قاعدة بيانات المستخدم من مشروع prod إلى dev للتحقيق واستكشاف الأخطاء وإصلاحها ، فنحن بحاجة إلى طريقة لتعطيل جميع المشغلات أثناء استيراد json.
والطريقة الوحيدة لتعطيل المشغلات التي توصلنا إليها هي حذف جميع الوظائف في مشروع dev قبل الاستيراد - قم حرفيًا بالتعليق على جميع index.js ، ونشره في dev ، ثم استيراد json ثم إعادة جميع الوظائف مرة أخرى لـ مزيد من التحقيق في أي قضايا تم الإبلاغ عنها.
إذا كانت هناك طريقة لتعطيل المشغلات بطريقة أكثر ودية مع CLI المحدث ، فسأكون ممتنًا لأي مدخلات حول كيفية تحقيق ذلك. وإلا فإن إزالة الوظائف من CLI دفعة واحدة لا يزال أمرًا نعتمد عليه.
@ laurenzlong هل يتم معالجة هذا؟
سنضيف خيارًا لفرض حذف الوظائف المفقودة قريبًا.
لقد سمعنا التعليقات ، ونأمل أن يكون هذا مفيدًا. السلوك الافتراضي سوف
لا يزال كما هو.
في الجمعة ، 12 أكتوبر ، 2018 ، 5:06 صباحًا كتب سليمان إنجل < [email protected] :
@ laurenzlong https://github.com/laurenzlong هل تتم معالجة هذا الأمر؟
-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/877#issuecomment-429303503 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAD_npvEeL-UEG_Q5YNtNylQCi_9hKKks5ukIWtgaJpZM4WCBfg
.
mbleigh هل هناك أي خيار لعدم حذف أي وظيفة عند تشغيل firebase deploy
؟
على سبيل المثال ، إذا كان لدي مستودعين منفصلين بوظائف مختلفة تمامًا والتي يتم نشرها جميعًا في نفس مشروع الوظائف.
لذلك على سبيل المثال:
لدي ريبو
الآن إذا قمت بتشغيل firebase deploy
من الريبو "الأمامي" فأنا أريد تحديث languageRedirector
وإذا قمت بتشغيل firebase deploy
من الريبو "الخلفي" ، فأنا أريد تحديث onUserAuthenticated
هل هذا ممكن؟
IchordeDionysos هذا غير ممكن ، على حد
هل هذا # 999 شيء تفكر فيه؟ :)
نحتاج حقًا إلى هذا الخيار لأن نص CI الخاص بنا لن يعمل حاليًا بدون هذا ...
أنا فقط وضعت ملاحظة على ذلك العلاقات العامة. في حين أنها فكرة جيدة ، إلا أن هناك عملية داخلية أكثر قليلاً يجب أن تحدث لإضافة علامة مثل هذه. لا أتوقع حدوث شيء ما في عدد من الأيام ، لكنني أعلم أنه على رادارنا.
IchordeDionysos في هذه الأثناء ، هل من الممكن أن تستخدم --only functions:[function]
على firebase deploy
لتشغيل CI الخاص بك؟ يمكنك العثور على مزيد من التفاصيل هنا: https://firebase.google.com/docs/cli/#deploy_specific_functions
بالنسبة لنا تم حل المشكلة. نحن قادرون على النشر عبر Google Cloud Builder مرة أخرى.
إليك "الاختراق" الذي نستخدمه فقط لرفع الوظيفة (وليس حذف الآخرين):
echo "n\n" | firebase deploy --only functions --interactive --token $FIREBASE_TOKEN
سأقدر أيضًا وجود خيار واضح مثل --no-delete
بدلاً من الاعتماد على السؤال الذي لا يتغير أبدًا 😏
التعليق الأكثر فائدة
بالتأكيد: نعمل باستمرار على إعادة بناء الوظائف القديمة وغالبًا ما نستبدل (مبادلة https onRequest بـ onCall على سبيل المثال). يسهل علينا حذف الوظيفة القديمة وإضافة وظيفة جديدة. في بعض الأحيان ، لم نعد نستخدم الوظيفة بعد الآن ، ونريدها أن تختفي.
لن نحذف وظيفة كل أسبوع ، ولكن الآن بعد أن أصبح من غير الممكن القيام بذلك عبر CI ، فهذا يعني أنه يتعين علينا إضافة خطوة يدوية للمراجعة للحذف يدويًا قبل الدمج والنشر التلقائي. وهذا يعني أيضًا أن اثنين من المطورين على الأقل يحتاجان إلى الوصول للكتابة إلى وظائف الإنتاج لدينا ، والتي نحاول الابتعاد عنها لراحة البال.
إذا كان لدينا شيء مثل
firebase deploy --allow-deletes
وحافظنا على عملية مراجعة جيدة ، يمكن لفريق التطوير بأكمله إنشاء / تحديث / حذف أي شيء بحرية دون انتظار فتح CLI للإنتاج على الكمبيوتر المحمول الخاص بي أثناء عملي على شيء ما آخر.يمكنني أن أفهم سبب عدم الحذف الافتراضي ، لكننا مندهشون من أنه غير ممكن / محظور في الوضع غير التفاعلي ، على افتراض أن معظم الأشخاص في هذا الوضع يراجعون بدقة قبل النشر كما نحن؟