जेनकिन्स शेयर नौकरियों में बिल्ड नंबर?

Question

वर्तमान में हम विकास के कई समांतर धाराओं के साथ एक ऐप विकसित कर रहे हैं। प्रत्येक स्ट्रीम/रिलीज बनाने के लिए हमारे पास जेनकिन्स नौकरी है। तो जॉब-ए रिलीज 1.1 का निर्माण कर सकता है, और जॉब-बी रिलीज 1.2 हो सकता है।

मुझे लगता है कि प्रत्येक रिलीज में बिल्ड नंबर साझा करना सबसे अच्छा होगा, जैसे कि यदि जॉब-ए बिल्ड संख्या 125 के साथ चलता है, तो जॉब-बी अगले नंबर पर चलता है तो यह बिल्ड नंबर 126 के साथ चलाएगा। कारण मुझे लगता है यह सबसे अच्छी रणनीति है कि यह एक एंड्रॉइड ऐप है, जिसके लिए इसे Google Play पर सबमिट किए जाने पर प्रत्येक संस्करण कोड पैरामीटर को बढ़ाया जाना आवश्यक है। हम संस्करण कोड मूल्य के लिए जेनकींस बिल्ड नंबर का उपयोग करते हैं।

क्या कई नौकरियों में बिल्ड नंबर साझा करने के लिए जेनकींस को कॉन्फ़िगर करने का कोई तरीका है? या, क्या कोई इस समस्या के बेहतर समाधान के साथ आया है?

Answer 1

@coffeebreaks एक महान प्रतिक्रिया प्रदान की है, लेकिन हम उस नौकरियों एक बिल्ड नंबर साझा करने की अनुमति के लिए एक कस्टम प्लगइन लिखने के समाप्त हो गया है, तो काम के नाम एक मिलान उपसर्ग था।

Answer 2

चाहे आपने युक्त काम करने के लिए कई parameterised नौकरियों जोड़ सकते हैं जहां multijob प्लगइन पर दिखाई दे सकता है

https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin

तुम भी विरूपण साक्ष्य Archive the artifacts in hudson/jenkins संग्रह में दिखाई दे सकता है और उसके बाद फ़ाइलों

Answer 3

लेने बाद में

संक्षिप्त उत्तर टाइमस्टैम्प का उपयोग करें या मैन्युअल रूप से संस्करण कोड सेट करें, आवश्यक होने पर चीजों को सीआई सर्वर से बाहर रखें। या जेनकिंस बिल्ड संख्याओं को मजबूर करें।

लंबे उत्तर मुझे जेनकिंस को कुछ भी स्वचालित करने के लिए जिम्मेदार होना पसंद है जो स्वयं भी काम करता है। तो अगर मुझे सेटअप के लिए जेनकींस की ज़रूरत नहीं है, तो मैं भी खुश हूं।

यदि आप 2 शाखाओं का उपयोग करते हैं, तो आप शायद उन्हें यादृच्छिक आदेश में प्रतिबद्ध करते हैं। कुछ तरीकों से नौकरियों को एक साथ बांधने की कोशिश करना एक अनावश्यक परेशानी जैसा लगता है जो बाद में एक समस्या हो सकती है। जैसे क्या होगा यदि संस्करण 2.0 बनाया गया है और अब QAed है, बस अपनी नौकरी पूरी करने के लिए उचित रिलीज दिनांक और मार्केटिंग टीम की प्रतीक्षा कर रहा है, लेकिन इसके बाद आपको v1.1.1 त्वरित फिक्स जारी करने की आवश्यकता है? आपके द्वारा चुने गए समाधान के आधार पर, आपको वर्जनकोड टक्कर को मजबूर करने के लिए कुछ पुनर्निर्माणों को ट्रिगर करने की आवश्यकता हो सकती है। नया निर्माण, नया क्यूए?

संस्करण कोड के लिए आपकी वास्तविक आवश्यकता पिछले रिलीज की तुलना में अधिक होने के लिए है।

http://developer.android.com/guide/topics/manifest/manifest-element.html से

एंड्रॉयड: versionCode एक आंतरिक संस्करण संख्या।

यह संख्या प्रयोग किया जाता है केवल निर्धारित करने के लिए एक संस्करण अन्य की तुलना में अधिक हाल ही में है या नहीं, अधिक संख्या के नवीनतम संस्करण का संकेत है। यह उपयोगकर्ताओं को दिखाए गए संस्करण संख्या नहीं है; वह संख्या संस्करण नाम विशेषता द्वारा निर्धारित की गई है। मान को पूर्णांक के रूप में सेट किया जाना चाहिए, जैसे कि "100"। आप इसे परिभाषित कर सकते हैं, हालांकि आप चाहते हैं, जब तक प्रत्येक क्रमिक संस्करण में उच्च संख्या हो। उदाहरण के लिए, यह एक बिल्ड नंबर हो सकता है। या आप 0 xएन्कोडिंग "x" और "y" एन्कोडिंग द्वारा निचले और ऊपरी 16 बिट्स में एक पूर्णांक में "x.y" प्रारूप में एक संस्करण संख्या का अनुवाद कर सकते हैं। या आप प्रत्येक बार एक नया संस्करण जारी किए गए नंबर को आसानी से बढ़ा सकते हैं।

• मैनुअल bumping:

तो यहाँ 2 समाधान कर रहे हैं। हमारी परियोजनाओं में, मैं रिलीज से पहले बिल्ड नंबर के बंपिंग को स्वचालित करने के लिए कुछ sed स्क्रिप्ट का उपयोग करता हूं। जैसा कि मुझे कुछ चीजों को हाथ से बदलना होगा, जैसे वर्जननाम प्रीफिक्स, विकास के दौरान डीबगिंग मोड अक्षम/सक्षम करें, मैं मैन्युअल रूप से एक बंपवर्जन स्क्रिप्ट चलाता हूं ताकि मेरी शाखा में अगले निर्माण में उचित संस्करण और संस्करण कोड संख्या हो। नोट मैं इसके बजाय संस्करण नाम में जेनकींस बिल्ड नंबर का उपयोग करता हूं। यदि आप v2 के लिए पर्याप्त पर्याप्त संस्करण कोड बंप चुनते हैं तो यह समाधान आपको V.1 तैयार होने की समस्या के बाद 1.1.1 की आवश्यकता होने से रोकता है।

एक और अधिक स्वचालित अभी तक सरल समाधान टाइमस्टैम्प से कुछ का उपयोग करना होगा। प्रारूप YYMMDDHHSS एक पूर्णांक (< 2^31) के लिए पर्याप्त है, और संभावना है कि जो भी संस्करण आप अगले रिलीज करने जा रहे हैं वह पिछले एक के बाद तैयार किया जा रहा है और उसी मिनट के भीतर नहीं। तो मूल रूप से जब आप v1.1 बनाते हैं, तो यह उदा। 1308131600 और यदि आप v1.2 मिनट का निर्माण के बाद यह 1308131601. हो जाता है (यह स्पष्ट रूप से v1.1.1/वी 2 परिदृश्य के खिलाफ आप मदद नहीं करता है)

यहाँ लिपियों/अद्यतन versionCode उत्पन्न करने के लिए के लिए कुछ विचार कर रहे Auto increment version code in Android app।

जेनकींस रास्ता

अब अगर आप अभी भी शुल्क में जेनकींस चाहते हैं, एक सरल उपाय https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin की तरह कुछ का उपयोग करें और अपने प्रति शाखा नौकरियों कॉन्फ़िगर कोई टकराव सुनिश्चित करने के लिए एक बहुत बड़ी उपसर्ग के लिए है। सेटअप अभी भी बहुत आसान है।

उदा।

• शाखा 1.1
• 120000 के लिए शाखा के लिए 110000 1,2

Answer 4

मैंने इसे आजमाया नहीं है, लेकिन मैं बिल्ड मशीन पर जाने के बारे में सोच रहा हूं और nextBuildNumber फ़ाइल को प्रतिस्थापित करने के बारे में सोच रहा हूं, एक सिमलिंक के साथ कहीं भी एक फ़ाइल में। क्या गलत होने की सम्भावना है। खैर, समवर्ती पहुंच एक मुद्दा हो सकता है। यदि कोई समस्या सामान्य रूप से इसे खोलने के बजाए, जेनकिंस फ़ाइल को स्क्रैच से फिर से बनाता है, यानी निकालने और बनाने के साथ, तो कोई समस्या हो सकती है।