🤾🏻 🤘🏾 🌪️ बिल्डबॉट: एक अन्य सतत एकीकरण प्रणाली के उदाहरणों के साथ एक कहानी 🕺🏽 ⏱️ 😜

( आधिकारिक साइट से तस्वीर)

बिल्डबोट, जैसा कि नाम से पता चलता है, एक निरंतर एकीकरण प्रणाली (सीआई) है। होबे पर उनके बारे में पहले से ही कई लेख थे, लेकिन, मेरे दृष्टिकोण से, इस उपकरण के फायदे उनसे बहुत स्पष्ट नहीं हैं। इसके अलावा, उनके पास लगभग कोई उदाहरण नहीं है, जिससे कार्यक्रम की पूरी शक्ति को देखना मुश्किल हो जाता है। अपने लेख में, मैं इन कमियों के लिए बनाने की कोशिश करूंगा, बिल्डबोट की आंतरिक संरचना के बारे में बात करूंगा, और कई गैर-मानक स्क्रिप्ट का उदाहरण दूंगा।

आम शब्द

वर्तमान में, बड़ी संख्या में निरंतर एकीकरण प्रणालियां हैं, और जब उनमें से एक की बात आती है, तो "पहले से ही एक <program_name>" होने पर और "इसका उपयोग करने की आवश्यकता क्यों है" की भावना में काफी तार्किक प्रश्न उठते हैं? मैं बिल्डबॉट के बारे में इस तरह के सवाल का जवाब देने की कोशिश करूंगा। कुछ जानकारी को मौजूदा लेखों के साथ दोहराया जाएगा, कुछ को आधिकारिक प्रलेखन में वर्णित किया गया है, लेकिन यह कथा की स्थिरता के लिए आवश्यक है।

निरंतर एकीकरण की अन्य प्रणालियों से मुख्य अंतर यह है कि बिल्डबोट ci लिखने के लिए एक पायथन फ्रेमवर्क है, और बॉक्स से कोई समाधान नहीं है। इसका मतलब यह है कि एक प्रोजेक्ट को बिल्डबोट से कनेक्ट करने के लिए, आपको पहले बिल्डबॉट फ्रेमवर्क का उपयोग करके एक अलग अजगर प्रोग्राम लिखना होगा जो आपके प्रोजेक्ट की निरंतरता की निरंतरता कार्यक्षमता को लागू करता है। यह दृष्टिकोण जबरदस्त लचीलापन प्रदान करता है, जिससे आपको ट्रिकी परीक्षण परिदृश्यों को लागू करने की अनुमति मिलती है जो वास्तु सीमाओं के कारण आउट-ऑफ-बॉक्स समाधान के लिए असंभव हैं।

इसके अलावा, बिल्डबोट एक सेवा नहीं है, और इसलिए आपको इसे अपने बुनियादी ढांचे पर ईमानदारी से तैनात करना चाहिए। यहां मैंने ध्यान दिया कि फ्रेमवर्क सिस्टम के संसाधनों के लिए बहुत वफादार है। यह निश्चित रूप से C या C ++ नहीं है, लेकिन अजगर अपने जावा प्रतियोगियों के खिलाफ जीतता है। उदाहरण के लिए, GoCD के साथ मेमोरी खपत की तुलना (और हाँ, नाम के बावजूद, यह एक जावा सिस्टम है):

buildbot:

GoCD:

एक अलग परीक्षा कार्यक्रम की तैनाती और लेखन खुद आपको शुरुआती सेटअप के विचार से दुखी कर सकता है। हालांकि, अंतर्निहित कक्षाओं की सरासर संख्या से स्क्रिप्टिंग बहुत सरल है। ये कक्षाएं कई मानक संचालन को कवर करती हैं, चाहे इसे गिटब रिपॉजिटरी से बदलाव मिल रहा हो या सीएमके के साथ प्रोजेक्ट का निर्माण करना। नतीजतन, कुछ ट्रैविस-सीआई के लिए वाईएमएल फ़ाइलों की तुलना में छोटी परियोजनाओं के लिए मानक स्क्रिप्ट अधिक जटिल नहीं होंगे। मैं तैनाती के बारे में नहीं लिखूंगा, यह मौजूदा लेखों में विस्तार से कवर किया गया है और वहां कुछ भी जटिल नहीं है।

बिल्डबॉट की अगली विशेषता, मैं ध्यान देता हूं कि डिफ़ॉल्ट रूप से परीक्षण तर्क को ci-server के पक्ष में लागू किया जाता है। यह अब "लोकप्रिय एक कोड के रूप में पाइपलाइन" दृष्टिकोण के लिए काउंटर चलाता है, जिसमें परीक्षण तर्क को एक फ़ाइल में वर्णित किया गया है (जैसे .travis.yml) परियोजना स्रोत कोड के साथ रिपॉजिटरी में पड़ा हुआ है, और ci सर्वर केवल इस फ़ाइल को पढ़ता है और निष्पादित करता है। यह क्या कहता है। फिर, यह केवल डिफ़ॉल्ट व्यवहार है। बिल्डबॉट फ्रेमवर्क की क्षमताएं आपको रिपॉजिटरी में परीक्षण स्क्रिप्ट को संग्रहीत करने के साथ वर्णित दृष्टिकोण को लागू करने की अनुमति देती हैं। यहां तक कि एक रेडी-मेड समाधान भी है - bb-travis , जो बिल्डबॉट और ट्रैविस-सीआई से सर्वश्रेष्ठ लेने की कोशिश करता है। इसके अलावा, बाद में इस लेख में मैं वर्णन करूंगा कि इस व्यवहार के समान कुछ को कैसे लागू किया जाए।

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

फ्रेमवर्क में एक काफी अच्छा दस्तावेज है, जो सामान्य वास्तुकला से लेकर अंतर्निहित कक्षाओं के विस्तार के लिए दिशानिर्देशों तक सब कुछ विस्तार से बताता है। हालांकि, इस तरह के प्रलेखन के साथ, आपको स्रोत कोड में कुछ चीजों को देखना पड़ सकता है। यह GPL v2 लाइसेंस के तहत पूरी तरह से खुला है और पढ़ने में आसान है। Minuses की - प्रलेखन केवल अंग्रेजी में उपलब्ध है, रूसी में नेटवर्क पर बहुत कम जानकारी है। उपकरण कल दिखाई नहीं दिया, इसकी मदद से अजगर , विंडशार्क , एलएलवीएम और कई अन्य प्रसिद्ध परियोजनाएं इकट्ठी की जाती हैं। अपडेट सामने आ रहे हैं, परियोजना कई डेवलपर्स द्वारा समर्थित है, इसलिए हम विश्वसनीयता और स्थायित्व के बारे में बात कर सकते हैं।

(पायथन बिल्डबोट होमपेज)

Teormin

यह हिस्सा अनिवार्य रूप से ढांचे के वास्तुकला पर आधिकारिक प्रलेखन के अध्याय का एक मुफ्त अनुवाद है। यह उपयोगकर्ताओं को परिणाम की सूचना भेजने के लिए ci-system द्वारा परिवर्तन प्राप्त करने से लेकर कार्यों की पूरी श्रृंखला दिखाता है। इसलिए, आपने परियोजना के स्रोत कोड में परिवर्तन किए और उन्हें दूरस्थ भंडार में भेज दिया। आगे क्या होता है यह योजनाबद्ध रूप से चित्र में दिखाया गया है:

( आधिकारिक दस्तावेज से तस्वीर)

सबसे पहले, बिल्डबोट को किसी तरह यह पता लगाना चाहिए कि रिपॉजिटरी में बदलाव हुए हैं। वहाँ दो मुख्य तरीके हैं - webhooks और मतदान, हालांकि कोई भी अधिक परिष्कृत कुछ के साथ आने से मना करता है। पहले मामले में, बिल्डबॉट में, बेसहुकहैंडलर वंशज वर्ग इसके लिए जिम्मेदार हैं। कई तैयार समाधान हैं, उदाहरण के लिए, GitHubHandler या GitoriusHandler । इन वर्गों में मुख्य विधि getChanges () है । इसका तर्क अत्यंत सरल है: इसे HTTP अनुरोध को परिवर्तनशील वस्तुओं की सूची में बदलना चाहिए।

दूसरे मामले के लिए, आपको पोलिंगक्रॉससोर्स अवरोही वर्गों की आवश्यकता है। फिर से, तैयार किए गए समाधान हैं, जैसे कि GitPoller या HgPoller । प्रमुख विधि पोल () है । यह एक निश्चित आवृत्ति के साथ कहा जाता है और किसी तरह भंडार में बदलाव की एक सूची बनाना चाहिए। गिट के मामले में, यह भ्रूण लाने के लिए कॉल हो सकता है और पिछले सहेजे गए राज्य के साथ तुलना कर सकता है। यदि अंतर्निहित क्षमताएं पर्याप्त नहीं हैं, तो बस अपने स्वयं के उत्तराधिकारी वर्ग बनाएं और विधि को अधिभारित करें। मतदान का उपयोग करने का एक उदाहरण:

c['change_source'] = [changes.GitPoller( repourl = 'git@git.example.com:project', project = 'My Project', branches = True, #      pollInterval = 60 )]

Webhook का उपयोग करना और भी आसान है, मुख्य बात यह नहीं है कि इसे git-server पक्ष पर कॉन्फ़िगर करना भूल जाए। कॉन्फ़िगरेशन फ़ाइल में यह केवल एक पंक्ति है:

 c['www']['change_hook_dialects'] = { 'github': {} }

अगला चरण, परिवर्तन ऑब्जेक्ट शेड्यूलर ऑब्जेक्ट्स ( शेड्यूलर्स ) पर इनपुट हैं। अंतर्निहित अनुसूचियों के उदाहरण: AnyBranchScheduler , NightlyScheduler , ForceScheduler , आदि। प्रत्येक अनुसूचक इनपुट के रूप में सभी परिवर्तन वस्तुओं को प्राप्त करता है, लेकिन केवल उन का चयन करता है जो फ़िल्टर पास करते हैं। फ़िल्टर को change_filter तर्क के माध्यम से निर्माता में शेड्यूलर को दिया जाता है। आउटपुट पर, नियोजक बिल्ड अनुरोध बनाते हैं। अनुसूचक बिल्डरों के तर्क के आधार पर बिल्डरों का चयन करता है।

कुछ योजनाकारों के पास एक मुश्किल तर्क है, जिसे ट्रीस्टेबलटेमर कहा जाता है। यह निम्नानुसार काम करता है: जब कोई परिवर्तन प्राप्त होता है, तो शेड्यूलर तुरंत एक नया बिल्ड अनुरोध नहीं बनाता है, लेकिन एक टाइमर शुरू करता है। यदि नए परिवर्तन आते हैं और टाइमर की समय सीमा समाप्त नहीं हुई है, तो पुराने परिवर्तन को एक नए से बदल दिया जाता है, और टाइमर को अपडेट किया जाता है। जब टाइमर समाप्त हो जाता है, तो शेड्यूलर अंतिम सहेजे गए परिवर्तन से केवल एक बिल्ड अनुरोध बनाता है।

इस प्रकार, जब धक्का दिया जाता है तो केवल अंतिम प्रतिबद्ध को इकट्ठा करने का तर्क। शेड्यूलर कॉन्फ़िगरेशन उदाहरण:

 c['schedulers'] = [schedulers.AnyBranchScheduler( name = 'My Scheduler', treeStableTimer = None, change_filter = util.ChangeFilter(project = 'My Project'), builderNames = ['My Builder'] )]

बिल्ड अनुरोध, हालांकि अजीब लग सकता है, बिल्डरों के इनपुट पर जाएं। कलेक्टर का कार्य एक सुलभ "कार्यकर्ता" पर विधानसभा को चलाना है। वर्कर एक निर्माण परिवेश है, जैसे कि खिंचाव 64 या ubuntu1804x64। श्रमिकों की सूची को श्रमिक तर्क के माध्यम से पारित किया जाता है। सूची में सभी श्रमिकों को समान होना चाहिए (यानी नाम स्वाभाविक रूप से अलग हैं, लेकिन अंदर का वातावरण समान है), क्योंकि कलेक्टर किसी भी उपलब्ध को चुनने के लिए स्वतंत्र है। यहां कई मान सेट करना लोड को संतुलित करने का काम करता है, न कि अलग-अलग वातावरण में निर्माण करने का। कारक y तर्क का उपयोग करते हुए, कलेक्टर को परियोजना के निर्माण के लिए चरणों का अनुक्रम प्राप्त होता है। मैं इस बारे में नीचे विस्तार से लिखूंगा।

कलेक्टर को कॉन्फ़िगर करने का एक उदाहरण:

 c['builders'] = [util.BuilderConfig( name = 'My Builder', workernames = ['stretch32'], factory = factory )]

तो, परियोजना तैयार है। बिल्डबॉट का अंतिम चरण बिल्ड को सूचित करना है। इसके लिए रिपोर्टर वर्ग जिम्मेदार हैं। एक क्लासिक उदाहरण MailNotifier class है, जो बिल्ड परिणामों के साथ एक ईमेल भेजता है। MailNotifier कनेक्शन उदाहरण :

 c['services'] = [reporters.MailNotifier( fromaddr = 'buildbot@example.com', relayhost = 'mail.example.com', smtpPort = 25, extraRecipients = ['devel@example.com'], sendToInterestedUsers = False )]

खैर, यह समय है कि पूर्ण विकसित उदाहरणों पर आगे बढ़ें। मैं ध्यान देता हूं कि बिल्डबॉट खुद ट्विस्टेड फ्रेमवर्क का उपयोग करके लिखा गया था, और इसलिए इसके साथ परिचित होने से बिल्डबॉट स्क्रिप्ट के लेखन और समझ में बहुत सुविधा होगी। हमारे पास पेट प्रोजेक्ट नामक प्रोजेक्ट के लिए एक सचेतक लड़का होगा। इसे सी ++ में लिखा जाए, सीएमके का उपयोग करके इकट्ठा किया जाए, और स्रोत कोड गिट रिपॉजिटरी में निहित है। हम बहुत आलसी नहीं थे और उनके लिए परीक्षण लिखे जो कि ctest टीम द्वारा चलाए जा रहे हैं। हाल ही में, हमने इस लेख को पढ़ा और महसूस किया कि हम अपनी परियोजना के लिए नए सिरे से प्राप्त ज्ञान को लागू करना चाहते हैं।

उदाहरण एक: इसके लिए काम करना है

दरअसल, कॉन्फ़िगरेशन फ़ाइल:

अजगर कोड की 100 लाइनें

 from buildbot.plugins import * # shortcut c = BuildmasterConfig = {} # create workers c['workers'] = [worker.Worker('stretch32', 'example_password')] # general settings c['title'] = 'Buildbot: test' c['titleURL'] = 'https://buildbot.example.com/' c['buildbotURL'] = 'https://buildbot.example.com/' # setup database c['db'] = { 'db_url': 'sqlite:///state.sqlite' } # port to communicate with workers c['protocols'] = { 'pb': { 'port': 9989 } } # make buildbot developers a little bit happier c['buildbotNetUsageData'] = 'basic' # webserver setup c['www'] = dict(plugins = dict(waterfall_view={}, console_view={}, grid_view={})) c['www']['authz'] = util.Authz( allowRules = [util.AnyEndpointMatcher(role = 'admins')], roleMatchers = [util.RolesFromUsername(roles = ['admins'], usernames = ['root'])] ) c['www']['auth'] = util.UserPasswordAuth([('root', 'root_password')]) # mail notification c['services'] = [reporters.MailNotifier( fromaddr = 'buildbot@example.com', relayhost = 'mail.example.com', smtpPort = 25, extraRecipients = ['devel@example.com'], sendToInterestedUsers = False )] c['change_source'] = [changes.GitPoller( repourl = 'git@git.example.com:pet-project', project = 'Pet Project', branches = True, pollInterval = 60 )] c['schedulers'] = [schedulers.AnyBranchScheduler( name = 'Pet Project Scheduler', treeStableTimer = None, change_filter = util.ChangeFilter(project = 'Pet Project'), builderNames = ['Pet Project Builder'] )] factory = util.BuildFactory() factory.addStep(steps.Git( repourl = util.Property('repository'), workdir = 'sources', haltOnFailure = True, submodules = True, progress = True) ) factory.addStep(steps.ShellSequence( name = 'create builddir', haltOnFailure = True, hideStepIf = lambda results, s: results == util.SUCCESS, commands = [ util.ShellArg(command = ['rm', '-rf', 'build']), util.ShellArg(command = ['mkdir', 'build']) ]) ) factory.addStep(steps.CMake( workdir = 'build', path = '../sources', haltOnFailure = True) ) factory.addStep(steps.Compile( name = 'build project', workdir = 'build', haltOnFailure = True, warnOnWarnings = True, command = ['make']) ) factory.addStep(steps.ShellCommand( name = 'run tests', workdir = 'build', haltOnFailure = True, command = ['ctest']) ) c['builders'] = [util.BuilderConfig( name = 'Pet Project Builder', workernames = ['stretch32'], factory = factory )]

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

कारखाने में बिल्ड कदम होते हैं जो बिल्डबोट को परियोजना के लिए पूरा करना चाहिए। अन्य वर्गों के साथ के रूप में, कई तैयार समाधान हैं। हमारे कारखाने पांच चरणों के होते हैं। एक नियम के रूप में, पहला कदम रिपॉजिटरी की वर्तमान स्थिति प्राप्त करना है, और यहां हम अपवाद नहीं बनाएंगे। ऐसा करने के लिए, हम मानक Git वर्ग का उपयोग करते हैं:

पहला कदम

 factory = util.BuildFactory() factory.addStep(steps.Git( repourl = util.Property('repository'), workdir = 'sources', haltOnFailure = True, submodules = True, progress = True) )

अगला, हमें एक निर्देशिका बनाने की आवश्यकता है जिसमें परियोजना को इकट्ठा किया जाएगा - हम एक पूर्ण निर्माण स्रोत बनाएंगे। इससे पहले, आपको निर्देशिका को हटाना याद रखना चाहिए यदि यह पहले से मौजूद है। इस प्रकार, हमें दो कमांड निष्पादित करने की आवश्यकता है। ShellSequence वर्ग हमें इसमें मदद करेगा:

दूसरा कदम

 factory.addStep(steps.ShellSequence( name = 'create builddir', haltOnFailure = True, hideStepIf = lambda results, s: results == util.SUCCESS, commands = [ util.ShellArg(command = ['rm', '-rf', 'build']), util.ShellArg(command = ['mkdir', 'build']) ]) )

अब आपको सीएमके शुरू करने की आवश्यकता है। ऐसा करने के लिए, दो वर्गों में से एक का उपयोग करना तर्कसंगत है - शेलकोमैंड या सीमेक । हम बाद का उपयोग करेंगे, लेकिन अंतर न्यूनतम हैं: यह प्रथम श्रेणी पर एक सरल आवरण है , जो सीएमके के लिए विशिष्ट तर्क पारित करने के लिए थोड़ा अधिक सुविधाजनक बनाता है।

तीसरा कदम

 factory.addStep(steps.CMake( workdir = 'build', path = '../sources', haltOnFailure = True) )

प्रोजेक्ट संकलित करने का समय। पिछले मामले में, आप शेलकोमैंड का उपयोग कर सकते हैं। इसी तरह, कंपाइल क्लास है, जो शेलकोमैंड के ऊपर एक आवरण है। फिर भी, यह एक पेचीदा आवरण है: संकलन के दौरान संकलन क्लास मॉनिटरिंग चेतावनियों की निगरानी करता है और उन्हें एक अलग लॉग में प्रदर्शित करता है। यही कारण है कि हम कम्पाइल क्लास का उपयोग करेंगे:

चौथा चरण

 factory.addStep(steps.Compile( name = 'build project', workdir = 'build', haltOnFailure = True, warnOnWarnings = True, command = ['make']) )

अंत में, हमारे परीक्षण चलाएं। यहां हम पहले बताए गए ShellCommand वर्ग का उपयोग करेंगे:

पांचवां चरण

 factory.addStep(steps.ShellCommand( name = 'run tests', workdir = 'build', haltOnFailure = True, command = ['ctest']) )

उदाहरण दो: एक कोड के रूप में पाइपलाइन

यहां मैं दिखाऊंगा कि प्रोजेक्ट लॉजिक कोड के साथ टेस्टिंग लॉजिक को स्टोर करने के लिए बजट विकल्प को कैसे लागू किया जाए, न कि ci-server कॉन्फ़िगरेशन फाइल में। ऐसा करने के लिए, कोड के साथ रिपॉजिटरी में .buildbot फ़ाइल डालें , जिसमें प्रत्येक पंक्ति में शब्द शामिल हैं, जिनमें से पहली को कमांड के निष्पादन के लिए एक निर्देशिका के रूप में व्याख्या की गई है, और बाकी अपने तर्कों के साथ एक कमांड के रूप में। हमारे पेट प्रोजेक्ट के लिए .buildbot फाइल इस तरह दिखाई देगी:

कमांड के साथ .Bildbot फ़ाइल

. rm -rf build
. mkdir build
build cmake ../sources
build make
build ctest

अब हमें बिल्डबोट कॉन्फ़िगरेशन फ़ाइल को संशोधित करने की आवश्यकता है। .Buildbot फाइल का विश्लेषण करने के लिए, हमें अपने स्वयं के चरण की एक कक्षा लिखनी होगी। यह चरण .buildbot फ़ाइल को पढ़ेगा , जिसके बाद प्रत्येक पंक्ति के लिए आवश्यक तर्क के साथ ShellCommand चरण जोड़ें। गतिशील रूप से चरण जोड़ने के लिए, हम build.addStepsAfterCurrentStep () विधि का उपयोग करेंगे। यह बिल्कुल डरावना नहीं है:

क्लास एनालिसिसस्टेप

 class AnalyseStep(ShellMixin, BuildStep): def __init__(self, workdir, **kwargs): kwargs = self.setupShellMixin(kwargs, prohibitArgs = ['command', 'workdir', 'want_stdout']) BuildStep.__init__(self, **kwargs) self.workdir = workdir @defer.inlineCallbacks def run(self): self.stdio_log = yield self.addLog('stdio') cmd = RemoteShellCommand( command = ['cat', '.buildbot'], workdir = self.workdir, want_stdout = True, want_stderr = True, collectStdout = True ) cmd.useLog(self.stdio_log) yield self.runCommand(cmd) if cmd.didFail(): defer.returnValue(util.FAILURE) results = [] for row in cmd.stdout.splitlines(): lst = row.split() dirname = lst.pop(0) results.append(steps.ShellCommand( name = lst[0], command = lst, workdir = dirname ) ) self.build.addStepsAfterCurrentStep(results) defer.returnValue(util.SUCCESS)

इस दृष्टिकोण के लिए धन्यवाद, कलेक्टर के लिए कारखाना सरल और अधिक बहुमुखी हो गया है:

फ़ाइल का विश्लेषण करने के लिए फैक्टरी

 factory = util.BuildFactory() factory.addStep(steps.Git( repourl = util.Property('repository'), workdir = 'sources', haltOnFailure = True, submodules = True, progress = True, mode = 'incremental') ) factory.addStep(AnalyseStep( name = 'Analyse .buildbot file', workdir = 'sources', haltOnFailure = True, hideStepIf = lambda results, s: results == util.SUCCESS) )

उदाहरण तीन: एक कोड के रूप में कार्यकर्ता

अब कल्पना करें कि परियोजना कोड के बगल में, हमें आदेशों के अनुक्रम को निर्धारित करने की आवश्यकता नहीं है, लेकिन विधानसभा के लिए वातावरण। वास्तव में, हम कार्यकर्ता को परिभाषित करते हैं। .Buildbot फाइल कुछ इस तरह दिख सकती है:

। पर्यावरण की फ़ाइल

{
"workers": ["stretch32", "wheezy32"]
}

इस स्थिति में, बिल्डबोट कॉन्फ़िगरेशन फ़ाइल अधिक जटिल हो जाएगी, क्योंकि हम चाहते हैं कि विभिन्न परिवेशों पर असेंबली को परस्पर जोड़ा जाए (यदि कम से कम एक वातावरण विफल हो जाता है, तो पूरी प्रतिबद्धता निष्क्रिय मानी गई थी)। दो-स्तरीय हमें समस्या को हल करने में मदद करते हैं। हमारे पास एक स्थानीय कार्यकर्ता होगा जो .buildbot फाइल को पार्स करता है और वांछित श्रमिकों पर बिल्ड चलाता है। सबसे पहले, पिछले उदाहरण की तरह, हम .buildbot फाइल का विश्लेषण करने के लिए अपना चरण लिखेंगे । किसी विशिष्ट कार्यकर्ता पर असेंबली शुरू करने के लिए, ट्रिगर स्टेप से एक बंडल और एक विशेष प्रकार के ट्रिगर्जेबल शेड्यूलर शेड्यूलर्स का उपयोग किया जाता है । हमारा कदम थोड़ा और जटिल हो गया है, लेकिन काफी समझ में आता है:

क्लास एनालिसिसस्टेप

 class AnalyseStep(ShellMixin, BuildStep): def __init__(self, workdir, **kwargs): kwargs = self.setupShellMixin(kwargs, prohibitArgs = ['command', 'workdir', 'want_stdout']) BuildStep.__init__(self, **kwargs) self.workdir = workdir @defer.inlineCallbacks def _getWorkerList(self): cmd = RemoteShellCommand( command = ['cat', '.buildbot'], workdir = self.workdir, want_stdout = True, want_stderr = True, collectStdout = True ) cmd.useLog(self.stdio_log) yield self.runCommand(cmd) if cmd.didFail(): defer.returnValue([]) # parse JSON try: payload = json.loads(cmd.stdout) workers = payload.get('workers', []) except json.decoder.JSONDecodeError as e: raise ValueError('Error loading JSON from .buildbot file: {}' .format(str(e))) defer.returnValue(workers) @defer.inlineCallbacks def run(self): self.stdio_log = yield self.addLog('stdio') try: workers = yield self._getWorkerList() except ValueError as e: yield self.stdio_log.addStdout(str(e)) defer.returnValue(util.FAILURE) results = [] for worker in workers: results.append(steps.Trigger( name = 'check on worker "{}"'.format(worker), schedulerNames = ['Pet Project ({}) Scheduler'.format(worker)], waitForFinish = True, haltOnFailure = True, warnOnWarnings = True, updateSourceStamp = False, alwaysUseLatest = False ) ) self.build.addStepsAfterCurrentStep(results) defer.returnValue(util.SUCCESS)

हम स्थानीय कार्यकर्ता के इस कदम का उपयोग करेंगे। कृपया ध्यान दें कि हमने अपने कलेक्टर "पेट प्रोजेक्ट बिल्डर" को टैग सेट कर दिया है। इसके साथ, हम मेलनोटिफायर को फ़िल्टर कर सकते हैं, यह बताते हुए कि पत्र केवल कुछ कलेक्टरों को भेजे जाने चाहिए। यदि यह फ़िल्टरिंग नहीं किया जाता है, तो दो वातावरणों पर प्रतिबद्ध बनाते समय, हमें तीन पत्र प्राप्त होंगे।

सामान्य कलेक्टर

 factory = util.BuildFactory() factory.addStep(steps.Git( repourl = util.Property('repository'), workdir = 'sources', haltOnFailure = True, submodules = True, progress = True, mode = 'incremental') ) factory.addStep(AnalyseStep( name = 'Analyse .buildbot file', workdir = 'sources', haltOnFailure = True, hideStepIf = lambda results, s: results == util.SUCCESS) ) c['builders'] = [util.BuilderConfig( name = 'Pet Project Builder', tags = ['generic_builder'], workernames = ['local'], factory = factory )]

यह हमारे सभी वास्तविक श्रमिकों के लिए कलेक्टरों और एक ही ट्रिगर करने वाले शेड्यूलर्स को जोड़ने के लिए रहता है:

सही माहौल में कलेक्टर

 for worker in allWorkers: c['schedulers'].append(schedulers.Triggerable( name = 'Pet Project ({}) Scheduler'.format(worker), builderNames = ['Pet Project ({}) Builder'.format(worker)]) ) c['builders'].append(util.BuilderConfig( name = 'Pet Project ({}) Builder'.format(worker), workernames = [worker], factory = specific_factory) )

(दो वातावरण में हमारी परियोजना का पृष्ठ बनाएँ)

उदाहरण चार: कई अक्षरों में से एक अक्षर

यदि आप उपरोक्त उदाहरणों में से किसी का उपयोग करते हैं, तो आप एक अप्रिय विशेषता को नोटिस कर सकते हैं। चूंकि प्रत्येक प्रतिबद्ध के लिए एक पत्र बनाया जाता है, जब हम शाखा को 20 नए कमिट के साथ आगे बढ़ाते हैं, तो हमें 20 पत्र प्राप्त होंगे। इससे बचते हुए, पिछले उदाहरण की तरह, हम दो-स्तरीय मदद करेंगे। हमें परिवर्तन प्राप्त करने के लिए कक्षा को संशोधित करने की भी आवश्यकता है। कई परिवर्तन ऑब्जेक्ट बनाने के बजाय, हम केवल एक ऐसी वस्तु बनाएंगे, जिसके गुणों में सभी कमिट्स की एक सूची प्रसारित होती है। जल्दी में, यह इस तरह किया जा सकता है:

क्लास मल्टीगिटहुबंडलर

 class MultiGitHubHandler(GitHubHandler): def getChanges(self, request): new_changes = GitHubHandler.getChanges(self, request) if not new_changes: return ([], 'git') change = new_changes[-1] change['revision'] = '{}..{}'.format( new_changes[0]['revision'], new_changes[-1]['revision']) commits = [c['revision'] for c in new_changes] change['properties']['commits'] = commits return ([change], 'git') c['www']['change_hook_dialects'] = { 'base': { 'custom_class': MultiGitHubHandler } }

इस तरह के असामान्य परिवर्तन वाली वस्तु के साथ काम करने के लिए, हमें अपने स्वयं के विशेष कदम की आवश्यकता होती है, जो गतिशील रूप से ऐसे कदम बनाता है जो एक विशिष्ट प्रतिबद्धता एकत्र करते हैं:

कक्षा GenerateCommitSteps

 class GenerateCommitSteps(BuildStep): def run(self): commits = self.getProperty('commits') results = [] for commit in commits: results.append(steps.Trigger( name = 'Checking commit {}'.format(commit), schedulerNames = ['Pet Project Commits Scheduler'], waitForFinish = True, haltOnFailure = True, warnOnWarnings = True, sourceStamp = { 'branch': util.Property('branch'), 'revision': commit, 'codebase': util.Property('codebase'), 'repository': util.Property('repository'), 'project': util.Property('project') } ) ) self.build.addStepsAfterCurrentStep(results) return util.SUCCESS

हमारे सामान्य संग्राहक को जोड़ें, जो केवल व्यक्तिगत कमिटियों की विधानसभाओं को चलाने में शामिल है। तब इस टैग द्वारा अक्षरों के भेजने को फ़िल्टर करने के लिए इसे टैग किया जाना चाहिए।

सामान्य मेल फ़ेचर

 c['schedulers'] = [schedulers.AnyBranchScheduler( name = 'Pet Project Branches Scheduler', treeStableTimer = None, change_filter = util.ChangeFilter(project = 'Pet Project'), builderNames = ['Pet Project Branches Builder'] )] branches_factory = util.BuildFactory() branches_factory.addStep(GenerateCommitSteps( name = 'Generate commit steps', haltOnFailure = True, hideStepIf = lambda results, s: results == util.SUCCESS) ) c['builders'] = [util.BuilderConfig( name = 'Pet Project Branches Builder', tags = ['branch_builder'], workernames = ['local'], factory = branches_factory )]

यह केवल व्यक्तिगत आवागमन के लिए कलेक्टर को जोड़ने के लिए बनी हुई है। हम इस कलेक्टर को केवल एक टैग के साथ टैग नहीं करते हैं, और इसलिए इसके लिए पत्र नहीं बनाए जाएंगे।

सामान्य मेल फ़ेचर

 c['schedulers'].append(schedulers.Triggerable( name = 'Pet Project Commits Scheduler', builderNames = ['Pet Project Commits Builder']) ) c['builders'].append(util.BuilderConfig( name = 'Pet Project Commits Builder', workernames = ['stretch32'], factory = specific_factory) )

अंतिम शब्द

यह लेख किसी भी तरह से आधिकारिक प्रलेखन को पढ़ने की जगह नहीं देता है, इसलिए यदि आप बिल्डबॉट में रुचि रखते हैं, तो आपका अगला कदम इसे पढ़ने के लिए होना चाहिए। सभी उदाहरणों की कॉन्फ़िगरेशन फ़ाइलों के पूर्ण संस्करण जीथब पर उपलब्ध हैं। संबंधित लिंक, जिसमें से लेख के लिए अधिकांश सामग्री ली गई थी:

बिल्डबॉट: एक अन्य सतत एकीकरण प्रणाली के उदाहरणों के साथ एक कहानी