@bazel_tools//tools/build_defs/repo:git.bzl
से ये फ़ंक्शन लोड किए जा सकते हैं.
बाहरी git डेटा स्टोर करने की जगहों को क्लोन करने के नियम.
git_repository
git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args, patch_cmds, patch_cmds_win, patch_tool, patches, recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag, verbose, workspace_file, workspace_file_content)
बाहरी गिट रिपॉज़िटरी का क्लोन बनाएं.
यह Git रिपॉज़िटरी को क्लोन करता है, तय किए गए टैग की जांच करता है या तय करता है. साथ ही, इसके टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. साथ ही, वाकई में चेक आउट किए गए दस्तावेज़ का आईडी और उसकी तारीख तय करें. साथ ही, ऐसे पैरामीटर के साथ डिक्शनरी दिखाएं जो इस नियम का फिर से जनरेट किया जा सकने वाला वर्शन उपलब्ध कराते हों (जो कि ज़रूरी नहीं है).
Bazel पहले सिर्फ़ तय की गई प्रतिबद्धता को शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता (आम तौर पर सर्वर के साथ काम न करने की वजह से), तो डेटा स्टोर करने की जगह के पूरे डेटा को फ़ेच किया जाएगा.
git_repository
के लिए http_archive
को प्राथमिकता दें.
इसकी वजहें यहां दी गई हैं:
- Git रिपॉज़िटरी के नियम, सिस्टम
git(1)
पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर, Bazel में पहले से बना होता है. साथ ही, इसके लिए कोई सिस्टम डिपेंडेंसी नहीं होती है. http_archive
,urls
की सूची को मिरर के तौर पर इस्तेमाल करता है औरgit_repository
सिर्फ़ एकremote
के साथ काम करता है.http_archive
, डेटा स्टोर करने की जगह की कैश मेमोरी के साथ काम करता है, लेकिनgit_repository
के साथ नहीं. ज़्यादा जानकारी के लिए, #5116 देखें.
एट्रिब्यूट
name |
नाम; ज़रूरी है
डेटा स्टोर करने की इस जगह के लिए खास नाम. |
branch |
स्ट्रिंग; ज़रूरी नहीं
ब्रांच की वैल्यू डालें. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
build_file |
लेबल; ज़रूरी नहीं
इस रिपॉज़िटरी के लिए BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल.यह एट्रिब्यूट एक पूरा लेबल है (मुख्य डेटा स्टोर करने के लिए '@//' का इस्तेमाल करें). फ़ाइल को BUILD का नाम देने की ज़रूरत नहीं है, लेकिन (BUILD.new-repo-name जैसी कोई फ़ाइल, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.) |
build_file_content |
स्ट्रिंग; ज़रूरी नहीं
इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. |
commit |
स्ट्रिंग; ज़रूरी नहीं
चेक आउट करने के लिए प्रतिबद्ध हैं. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
init_submodules |
बूलियन; ज़रूरी नहीं
रिपॉज़िटरी में सबमॉड्यूल को क्लोन करना है या नहीं. |
patch_args |
स्ट्रिंग की सूची; वैकल्पिक
पैच टूल को दिए गए तर्क. डिफ़ॉल्ट वैल्यू -p0 होती है. हालांकि, आम तौर पर git से जनरेट किए गए पैच के लिए, -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट दिए गए हैं, तो आखिरी वाला लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया गया है, तो Bazel फिर से Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. अगर पैच कमांड लाइन टूल और पैच_tool एट्रिब्यूट के बारे में नहीं बताया गया है, तो `patch` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Linux/Macos पर लागू किए जाने वाले बैश कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Windows पर लागू किए जाने वाले PowerPoint कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर restricted_cmds चलाए जाएंगे. इसके लिए, बैश बाइनरी का होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; ज़रूरी नहीं
पैच(1) यूटिलिटी. अगर यह बताया गया है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय बताए गए पैच टूल का इस्तेमाल करेगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने के तरीके का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट दिया गया है, तो Bazel वापस पैच कमांड लाइन टूल का इस्तेमाल करेगा. इसके अलावा, `patch_ जाएगाs` एट्रिब्यूट में `-p` के अलावा दूसरे तर्क मौजूद होने पर भी Bazel वापस पैच कमांड लाइन टूल का इस्तेमाल करेगा. |
recursive_init_submodules |
बूलियन; ज़रूरी नहीं
क्या डेटा स्टोर करने की जगह में, सबमॉड्यूल को बार-बार क्लोन करना है. |
remote |
स्ट्रिंग; ज़रूरी है
रिमोट Git रिपॉज़िटरी का यूआरआई |
repo_mapping |
डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है
स्थानीय डेटा स्टोर करने की जगह के नाम से ग्लोबल रिपॉज़िटरी के नाम तक का शब्दकोश. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से यह पता चलता है कि यह रिपॉज़िटरी किसी भी समय `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में डिपेंडेंसी को ठीक किया जाना चाहिए. |
shallow_since |
स्ट्रिंग; ज़रूरी नहीं
एक वैकल्पिक तारीख, तय की गई प्रतिबद्धता के बाद नहीं; अगर कोई टैग या ब्रांच तय की गई है, तो तर्क की अनुमति नहीं है (जिसे हमेशा --depth=1 के साथ क्लोन किया जा सकता है). तय की गई प्रतिबद्धता के आस-पास की तारीख सेट करने से, रिपॉज़िटरी (डेटा स्टोर करने की जगह) के उथले क्लोन की अनुमति मिल सकती है, भले ही सर्वर आर्बिटरी कमियों के उथले फ़ेच के साथ काम न करता हो. git के --shallow-since को लागू करने में हुई गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा करने से, फ़ेच न हो पाने की समस्या हो सकती है. |
strip_prefix |
स्ट्रिंग; ज़रूरी नहीं
निकाली गई फ़ाइलों से निकालने के लिए एक डायरेक्ट्री प्रीफ़िक्स. |
tag |
स्ट्रिंग; ज़रूरी नहीं
टैग के लिए चुना गया है. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
verbose |
बूलियन; ज़रूरी नहीं |
workspace_file |
लेबल; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए, `WORKSPACE` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` को तय किया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |
workspace_file_content |
स्ट्रिंग; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` को तय किया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |
new_git_repository
new_git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args, patch_cmds, patch_cmds_win, patch_tool, patches, recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag, verbose, workspace_file, workspace_file_content)
बाहरी गिट रिपॉज़िटरी का क्लोन बनाएं.
यह Git रिपॉज़िटरी को क्लोन करता है, तय किए गए टैग की जांच करता है या तय करता है. साथ ही, इसके टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. साथ ही, वाकई में चेक आउट किए गए दस्तावेज़ का आईडी और उसकी तारीख तय करें. साथ ही, ऐसे पैरामीटर के साथ डिक्शनरी दिखाएं जो इस नियम का फिर से जनरेट किया जा सकने वाला वर्शन उपलब्ध कराते हों (जो कि ज़रूरी नहीं है).
Bazel पहले सिर्फ़ तय की गई प्रतिबद्धता को शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता (आम तौर पर सर्वर के साथ काम न करने की वजह से), तो डेटा स्टोर करने की जगह के पूरे डेटा को फ़ेच किया जाएगा.
git_repository
के लिए http_archive
को प्राथमिकता दें.
इसकी वजहें यहां दी गई हैं:
- Git रिपॉज़िटरी के नियम, सिस्टम
git(1)
पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर, Bazel में पहले से बना होता है. साथ ही, इसके लिए कोई सिस्टम डिपेंडेंसी नहीं होती है. http_archive
,urls
की सूची को मिरर के तौर पर इस्तेमाल करता है औरgit_repository
सिर्फ़ एकremote
के साथ काम करता है.http_archive
, डेटा स्टोर करने की जगह की कैश मेमोरी के साथ काम करता है, लेकिनgit_repository
के साथ नहीं. ज़्यादा जानकारी के लिए, #5116 देखें.
एट्रिब्यूट
name |
नाम; ज़रूरी है
डेटा स्टोर करने की इस जगह के लिए खास नाम. |
branch |
स्ट्रिंग; ज़रूरी नहीं
ब्रांच की वैल्यू डालें. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
build_file |
लेबल; ज़रूरी नहीं
इस रिपॉज़िटरी के लिए BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल.यह एट्रिब्यूट एक पूरा लेबल है (मुख्य डेटा स्टोर करने के लिए '@//' का इस्तेमाल करें). फ़ाइल को BUILD का नाम देने की ज़रूरत नहीं है, लेकिन (BUILD.new-repo-name जैसी कोई फ़ाइल, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में अच्छी तरह काम कर सकती है.) |
build_file_content |
स्ट्रिंग; ज़रूरी नहीं
इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. |
commit |
स्ट्रिंग; ज़रूरी नहीं
चेक आउट करने के लिए प्रतिबद्ध हैं. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
init_submodules |
बूलियन; ज़रूरी नहीं
रिपॉज़िटरी में सबमॉड्यूल को क्लोन करना है या नहीं. |
patch_args |
स्ट्रिंग की सूची; वैकल्पिक
पैच टूल को दिए गए तर्क. डिफ़ॉल्ट वैल्यू -p0 होती है. हालांकि, आम तौर पर git से जनरेट किए गए पैच के लिए, -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट दिए गए हैं, तो आखिरी वाला लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया गया है, तो Bazel फिर से Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. अगर पैच कमांड लाइन टूल और पैच_tool एट्रिब्यूट के बारे में नहीं बताया गया है, तो `patch` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Linux/Macos पर लागू किए जाने वाले बैश कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Windows पर लागू किए जाने वाले PowerPoint कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर restricted_cmds चलाए जाएंगे. इसके लिए, बैश बाइनरी का होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; ज़रूरी नहीं
पैच(1) यूटिलिटी. अगर यह बताया गया है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय बताए गए पैच टूल का इस्तेमाल करेगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने के तरीके का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट दिया गया है, तो Bazel वापस पैच कमांड लाइन टूल का इस्तेमाल करेगा. इसके अलावा, `patch_ जाएगाs` एट्रिब्यूट में `-p` के अलावा दूसरे तर्क मौजूद होने पर भी Bazel वापस पैच कमांड लाइन टूल का इस्तेमाल करेगा. |
recursive_init_submodules |
बूलियन; ज़रूरी नहीं
क्या डेटा स्टोर करने की जगह में, सबमॉड्यूल को बार-बार क्लोन करना है. |
remote |
स्ट्रिंग; ज़रूरी है
रिमोट Git रिपॉज़िटरी का यूआरआई |
repo_mapping |
डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है
स्थानीय डेटा स्टोर करने की जगह के नाम से ग्लोबल रिपॉज़िटरी के नाम तक का शब्दकोश. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से यह पता चलता है कि यह रिपॉज़िटरी किसी भी समय `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में डिपेंडेंसी को ठीक किया जाना चाहिए. |
shallow_since |
स्ट्रिंग; ज़रूरी नहीं
एक वैकल्पिक तारीख, तय की गई प्रतिबद्धता के बाद नहीं; अगर कोई टैग या ब्रांच तय की गई है, तो तर्क की अनुमति नहीं है (जिसे हमेशा --depth=1 के साथ क्लोन किया जा सकता है). तय की गई प्रतिबद्धता के आस-पास की तारीख सेट करने से, रिपॉज़िटरी (डेटा स्टोर करने की जगह) के उथले क्लोन की अनुमति मिल सकती है, भले ही सर्वर आर्बिटरी कमियों के उथले फ़ेच के साथ काम न करता हो. git के --shallow-since को लागू करने में हुई गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा करने से, फ़ेच न हो पाने की समस्या हो सकती है. |
strip_prefix |
स्ट्रिंग; ज़रूरी नहीं
निकाली गई फ़ाइलों से निकालने के लिए एक डायरेक्ट्री प्रीफ़िक्स. |
tag |
स्ट्रिंग; ज़रूरी नहीं
टैग के लिए चुना गया है. सटीक तौर पर, किसी एक ब्रांच, टैग या कमिट की वैल्यू दी जानी चाहिए. |
verbose |
बूलियन; ज़रूरी नहीं |
workspace_file |
लेबल; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए, `WORKSPACE` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` को तय किया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |
workspace_file_content |
स्ट्रिंग; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` को तय किया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |