हर्मेटिकिटी

किसी समस्या की शिकायत करें स्रोत देखें

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

खास जानकारी

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

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

एक-दूसरे के आधार पर भेदभाव करने के दो अहम पहलू हैं:

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

इसके फ़ायदे

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

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

किसी अन्य चरण की निगरानी न करना

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

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

नॉन-हेमेटिक बिल्ड से जुड़ी समस्या हल करना

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

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

बेज़ल के साथ हरमेटिकिटी

BazelCon की मदद से, दूसरों के प्रोजेक्ट को कामयाबी मिल गई है. इसके लिए, BazelCon की यह बातचीत देखें: