Java-buildpack: ادفع باستخدام Java Buildpack Failing

nebhale - ربما كان هذا نتيجة الالتزامات الأخيرة التي قمت بها؟

لدي نفس المشكلة:

Java Buildpack 9c46802 | https://github.com/cloudfoundry/java-buildpack.git#9c46802
No start command specified by buildpack or via Procfile.
App will not start unless a command is provided at runtime.

لقد جربت الإصدار 4.16.1 ونجح.

ربما اسم علامة release يشير دائمًا إلى أحدث علامة تم إصدارها؟

تم الحل بواسطة af2e9b6

شكرا على الرد السريعnebhale!

لا أقصد أن أكون وقحًا ، ولكن هذه هي المرة الثانية في اليومين الماضيين التي يكسر فيها الدفع لإتقان نشرنا. هل هناك عملية أفضل لهذا؟ يقوم فريقنا حاليًا بتحديد https://github.com/cloudfoundry/java-buildpack.git buildpack مباشرة في خط الأنابيب لدينا ، وهو ما يؤدي بوضوح إلى حدوث مشكلات. الخيار الآخر الذي يمكنني العثور عليه هو تحديد علامة مثل https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 ، ولكن بعد ذلك تقع مسؤولية إدارة الإصدار لجميع مشاريعنا وخطوط الأنابيب على عاتق فريقي. أعتقد أن corneil لديه الحل الأفضل ، من خلال تحديد علامة release يمكن أن تشير إلى أحدث إصدار مستقر. ما رأيك؟

لطالما كان master فرعًا نشطًا للتطوير ، وقد تم كسره عدة مرات في الماضي. اعتمادًا على ذلك في حالة الإنتاج ، لم يتم تشجيعه مطلقًا ولا نتخذ أي احتياطات للحفاظ على استقراره. يعد استخدام العلامات القابلة للتغيير مثل علامة release مضادًا للنمط لأنه يكسر قابلية إعادة إنتاج البناء (فشل آخر في استخدام master ). نظرًا لأن الاستخدام الأساسي لحزم buildpack في Cloud Foundry هو مع الإصدارات الثابتة التي تستخدم cf create-buildpack/update-buildpack ، ليس لدينا أي نية لإنشاء أي شيء يتجاوز الاستراتيجية الحالية للإصدارات المستقرة ذات العلامات.

مشروعنا موجود في IBM Bluemix و java buildpack الافتراضي هو WebSphere Liberty Profile ، لذلك علينا تحديد حزمة البناء بشكل صريح.

ماذا سيكون اقتراح للمطورين للحفاظ على قوائمهم أو نصوص النشر؟

• استخدم https://github.com/cloudfoundry/java-buildpack.git وأتمنى الأفضل؟
• استخدم https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 وتحدد بطريقة ما متى تستخدم إصدارًا جديدًا؟

أود أن أقترح أن #release أو #v4.x يوفر مقايضة آمنة بأقل تأثير على المجتمع.
إذا كنت تريد التكاثر ، فاستخدم إصدارًا صريحًا مثل #v4.16.1

من الواضح أن هناك حاجة لإجراء تغييرات على عملية الإصدار لدعم ذلك.

أنا أتفق معcorneil. تتمثل عملية تفكيري في أن المستهلكين الذين يتوقعون إمكانية التكاثر في عمليات الإنشاء يضطرون بالفعل إلى تحديد علامة مباشرة. سيؤدي عرض علامة release إلى إضافة المرونة ، مما يمنح الفرق الراغبة في التضحية بإمكانية التكرار من أجل الاستقرار خيار القيام بذلك.