इस पेज में आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम और उनके पीछे के सिद्धांत के बारे में बताया गया है बनाना. Basel एक आर्टफ़ैक्ट-आधारित बिल्ड सिस्टम है. टास्क के हिसाब से बिल्ड सिस्टम, स्क्रिप्ट बनाने के ऊपर अच्छा चरण रखते हैं, और ये स्क्रिप्ट को बहुत अच्छी तरह से अलग-अलग इंजीनियरों को उनके टास्क तय करने की अनुमति दी.
आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम में, सिस्टम की ओर से तय किए गए कुछ ही टास्क होते हैं
जिसे इंजीनियर सीमित तरीके से कॉन्फ़िगर कर सकते हैं. इंजीनियर अब भी सिस्टम के बारे में बताते हैं
क्या बनाना है, लेकिन बिल्ड सिस्टम यह तय करता है कि इसे कैसे बनाना है. जैसा कि
टास्क पर आधारित बिल्ड सिस्टम, आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम, जैसे कि Basel का वर्शन
बिल्ड-फ़ाइलें होती हैं, लेकिन इन बिल्डफ़ाइलों का कॉन्टेंट बहुत अलग होता है. इसके बजाय
एक ट्यूरिंग-कंप्लीट स्क्रिप्टिंग भाषा में कमांड का सेट
बेज़ल में बिल्डफ़ाइल एक डिक्लेरेटिव टोन में दी गई है और यह बताता है कि आउटपुट कैसे तैयार किया जाता है
मेनिफ़ेस्ट फ़ाइल में उन आर्टफ़ैक्ट के सेट के बारे में बताया गया है जिन्हें बनाना है, उनकी निर्भरता कितनी है, और
सीमित विकल्प होते हैं, जो उन्हें बनाने के तरीके पर असर डालते हैं. जब इंजीनियर bazel चलाते हैं
कमांड लाइन पर, वे टारगेट का एक सेट बनाते हैं, जिसे बनाना है (क्या) और
बेज़ल, कंपाइलेशन को कॉन्फ़िगर करने, चलाने, और शेड्यूल करने की ज़िम्मेदारी है
कदमों के बारे में ज़्यादा जानें (कैसे). क्योंकि बिल्ड सिस्टम के पास अब
चलाने के लिए उपलब्ध टूल की मदद से, यह इस बात की बहुत बड़ी गारंटी दे सकता है कि यह
और उनके सही होने की गारंटी देते हुए भी बेहतर तरीके से काम कर सकते हैं.
फ़ंक्शनल नज़रिया
आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम और फ़ंक्शनल सिस्टम के बीच तुलना करना आसान है प्रोग्रामिंग. पारंपरिक इंपेरेटिव प्रोग्रामिंग भाषाएं (जैसे, Java, C, और Python) एक के बाद एक लागू किए जाने वाले स्टेटमेंट की सूची बनाता है, ठीक उसी तरह जिस तरह टास्क पर आधारित बिल्ड सिस्टम, प्रोग्रामर को कई चरण करने के लिए डिज़ाइन किया गया है. फ़ंक्शनल प्रोग्रामिंग लैंग्वेज (जैसे, Haskell और ML). इन्हें काफ़ी हद तक गणित के समीकरणों की तरह बनाया जाता है. तय सीमा में करने के लिए, प्रोग्रामर एक कंप्यूटेशन के बारे में बताता है, लेकिन इस बात का विवरण देता है कि वह गणना कंपाइलर.
इससे पता चलता है कि आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम में मेनिफ़ेस्ट का एलान किया जा सकता है और सिस्टम को बिल्ड को एक्ज़ीक्यूट करने का तरीका पता लगाने देता है. बहुत सारे सवाल एक ही जगह पर नहीं हो सकते फ़ंक्शनल प्रोग्रामिंग का इस्तेमाल करके, साफ़ तौर पर बताया जा सकता है. हालांकि, इससे जिन लोगों को फ़ायदा होता है से बहुत अलग है: भाषा अक्सर इस तरह के और उनके सही होने की मज़बूत गारंटी देने में मदद करता है. कर सकती है. इनका इस्तेमाल करके, सबसे आसान से जुड़े सवालों को फ़ंक्शनल प्रोग्रामिंग वे होती हैं जिनमें किसी एक चीज़ को पूरी तरह से बदलना होता है नियमों या फ़ंक्शन की सीरीज़ का इस्तेमाल करके, डेटा को किसी दूसरे डेटा में भेजना. और बस इतना ही बिल्ड सिस्टम क्या होता है: पूरा सिस्टम, असल में गणितीय तौर पर काम करता है जो सोर्स फ़ाइलों (और कंपाइलर जैसे टूल) को इनपुट के तौर पर लेता है और आउटपुट के तौर पर बाइनरी. इसलिए, इस बात में कोई हैरानी की बात नहीं है कि ऐसी रणनीति बनाना एक अच्छी तरह से काम करता है और बुनियादी जानकारी देने वाला सिस्टम तैयार किया है.
आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम को समझना
Google का बिल्ड सिस्टम, Blaze पहला आर्टफ़ैक्ट-आधारित बिल्ड सिस्टम था. बेज़ल Blaze का ओपन सोर्स वर्शन है.
बेज़ल में एक बिल्डफ़ाइल (इसे आम तौर पर BUILD कहा जाता है) कैसी दिखती है:
java_binary(
name = "MyBinary",
srcs = ["MyBinary.java"],
deps = [
":mylib",
],
)
java_library(
name = "mylib",
srcs = ["MyLibrary.java", "MyHelper.java"],
visibility = ["//java/com/example/myproduct:__subpackages__"],
deps = [
"//java/com/example/common",
"//java/com/example/myproduct/otherlib",
],
)
Basel में, BUILD फ़ाइलें टारगेट तय करती हैं—यहां दो तरह के टारगेट हैं
java_binary और java_library. हर टारगेट एक आर्टफ़ैक्ट से जुड़ा होता है, जो
सिस्टम से बनाया जा सकता है: बाइनरी टारगेट, ऐसे बाइनरी बनाते हैं जिन्हें
किया जा सकता है और लाइब्रेरी टारगेट ऐसी लाइब्रेरी बनाते हैं जिनका इस्तेमाल
बाइनरी या अन्य लाइब्रेरी का इस्तेमाल करना चाहिए. हर टारगेट में:
name: कमांड लाइन पर और दूसरे में टारगेट का रेफ़रंस कैसे दिया जाता है टारगेटsrcs: टारगेट के लिए आर्टफ़ैक्ट बनाने के लिए, इकट्ठा की जाने वाली सोर्स फ़ाइलेंdeps: अन्य ऐसे लक्ष्य जिन्हें इस टारगेट से पहले बनाया जाना चाहिए और जो इनसे लिंक होने चाहिए यह
डिपेंडेंसी या तो एक ही पैकेज में हो सकती हैं (जैसे कि MyBinary
(:mylib पर निर्भर है) या इसी सोर्स हैरारकी में किसी दूसरे पैकेज पर
(जैसे, //java/com/example/common पर mylib की डिपेंडेंसी).
टास्क पर आधारित बिल्ड सिस्टम की तरह ही, बेज़ल की कमांड-लाइन का इस्तेमाल करके बिल्ड किया जा सकता है
टूल. MyBinary टारगेट बनाने के लिए, आप bazel build :MyBinary चलाएं. इस तारीख के बाद
किसी क्लीन रिपॉज़िटरी (डेटा स्टोर करने की जगह) में पहली बार उस कमांड को डालकर, Basel:
- डिपेंडेंसी का ग्राफ़ बनाने के लिए, फ़ाइल फ़ोल्डर में हर
BUILDफ़ाइल को पार्स करता है ट्रैक किया जा सकता है. MyBinaryकी ट्रांज़िटिव डिपेंडेंसी का पता लगाने के लिए ग्राफ़ का इस्तेमाल करता है; वह हर टारगेट जोMyBinaryपर निर्भर करता है और उन सभी टारगेट के लिए पर निर्भर करता है.- इनमें से हर डिपेंडेंसी को क्रम में बनाता है. बेज़ेल की शुरुआत हर बिल्डिंग से हुई
ऐसा टारगेट जिसके पास कोई अन्य डिपेंडेंसी नहीं है और यह किन डिपेंडेंसी को ट्रैक करता है
हर टारगेट के लिए बनाई जानी चाहिए. टारगेट के पूरा होने पर
डिपेंडेंसी बना दी जाती है और बेज़ल अपने लिए टारगेट बनाना शुरू कर देते हैं. यह प्रोसेस
यह तब तक जारी रहेगा, जब तक
MyBinaryकी हर एक ट्रांज़िटिव डिपेंडेंसी बनाया. - यह
MyBinaryको बनाता है और एक्ज़ीक्यूटेबल बाइनरी बनाता है जो सभी इन डिपेंडेंसी को तीसरे चरण में बनाया गया था.
बुनियादी तौर पर, ऐसा नहीं लगता कि यहां जो कुछ हो रहा है वह यह टास्क पर आधारित बिल्ड सिस्टम इस्तेमाल करने पर होने वाले अपडेट से अलग है. सच में, आखिरी नतीजा एक ही बाइनरी है और इसे बनाने की प्रक्रिया डिपेंडेंसी खोजने के लिए कई चरणों का विश्लेषण किया गया है. इसके बाद, क्रम में रखा है. हालांकि, कुछ बड़े अंतर भी हैं. पहला विकल्प दिखेगा चरण 3 में: क्योंकि बेज़ल जानते हैं कि प्रत्येक लक्ष्य केवल एक Java लाइब्रेरी निर्मित करता है, इसलिए यह को पता है कि इसे आर्बिट्रेरी के बजाय Java कंपाइलर चलाना है उपयोगकर्ता की बनाई गई स्क्रिप्ट शामिल होती है, ताकि उसे पता चल सके कि इन चरणों को साथ-साथ चलाना सुरक्षित है. इससे इमारत की परफ़ॉर्मेंस में बहुत ज़्यादा सुधार हो सकता है मल्टीकोर मशीन को एक-एक करके टारगेट करता है और ऐसा सिर्फ़ इसलिए मुमकिन है, क्योंकि आर्टफ़ैक्ट पर आधारित तरीके की मदद से, बिल्ड सिस्टम को उसके काम करने की ज़िम्मेदारी खुद ही मिल जाती है रणनीति बनाई, ताकि यह समानता को लेकर गारंटी दे सके.
हालांकि, इससे होने वाले फ़ायदों को समानता के साथ-साथ और भी ज़्यादा फ़ायदा मिल सकता है. अगली चीज़ जो यह
जब डेवलपर बिना कोई बदलाव किए दूसरी बार bazel
build :MyBinary टाइप करता है, तो हमें उस तरीके का डेटा साफ़ तौर पर दिखने लगता है:
को मैसेज भेजने की कोशिश की जा रही है. इसमें बताया गया है कि टारगेट अप-टू-डेट है. यह है
ऐसा इसलिए हो सकता है, क्योंकि हम दुनिया भर में
इससे पहले—बेज़ल को पता है कि हर टारगेट, सिर्फ़ Java चलाने का नतीजा है
कंपाइलर का इस्तेमाल किया जा सकता है और उसे पता है कि Java कंपाइलर से मिलने वाला आउटपुट सिर्फ़
अगर इनपुट में कोई बदलाव नहीं किया जाता, तो आउटपुट का फिर से इस्तेमाल किया जा सकता है.
यह विश्लेषण हर लेवल पर काम करता है; अगर MyBinary.java में बदलाव होता है, तो Basel को पता चल जाता है
MyBinary को फिर से बनाने के लिए, लेकिन mylib का फिर से इस्तेमाल करें. अगर
//java/com/example/common बदलाव करते हैं, Basel वह लाइब्रेरी फिर से बनाना जानता है,
mylib और MyBinary का इस्तेमाल करें, लेकिन //java/com/example/myproduct/otherlib का फिर से इस्तेमाल करें.
बेज़ल हर कदम पर चलाए जाने वाले टूल की खूबियों के बारे में जानते हैं,
यह हर बार आर्टफ़ैक्ट के कम से कम सेट को फिर से बना सकता है.
यह गारंटी देना कि इससे पुराने सामान नहीं बनेंगे.
बिल्ड प्रोसेस को टास्क के बजाय आर्टफ़ैक्ट के तौर पर दिखाना आसान होता है लेकिन शक्तिशाली. प्रोग्रामर के सामने आने वाले लचीलेपन को कम करके, बिल्ड तो सिस्टम इस बारे में ज़्यादा जान सकता है कि बिल्ड के हर चरण पर क्या किया जा रहा है. यह काम कर सकता है इस जानकारी का इस्तेमाल, बिल्ड को साथ-साथ आगे बढ़ाने के लिए किया जाएगा. और आउटपुट प्रोसेस को दोबारा इस्तेमाल कर सकें. हालांकि, यह तो सिर्फ़ पहला कदम है और ये सब, समानता और फिर से इस्तेमाल किए जाने वाले ब्लॉक, किसी भी ऐसी नीति का आधार बने बिल्ड सिस्टम इस्तेमाल किया जा सकता है.
बेज़ेल की अन्य शानदार ट्रिक
आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम, समानता की मदद से समस्याओं को हल करते हैं और उनका फिर से इस्तेमाल करें जो टास्क पर आधारित बिल्ड सिस्टम में पहले से मौजूद हैं. हालांकि, अब भी कुछ जिन्हें हम हल नहीं कर पाए हैं. बेज़ल चतुर हैं उन्हें हल किया जा सकता है और हमें आगे बढ़ने से पहले उन पर चर्चा करनी चाहिए.
डिपेंडेंसी के तौर पर टूल
हमने पहले एक समस्या का सामना किया था. यह समस्या, इंस्टॉल किए गए टूल पर निर्भर करती थी वह हमारे सिस्टम पर बिल्ड को फिर से जनरेट कर सकता है. इस प्रोसेस की वजह से, टूल के अलग-अलग वर्शन या जगहों से जुड़ी जानकारी शामिल होती है. समस्या और भी ज़्यादा मुश्किल हो गई जब आपका प्रोजेक्ट ऐसी भाषाओं का इस्तेमाल करता है जिन्हें अलग-अलग टूल की ज़रूरत होती है. (जैसे, Windows बनाम Linux), और उन प्लैटफ़ॉर्म को इस्तेमाल करने के लिए, थोड़े अलग टूल की ज़रूरत होती है एक ही नौकरी.
Basel ने टूल को डिपेंडेंसी के तौर पर इस्तेमाल करके, इस समस्या के पहले हिस्से को हल किया
हर टारगेट पर लागू होती है. फ़ाइल फ़ोल्डर में हर java_library, साफ़ तौर पर Java पर निर्भर करता है
कंपाइलर, जो किसी जाने-माने कंपाइलर पर डिफ़ॉल्ट रूप से लागू होता है. जब भी Basel ने
java_library, यह जांच करता है कि बताया गया कंपाइलर उपलब्ध है या नहीं
किसी ज्ञात स्थान पर. किसी अन्य डिपेंडेंसी की तरह, अगर Java कंपाइलर
बदलाव करके, उस पर निर्भर हर आर्टफ़ैक्ट को फिर से बनाया जाता है.
बेज़ल, प्लैटफ़ॉर्म की इंडिपेंडेंस से जुड़ी समस्या का दूसरा हिस्सा हल करते हैं. इसके लिए, बिल्ड कॉन्फ़िगरेशन का इस्तेमाल करना चाहिए. इसके बजाय टारगेट के लिए सेट अप करना मुश्किल होता है. ये कॉन्फ़िगरेशन के टाइप पर निर्भर करते हैं:
- होस्ट कॉन्फ़िगरेशन: बिल्ड के दौरान काम करने वाले टूल बनाना
- टारगेट कॉन्फ़िगरेशन: उस बाइनरी को बनाना जिसका आपने असल में अनुरोध किया था
बिल्ड सिस्टम को बढ़ाना
Basel का लक्ष्य, इनमें से कुछ लोकप्रिय प्रोग्रामिंग भाषाओं को टारगेट करना है बॉक्स है, लेकिन इंजीनियर हमेशा कुछ और करना चाहेंगे—यह काम-आधारित सुविधा का हिस्सा है सिस्टम की मदद से, किसी भी तरह की बिल्ड प्रोसेस को पूरा करने में मदद मिलती है और यह तो बेहतर होगा कि उसे आर्टफ़ैक्ट-आधारित बिल्ड सिस्टम में न दें. अच्छी बात यह है कि Basel का इस्तेमाल करने वाले टारगेट टाइप को कस्टम नियम जोड़ना.
बेज़ल में नियम तय करने के लिए, नियम का लेखक ऐसे इनपुट का एलान करता है जो नियम
की आवश्यकता होती है (BUILD फ़ाइल में पास की गई विशेषताओं के रूप में) और सुधार की गई है
आउटपुट का सेट होता है, जिसे नियम के तहत जनरेट किया जाता है. लेखक ने उन कार्रवाइयों के बारे में भी बताया है
जनरेट करने की प्रोसेस उसी नियम के तहत जनरेट होगी. हर कार्रवाई अपने इनपुट और आउटपुट की जानकारी देती है,
किसी खास फ़ाइल को रन करता है या किसी फ़ाइल में कोई खास स्ट्रिंग लिखता है. इसके अलावा,
अन्य कार्रवाइयों से जुड़ा होता है. इसका मतलब है कि कार्रवाइयां
बिल्ड सिस्टम में सबसे निचले लेवल की कंपोज़ेबल यूनिट हैं—एक कार्रवाई
वह चाहे जो भी हो, जब तक कि वह सिर्फ़ अपने एलान किए गए इनपुट और आउटपुट का इस्तेमाल करता हो, और
Basel, कार्रवाइयों को शेड्यूल करने और उनके नतीजों को सही तरीके से कैश मेमोरी में सेव करने का ध्यान रखता है.
यह सिस्टम पूरी तरह से सुरक्षित नहीं है, क्योंकि किसी ऐक्शन डेवलपर को रोकने का कोई तरीका नहीं है एक ऐसी प्रक्रिया शुरू करने से कार्रवाई करते हैं. लेकिन असल में ऐसा अक्सर नहीं होता है और हम कार्रवाई के स्तर तक गलत इस्तेमाल की संभावना बहुत कम हो जाती है से गड़बड़ियों की संभावना नहीं है. कई सामान्य भाषाओं और टूल का समर्थन करने वाले नियम व्यापक रूप से ऑनलाइन उपलब्ध है और ज़्यादातर प्रोजेक्ट को कभी भी अपने लक्ष्य निर्धारित करने की ज़रूरत नहीं होती नियम. जो नियम बनाते हैं उनके लिए भी, नियम की परिभाषाएं सिर्फ़ एक वाक्य में तय की जानी चाहिए रिपॉज़िटरी में एक ही जगह रखा जाता है. इसका मतलब है कि ज़्यादातर इंजीनियर, और उन्हें इन नियमों के लागू होने की चिंता करने की ज़रूरत नहीं है.
एनवायरमेंट को आइसोलेट करना
कार्रवाइयां करने से ऐसा लगता है कि उनमें वही समस्याएं हो सकती हैं जो अन्य टास्क में होती हैं सिस्टम—क्या अब भी ऐसी कार्रवाइयां लिखना मुमकिन नहीं है जो दोनों एक ही और एक-दूसरे से टकराव होता है? दरअसल, बेज़ल इन सैंडबॉक्सिंग का इस्तेमाल करने से, ऐसा करना संभव नहीं है. समर्थित पर हर कार्रवाई को फ़ाइल सिस्टम के ज़रिए अलग-अलग करके, हर दूसरी कार्रवाई से अलग कर दिया जाता है सैंडबॉक्स. आम तौर पर, हर कार्रवाई वह फ़ाइल सिस्टम जो उसके बताए गए इनपुट और उसके सभी आउटपुट शामिल करता है बनाया गया. इसे Linux पर LXC जैसे सिस्टम से लागू किया जाता है. Docker की मदद से. इसका मतलब है कि कार्रवाइयों का किसी एक के साथ टकराव नहीं हो सकता क्योंकि वे जिन फ़ाइलों का एलान नहीं करते हैं उन्हें पढ़ने में असमर्थ होते हैं. ऐसी फ़ाइलें जिन्हें वे लिखते हैं, लेकिन एलान नहीं करते उन्हें खत्म. Baze, इसके ज़रिए बातचीत करने से रोकने के लिए सैंडबॉक्स का भी इस्तेमाल करते हैं नेटवर्क.
बाहरी डिपेंडेंसी को डिटरमिनिस्टिक बनाना
अब भी एक समस्या बाकी है: बिल्ड सिस्टम को अक्सर डाउनलोड करना पड़ता है
पर निर्भर करता है कि
उन्हें सीधे तौर पर तैयार किया जा रहा है. इसे उदाहरण में इनके द्वारा देखा जा सकता है:
@com_google_common_guava_guava//jar डिपेंडेंसी, जो JAR फ़ाइल डाउनलोड करती है
Maven से मिला डेटा.
मौजूदा फ़ाइल फ़ोल्डर के बाहर की फ़ाइलों के हिसाब से, नुकसान पहुंचाने वाला कॉन्टेंट हो सकता है. वे फ़ाइलें यह कर सकती थीं किसी भी समय बदला जा सकता है. ऐसा करने पर, बिल्ड सिस्टम को लगातार जांच करनी पड़ती है भले ही वे नए हों. अगर कोई रिमोट फ़ाइल बिना किसी बदलाव के बदल जाती है है, तो इसकी वजह से ऐसे बिल्ड भी हो सकते हैं जिन्हें दोहराया नहीं जा सकता—एक बिल्ड किसी का ध्यान न जाने की वजह से, किसी दिन काम कर सकता है और बिना किसी साफ़ वजह के अगले दिन फ़ेल हो सकता है डिपेंडेंसी में बदलाव हुआ है. आख़िर में, एक्सटर्नल डिपेंडेंसी, एक बहुत बड़ी सुरक्षा किसी तीसरे पक्ष के मालिकाना हक वाले कॉन्टेंट का जोखिम हो सकता है: अगर कोई हमलावर आपके खाते में घुसपैठ कर सकता है तो तीसरे पक्ष के सर्वर का इस्तेमाल कर रहे हैं, तो वे निर्भरता फ़ाइल को कुछ अपनी पसंद का डिज़ाइन बना सकते हैं. इससे उन्हें आपके बिल्ड पर पूरा कंट्रोल मिल सकता है पर्यावरण और उसके आउटपुट की जानकारी देता है.
मूल समस्या यह है कि हम चाहते हैं कि बिल्ड सिस्टम इन बातों के बारे में और सोर्स कंट्रोल में जाने की ज़रूरत नहीं है. डिपेंडेंसी अपडेट करना यह एक सोच-समझकर चुना जाने वाला विकल्प होना चाहिए, लेकिन यह फ़ैसला एक नहीं बल्कि अलग-अलग इंजीनियर द्वारा या स्वचालित रूप से सिस्टम. ऐसा इसलिए है, क्योंकि “Live at Head” मॉडल के साथ होने पर भी हम ऐसी बिल्ड चाहते हैं डिटर्मिनिस्टिक होगा. इसका मतलब है कि अगर पिछले 30 मिनट में आपको अपनी डिपेंडेंसी उसी तरह से दिखेगी जैसी वे थीं आखिरी चरण पूरा करें.
Basel और कुछ दूसरे बिल्ड सिस्टम इस समस्या को हल करते हैं. इसके लिए, फ़ाइल फ़ोल्डर में मौजूद मेनिफ़ेस्ट फ़ाइल, जिसमें हर बाहरी फ़ाइल के लिए क्रिप्टोग्राफ़िक हैश मौजूद होता है पर निर्भर है. हैश, टैग को सटीक तरीके से दिखाने का एक छोटा तरीका है. सोर्स कंट्रोल में जाने के लिए, पूरी फ़ाइल की जांच नहीं की जाती. जब कभी नया बाहरी डिपेंडेंसी का रेफ़रंस फ़ाइल फ़ोल्डर से दिया गया है, उस डिपेंडेंसी का हैश है मैन्युअल रूप से या अपने-आप मेनिफ़ेस्ट में जोड़ा जा सकता है. जब बेज़ल बिल्ड में मौजूद है, तो यह कैश मेमोरी में सेव की गई डिपेंडेंसी के असल हैश की जांच उम्मीद के मुताबिक करता है हैश को मेनिफ़ेस्ट में तय किया गया है और हैश अलग होने पर ही फ़ाइल को फिर से डाउनलोड करता है.
अगर हम जिस आर्टफ़ैक्ट को डाउनलोड करते हैं उसका हैश, मेनिफ़ेस्ट फ़ाइल में है, तो बिल्ड तब तक काम नहीं करेगा, जब तक मेनिफ़ेस्ट में हैश को अपडेट नहीं किया जाता. यह स्वचालित रूप से किया जा सकता है, लेकिन उस परिवर्तन को स्वीकृत होना चाहिए और उसमें चेक इन किया जाना चाहिए बिल्ड के लिए नई डिपेंडेंसी स्वीकार करने से पहले सोर्स कंट्रोल. इसका मतलब है कि डिपेंडेंसी के अपडेट होने का रिकॉर्ड हमेशा मौजूद रहता है. साथ ही, बाहरी डिपेंडेंसी को फ़ाइल फ़ोल्डर के सोर्स में बदलाव किए बिना नहीं बदला जा सकता. इसका मतलब यह भी है कि सोर्स कोड के पुराने वर्शन को देखने पर, बिल्ड में उन डिपेंडेंसी का इस्तेमाल करने की गारंटी है जिनका इस्तेमाल वह उस वर्शन को चेक इन करते समय चेक इन किया था (या फिर अगर ये डिपेंडेंसी हैं, तो यह विफल हो जाएगा अब उपलब्ध नहीं है).
बेशक, यह समस्या तब भी हो सकती है, जब कोई रिमोट सर्वर उपलब्ध न हो या खराब डेटा दिखाना शुरू कर देता है—इससे आपके सभी बिल्ड काम करना बंद कर सकते हैं अगर आपके पास इस डिपेंडेंसी की दूसरी कॉपी उपलब्ध नहीं है. इससे बचने के लिए है, तो हमारा सुझाव है कि आप किसी भी गैर-ज़रूरी प्रोजेक्ट के लिए आपके भरोसेमंद और कंट्रोल किए जाने वाले सर्वर या सेवाओं पर निर्भर करती है. नहीं तो, आपके बिल्ड सिस्टम के लिए हमेशा कोई तीसरा पक्ष कंट्रोल करता है उपलब्धता, भले ही चेक-इन हैश अपनी सुरक्षा की गारंटी देते हों.