Java-buildpack: Java Buildpack Failing के साथ पुश करें

को निर्मित 9 जन॰ 2019 · 8टिप्पणियाँ · स्रोत: cloudfoundry/java-buildpack

जावा बिल्डपैक के माध्यम से तैनाती करते समय निम्न त्रुटि प्राप्त करना:

[09:39:01][Step 2/4] [DEBUG] CloudFoundry  _cf_push                            No start command specified by buildpack or via Procfile.
[09:39:01][Step 2/4] [DEBUG] CloudFoundry  _cf_push                            App will not start unless a command is provided at runtime.
[09:39:01][Step 2/4] [DEBUG] CloudFoundry  _cf_push                            Exit status 0

bug

स्रोत

aknobloch

😕1

सबसे उपयोगी टिप्पणी

त्वरित प्रतिक्रिया के लिए धन्यवाद @nebhale!

मेरा मतलब अशिष्ट होना नहीं है, लेकिन पिछले कुछ दिनों में यह दूसरी बार है https://github.com/cloudfoundry/java-buildpack.git बिल्डपैक को सीधे हमारी पाइपलाइन में निर्दिष्ट कर रही है, जो स्पष्ट रूप से मुद्दों की ओर ले जा रहा है। दूसरा विकल्प जो मुझे मिल सकता है वह है https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 जैसे टैग को निर्दिष्ट करना, लेकिन फिर हमारी सभी परियोजनाओं और पाइपलाइनों के लिए संस्करण प्रबंधन की जिम्मेदारी मेरी टीम पर आती है। मेरा मानना है कि release टैग निर्दिष्ट करके @corneil के पास सबसे अच्छा समाधान है जो नवीनतम स्थिर रिलीज को इंगित कर सकता है। आपके क्या विचार हैं?

aknobloch 9 जन॰ 2019

👍2

सभी 8 टिप्पणियाँ

@nebhale - शायद यह आपके द्वारा किए गए हालिया

aknobloch 9 जन॰ 2019

मेरे पास एक ही मुद्दा था:

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.

मैंने v4.16.1 की कोशिश की और यह काम कर गया।

corneil 9 जन॰ 2019

शायद एक टैग नाम release जो हमेशा नवीनतम संस्करण वाले टैग को इंगित करता है?

corneil 9 जन॰ 2019

👍2

af2e9b6 . द्वारा हल किया गया

nebhale 9 जन॰ 2019

त्वरित प्रतिक्रिया के लिए धन्यवाद @nebhale!

aknobloch 9 जन॰ 2019

👍2

master हमेशा एक सक्रिय विकास शाखा रही है, और अतीत में कई बार टूट चुकी है। इसके आधार पर उत्पादन की स्थिति में कभी भी प्रोत्साहित नहीं किया गया है और हम इसे स्थिर रखने के लिए कोई सावधानी नहीं बरतते हैं। release टैग जैसे परिवर्तनशील टैग का उपयोग एक विरोधी पैटर्न है क्योंकि यह निर्माण प्रतिलिपि प्रस्तुत करने योग्यता को तोड़ता है ( master का उपयोग करने में एक और विफलता)। यह देखते हुए कि क्लाउड फाउंड्री में बिल्डपैक का प्राथमिक उपयोग cf create-buildpack/update-buildpack का उपयोग करते हुए निश्चित रिलीज़ संस्करणों के साथ है, टैग की गई स्थिर रिलीज़ की मौजूदा रणनीति से परे कुछ भी बनाने का हमारा कोई इरादा नहीं है।

nebhale 9 जन॰ 2019

हमारी परियोजना आईबीएम ब्लूमिक्स में है और डिफ़ॉल्ट जावा बिल्डपैक वेबस्फेयर लिबर्टी प्रोफाइल है, इसलिए हमें बिल्ड पैक को स्पष्ट रूप से निर्दिष्ट करना होगा।

डेवलपर्स के लिए अपने मैनिफेस्ट या परिनियोजन स्क्रिप्ट को बनाए रखने के लिए क्या सुझाव होगा?

https://github.com/cloudfoundry/java-buildpack.git उपयोग करें और सर्वश्रेष्ठ की आशा करें?
https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 उपयोग करें और किसी तरह निर्धारित करें कि आप एक नए संस्करण का उपयोग कब करते हैं?

मेरा सुझाव है कि #release या #v4.x समुदाय पर सबसे कम प्रभाव के साथ एक सुरक्षित व्यापार-बंद प्रदान करता है।
यदि आप प्रतिलिपि प्रस्तुत करने योग्यता चाहते हैं तो #v4.16.1 जैसे स्पष्ट संस्करण का उपयोग करें

जाहिर है, इसका समर्थन करने के लिए रिलीज प्रक्रिया में बदलाव की जरूरत है।

corneil 10 जन॰ 2019

मैं @corneil से सहमत हूं। मेरी विचार प्रक्रिया यह है कि उपभोक्ता जो निर्माण प्रक्रियाओं में पुनरुत्पादन की उम्मीद कर रहे हैं, उन्हें पहले से ही एक टैग निर्दिष्ट करना होगा। एक release टैग को उजागर करने से लचीलापन जुड़ जाएगा, जो टीमों को स्थिरता के लिए प्रतिलिपि प्रस्तुत करने योग्यता का त्याग करने के लिए ऐसा करने का विकल्प देगा।

aknobloch 10 जन॰ 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Java-buildpack: Java Buildpack Failing के साथ पुश करें

सबसे उपयोगी टिप्पणी

सभी 8 टिप्पणियाँ

संबंधित मुद्दों