जेनकिंस बिल्डिंग नौकरियों के लिए नियम और व्यंजन

Question

वर्तमान में हम जेनकींस में हमारे सीआई निर्माण के लिए ग्रोवी pipeline scripts जोड़ रहे हैं। कुछ सामान समानांतर किया जा सकता है, कुछ कुछ अन्य निर्माण चरण के उत्पादन पर निर्भर करता है।

parallel "does_not_depend_on_X": { upfront_tests(); }, 
"depends_on_x": { produce_x(); integration_tests(); publish_test_results()} 

अरे! मैं इसे पहचानता हूँ! make ने नियमों और व्यंजनों के साथ इसे हल किया है!

all: upfront_tests test_results x 

test_results: x 
    integration_tests > test_results 

x: x_inputs 
    produce_x $* 

upfront_test_results: 
    upfront_tests 

वहाँ छँटाई/जेनकींस और ग्रूवी भी साथ parallelizing इस निर्देशित-अचक्रीय-ग्राफ प्राप्त करने के लिए कोई तरीका है?

Answer 1

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

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

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

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

pipeline { 
    agent any 

    stages {    
     stage(name='Test', depends='Build'){ 
      steps { 
       sh 'make check' 
       junit 'reports/**/*.xml' 
      } 
     } 
     stage('Build') { 
      steps { 
       sh 'make' 
      } 
     } 
     stage(name='Deploy', depends='Test') { 
      steps { 
       sh 'make publish' 
      } 
     } 
    } 
} 

हालांकि सैद्धांतिक रूप से इस वाक्य और भी अधिक कथात्मक (कोड अब मामलों में चरणों के आदेश के रूप में) होगा, यह व्यावहारिक रूप से एक बेकार सुविधा है चूंकि आदेश चरणों के अनुक्रम का प्रतिनिधित्व करने के लिए पर्याप्त है।