हर्मेटिकिटी

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

इस पेज में हैरमेटिक बिल्ड का इस्तेमाल करने के फ़ायदे, और आपके बिल्ड में गैर-हैमेटिक व्यवहार की पहचान करने की रणनीतियां शामिल हैं.

खास जानकारी

जब एक ही इनपुट स्रोत कोड और प्रॉडक्ट कॉन्फ़िगरेशन दिया जाता है, तो एक हैर्मेटिक बिल्ड सिस्टम, बिल्ड को बदलावों से होस्ट सिस्टम में अलग करके हमेशा एक जैसे आउटपुट देता है.

बिल्ड को अलग करने के लिए, रिकॉर्ड किए जाने वाले बिल्ड लाइब्रेरी और स्थानीय या रिमोट होस्ट मशीन पर इंस्टॉल किए गए अन्य सॉफ़्टवेयर को लेकर संवेदनशील नहीं होते हैं. ये बिल्ड टूल के खास वर्शन पर निर्भर करते हैं, जैसे कि कंपाइलर और डिपेंडेंसी, जैसे कि लाइब्रेरी. इससे बिल्ड प्रोसेस अपने-आप में पूरी हो जाती है, क्योंकि यह बिल्ड एनवायरमेंट के बाहर की सेवाओं पर निर्भर नहीं करती है.

मालिकाना हक के दो अहम पहलू हैं:

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

फ़ायदे

हर्मेटिक बिल्ड के मुख्य फ़ायदे हैं:

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

उपयोगकर्ता की दिलचस्पी के बारे में जानकारी न मिलना

अगर आप Bazel पर स्विच करने की तैयारी कर रहे हैं, तो पहले से मौजूद बिल्ड की अनुमान को बेहतर बनाने पर माइग्रेशन ज़्यादा आसान हो जाएगा. बिल्ड में बिना हैरमेटी के कुछ सामान्य स्रोत ये हैं:

  • .mk फ़ाइलों में मध्यस्थता की प्रक्रिया
  • ऐसी कार्रवाइयां या टूल जो आम तौर पर फ़ाइलों को तय नहीं करते हैं, जिनमें आम तौर पर बिल्ड टाइमस्टैंप या टाइमस्टैंप शामिल होते हैं
  • सिस्टम की बाइनरी जो होस्ट के हिसाब से अलग-अलग होती हैं (जैसे कि /usr/bin बाइनरी, ऐब्सलूट पाथ, सिस्टम C++ कंपाइलर)
  • बिल्ड के दौरान सोर्स ट्री में लिखना. यह एक ही सोर्स ट्री को किसी दूसरे टारगेट के लिए इस्तेमाल करने से रोकता है. पहला बिल्ड, सोर्स ट्री में लिखता है और टारगेट A के लिए सोर्स ट्री को ठीक करता है. फिर लक्ष्य B बनाने का प्रयास विफल हो सकता है.

गैर-हेरमेटिक बिल्ड से जुड़ी समस्याओं को हल करना

लोकल एक्ज़ीक्यूशन के साथ शुरू होने वाली समस्याओं से, लोकल कैश हिट पर असर पड़ता है. साथ ही, उन कार्रवाइयों के बारे में पता चलता है जो उपयोगकर्ता की दिलचस्पी नहीं होती.

  • पक्का करें कि क्रम में चलने वाले बिल्ड अमान्य हों: अगर आप make चलाते हैं और सफल तरीके से बिल्ड करते हैं, तो बिल्ड को फिर से चलाने पर कोई टारगेट दोबारा नहीं बना होना चाहिए. अगर आप हर बिल्ड चरण को दो बार या अलग-अलग सिस्टम पर चलाते हैं, तो फ़ाइल कॉन्टेंट के हैश की तुलना करें और ऐसे नतीजे पाएं जो अलग हों, बिल्ड फिर से जनरेट नहीं किया जा सकता.
  • अलग-अलग संभावित क्लाइंट मशीनों पर स्थानीय कैश हिट को डीबग करने का तरीका चलाएं, ताकि यह पक्का हो सके कि आप कार्रवाइयों में ग्राहक के लीक होने के किसी भी मामले को पकड़ लें.
  • डॉकर कंटेनर के अंदर एक बिल्ड लागू करें. इसमें, जांचे गए सोर्स ट्री और होस्ट टूल की साफ़ तौर पर दी गई सूची के अलावा कुछ भी नहीं होता है. बिल्ड ब्रेकअप और गड़बड़ी के मैसेज, सिस्टम की इंडिपेंडेंसी का पता लगा लेंगे.
  • रिमोट एक्ज़ीक्यूशन के नियमों का इस्तेमाल करके किसी समस्या को खोजें और उसे ठीक करें.
  • हर कार्रवाई के लेवल पर, सैंडबॉक्सिंग की सुविधा चालू करें, क्योंकि बिल्ड में की जाने वाली कार्रवाइयों की वजह से, बिल्ड या आउटपुट पर असर पड़ सकता है.
  • Workspace के नियम डेवलपर को बाहरी फ़ाइल फ़ोल्डर में डिपेंडेंसी जोड़ने की अनुमति देते हैं, लेकिन वे इतना रिच होते हैं कि प्रोसेस में आर्बिट्ररी प्रोसेसिंग की अनुमति दी जा सकती है. आप अपने बेज़ेल कमांड में --experimental_workspace_rules_log_file=PATH फ़्लैग करके, Bzel Workspace के फ़ाइल फ़ोल्डर नियमों में, ऐसी चीज़ों का लॉग पा सकते हैं जो आम तौर पर काम के नहीं हैं.

बेज़ल के साथ हरकत

BazelCon की बातचीत के बारे में ज़्यादा जानकारी पाने के लिए, BazelCon के बारे में ये प्रोजेक्ट देखें: