ये फ़ंक्शन @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 रिपॉज़िटरी का क्लोन बनाएं.
Git रिपॉज़िटरी को क्लोन करता है, बताए गए टैग की जांच करता है या कमिट करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. साथ ही, चेक आउट किए गए काम का आईडी और उसकी तारीख भी तय करें. साथ ही, पैरामीटर के साथ एक डिसक्वेंट दें जो इस नियम का फिर से बनाया जा सकने वाला वर्शन देता है (जो ज़रूरी नहीं है कि टैग ही ऐसा हो).
Baज़ल, सबसे पहले सिर्फ़ तय की गई कमिटी का शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता है (आम तौर पर, सर्वर की सुविधा मौजूद न होने की वजह से), तो यह डेटा स्टोर करने की जगह को पूरी तरह से फ़ेच कर लेगा.
git_repository
से http_archive
को प्राथमिकता दें.
इसकी वजहें ये हैं:
- Git डेटा स्टोर करने की जगह के नियम, सिस्टम
git(1)
पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर, Basel में बनाया गया है और इसमें कोई सिस्टम डिपेंडेंसी नहीं है. http_archive
,urls
की सूची को मिरर के तौर पर इस्तेमाल करता है औरgit_repository
सिर्फ़ एकremote
के साथ काम करता है.http_archive
, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिनgit_repository
के साथ काम नहीं करता. ज़्यादा जानकारी के लिए, #5116 देखें.
विशेषताएं
name |
नाम; ज़रूरी है
डेटा स्टोर करने की इस जगह के लिए यूनीक नाम. |
branch |
स्ट्रिंग; वैकल्पिक
ब्रांच में जाकर उससे चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
build_file |
लेबल; ज़रूरी नहीं
डेटा स्टोर करने की इस फ़ाइल के लिए, बिल्ड फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट एक ऐब्सलूट लेबल है. मुख्य रेपो के लिए, '@//' का इस्तेमाल करें. फ़ाइल का नाम BUILD रखने की ज़रूरत नहीं है. हालांकि, यह हो सकता है (BUILD.new-repo-name जैसा कुछ इस तरह से काम करता है कि इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सके. |
build_file_content |
स्ट्रिंग; वैकल्पिक
इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट. |
commit |
स्ट्रिंग; वैकल्पिक
करने का वादा किया. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
init_submodules |
बूलियन; वैकल्पिक
रिपॉज़िटरी में सबमॉड्यूल का क्लोन बनाना है या नहीं. |
patch_args |
स्ट्रिंग की सूची; वैकल्पिक
पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Patch_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; वैकल्पिक
इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा. |
recursive_init_submodules |
बूलियन; वैकल्पिक
क्या रिपॉज़िटरी में सबमॉड्यूल को बार-बार क्लोन करना है. |
remote |
स्ट्रिंग; आवश्यक है
रिमोट Git रिपॉज़िटरी का यूआरआई |
repo_mapping |
शब्दकोश: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है
लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए. |
shallow_since |
स्ट्रिंग; वैकल्पिक
वैकल्पिक तारीख, तय किए गए कमिट के बाद नहीं; अगर किसी टैग या शाखा के बारे में बताया गया है, तो तर्क की अनुमति नहीं है (जिसकी हमेशा --depth=1 की मदद से क्लोन किया जा सकता है). तय की गई कमिट के करीब ऐसी तारीख सेट करने से, रिपॉज़िटरी के शैलो क्लोन की अनुमति मिल सकती है. भले ही, सर्वर आर्बिटरी कमिट के शैलो फ़ेच की सुविधा न देता हो. git's --हैलो-से-इन लागू करने में गड़बड़ी की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता है, क्योंकि इससे फ़ेच करने में गड़बड़ी हो सकती है. |
strip_prefix |
स्ट्रिंग; वैकल्पिक
निकाली गई फ़ाइलों से स्ट्रिप करने के लिए एक डायरेक्ट्री प्रीफ़िक्स. |
tag |
स्ट्रिंग; वैकल्पिक
टैग से चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
verbose |
बूलियन; वैकल्पिक |
workspace_file |
लेबल; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |
workspace_file_content |
स्ट्रिंग; वैकल्पिक
इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `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 रिपॉज़िटरी का क्लोन बनाएं.
Git रिपॉज़िटरी को क्लोन करता है, बताए गए टैग की जांच करता है या कमिट करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. साथ ही, चेक आउट किए गए काम का आईडी और उसकी तारीख भी तय करें. साथ ही, पैरामीटर के साथ एक डिसक्वेंट दें जो इस नियम का फिर से बनाया जा सकने वाला वर्शन देता है (जो ज़रूरी नहीं है कि टैग ही ऐसा हो).
Baज़ल, सबसे पहले सिर्फ़ तय की गई कमिटी का शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता है (आम तौर पर, सर्वर की सुविधा मौजूद न होने की वजह से), तो यह डेटा स्टोर करने की जगह को पूरी तरह से फ़ेच कर लेगा.
git_repository
से http_archive
को प्राथमिकता दें.
इसकी वजहें ये हैं:
- Git डेटा स्टोर करने की जगह के नियम, सिस्टम
git(1)
पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर, Basel में बनाया गया है और इसमें कोई सिस्टम डिपेंडेंसी नहीं है. http_archive
,urls
की सूची को मिरर के तौर पर इस्तेमाल करता है औरgit_repository
सिर्फ़ एकremote
के साथ काम करता है.http_archive
, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिनgit_repository
के साथ काम नहीं करता. ज़्यादा जानकारी के लिए, #5116 देखें.
विशेषताएं
name |
नाम; ज़रूरी है
डेटा स्टोर करने की इस जगह के लिए यूनीक नाम. |
branch |
स्ट्रिंग; वैकल्पिक
ब्रांच में जाकर उससे चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
build_file |
लेबल; ज़रूरी नहीं
डेटा स्टोर करने की इस फ़ाइल के लिए, बिल्ड फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट एक ऐब्सलूट लेबल है. मुख्य रेपो के लिए, '@//' का इस्तेमाल करें. फ़ाइल का नाम BUILD रखने की ज़रूरत नहीं है. हालांकि, यह हो सकता है (BUILD.new-repo-name जैसा कुछ इस तरह से काम करता है कि इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सके. |
build_file_content |
स्ट्रिंग; वैकल्पिक
इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट. |
commit |
स्ट्रिंग; वैकल्पिक
करने का वादा किया. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
init_submodules |
बूलियन; वैकल्पिक
रिपॉज़िटरी में सबमॉड्यूल का क्लोन बनाना है या नहीं. |
patch_args |
स्ट्रिंग की सूची; वैकल्पिक
पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; वैकल्पिक
पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Patch_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; वैकल्पिक
इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा. |
recursive_init_submodules |
बूलियन; वैकल्पिक
क्या रिपॉज़िटरी में सबमॉड्यूल को बार-बार क्लोन करना है. |
remote |
स्ट्रिंग; आवश्यक है
रिमोट Git रिपॉज़िटरी का यूआरआई |
repo_mapping |
शब्दकोश: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है
लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए. |
shallow_since |
स्ट्रिंग; वैकल्पिक
वैकल्पिक तारीख, तय किए गए कमिट के बाद नहीं; अगर किसी टैग या शाखा के बारे में बताया गया है, तो तर्क की अनुमति नहीं है (जिसकी हमेशा --depth=1 की मदद से क्लोन किया जा सकता है). तय की गई कमिट के करीब ऐसी तारीख सेट करने से, रिपॉज़िटरी के शैलो क्लोन की अनुमति मिल सकती है. भले ही, सर्वर आर्बिटरी कमिट के शैलो फ़ेच की सुविधा न देता हो. git's --हैलो-से-इन लागू करने में गड़बड़ी की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता है, क्योंकि इससे फ़ेच करने में गड़बड़ी हो सकती है. |
strip_prefix |
स्ट्रिंग; वैकल्पिक
निकाली गई फ़ाइलों से स्ट्रिप करने के लिए एक डायरेक्ट्री प्रीफ़िक्स. |
tag |
स्ट्रिंग; वैकल्पिक
टैग से चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए. |
verbose |
बूलियन; वैकल्पिक |
workspace_file |
लेबल; ज़रूरी नहीं
इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |
workspace_file_content |
स्ट्रिंग; वैकल्पिक
इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है. |