गिट रिपॉज़िटरी के नियम

ये फ़ंक्शन, @bazel_tools//tools/build_defs/repo:git.bzl से लोड किए जा सकते हैं.

बाहरी git डेटा स्टोर करने की जगहों की क्लोनिंग करने के नियम.

git_repository

load("@bazel//tools/build_defs/repo:git.bzl", "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) पर निर्भर करते हैं. वहीं, एचटीटीपी डाउनलोडर को Bazel में बनाया गया है और इसमें सिस्टम की कोई डिपेंडेंसी नहीं है.
• http_archive, मिरर के तौर पर urls की सूची के साथ काम करता है. वहीं, git_repository सिर्फ़ एक remote के साथ काम करता है.
• http_archive, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिन git_repository के साथ काम नहीं करता. ज़्यादा जानकारी के लिए, #5116 देखें.

एट्रिब्यूट

name	नाम; यह ज़रूरी है डेटा स्टोर करने की इस जगह के लिए यूनीक नाम.
branch	स्ट्रिंग; ज़रूरी नहीं शाखा को चेक आउट किया जा सकता है. ब्रैंच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
build_file	लेबल; ज़रूरी नहीं इस रिपॉज़िटरी के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट एक एब्सोल्यूट लेबल है. मुख्य रिपॉज़िटरी के लिए, '@//' का इस्तेमाल करें. फ़ाइल का नाम BUILD होना ज़रूरी नहीं है. हालांकि, इसे 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 पर लागू किए जाने वाले Powershell निर्देशों का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Pat_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_tool	स्ट्रिंग; वैकल्पिक इस्तेमाल करने के लिए पैच(1) की सुविधा. अगर यह जानकारी दी गई है, तो Bazel, Bazel के पैच लागू करने के बजाय, बताए गए पैच टूल का इस्तेमाल करेगा.
patches	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने का तरीका इस्तेमाल करता है. यह फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट की वैल्यू दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट है, तो Bazel पैच कमांड लाइन टूल का इस्तेमाल करेगा.
recursive_init_submodules	बूलियन; ज़रूरी नहीं डेटा स्टोर करने की जगह में सब-मोड्यूल को बार-बार क्लोन करना है या नहीं.
remote	स्ट्रिंग; ज़रूरी है रिमोट Git रिपॉज़िटरी का यूआरआई
repo_mapping	डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम में बदलने वाली डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि इस रिपॉज़िटरी में, किसी भी समय `@foo` पर निर्भरता हो सकती है. जैसे, `@foo//some:target` पर निर्भरता. यह असल में, दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में उस निर्भरता को हल करनी चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम नहीं करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन में रिपॉज़िटरी नियम को लागू किया जाता है.
shallow_since	स्ट्रिंग; ज़रूरी नहीं यह तारीख ज़रूरी नहीं है. यह तय की गई कमिट के बाद की नहीं होनी चाहिए. अगर कोई टैग या शाखा तय की गई है, तो इस आर्ग्युमेंट की अनुमति नहीं है. --depth=1 का इस्तेमाल करके, शाखा को हमेशा क्लोन किया जा सकता है. तय किए गए कमिट के करीब की तारीख सेट करने पर, रिपॉज़िटरी का शॉर्ट क्लोन बनाया जा सकता है. भले ही, सर्वर किसी भी कमिट के शॉर्ट फ़ेच के साथ काम न करता हो. git के --shallow-since लागू करने में गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा करने पर, फ़ेच करने में समस्याएं आ सकती हैं.
strip_prefix	स्ट्रिंग; ज़रूरी नहीं निकाली गई फ़ाइलों से हटाने के लिए, डायरेक्ट्री का प्रीफ़िक्स.
tag	स्ट्रिंग; ज़रूरी नहीं टैग को रिमोट रिपॉज़िटरी में चेक आउट किया गया है. ब्रैंच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
verbose	बूलियन; ज़रूरी नहीं
workspace_file	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` में से किसी एक का इस्तेमाल किया जा सकता है. इसके अलावा, दोनों का इस्तेमाल नहीं किया जा सकता.
workspace_file_content	स्ट्रिंग; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` में से किसी एक का इस्तेमाल किया जा सकता है. इसके अलावा, दोनों का इस्तेमाल नहीं किया जा सकता.

new_git_repository

load("@bazel//tools/build_defs/repo:git.bzl", "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 रिपॉज़िटरी को क्लोन करता है, बताए गए टैग की जांच करता है या कमिट करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. साथ ही, असल में चेक आउट किए गए कमिट का आईडी और उसकी तारीख भी तय करें. साथ ही, पैरामीटर के साथ एक डिक्शनरी दिखाएं, जो इस नियम का ऐसा वर्शन देती हो जिसे फिर से बनाया जा सके. हालांकि, यह ज़रूरी नहीं है कि यह एक टैग हो.

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 रखा जा सकता है. जैसे, 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 पर लागू किए जाने वाले Powershell निर्देशों का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Pat_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_tool	स्ट्रिंग; वैकल्पिक इस्तेमाल करने के लिए पैच(1) की सुविधा. अगर यह जानकारी दी गई है, तो Bazel, Bazel के पैच लागू करने के बजाय, बताए गए पैच टूल का इस्तेमाल करेगा.
patches	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह को निकालने के बाद, पैच के तौर पर लागू करना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने का तरीका इस्तेमाल करता है. यह फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट की वैल्यू दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट है, तो Bazel पैच कमांड लाइन टूल का इस्तेमाल करेगा.
recursive_init_submodules	बूलियन; ज़रूरी नहीं डेटा स्टोर करने की जगह में सब-मोड्यूल को बार-बार क्लोन करना है या नहीं.
remote	स्ट्रिंग; ज़रूरी है रिमोट Git रिपॉज़िटरी का यूआरआई
repo_mapping	डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम में बदलने वाली डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि इस रिपॉज़िटरी में, किसी भी समय `@foo` पर निर्भरता हो सकती है. जैसे, `@foo//some:target` पर निर्भरता. यह असल में, दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में उस निर्भरता को हल करनी चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम नहीं करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन में रिपॉज़िटरी नियम को लागू किया जाता है.
shallow_since	स्ट्रिंग; ज़रूरी नहीं यह तारीख ज़रूरी नहीं है. यह तय की गई कमिट के बाद की नहीं होनी चाहिए. अगर कोई टैग या शाखा तय की गई है, तो इस आर्ग्युमेंट की अनुमति नहीं है. --depth=1 का इस्तेमाल करके, शाखा को हमेशा क्लोन किया जा सकता है. तय किए गए कमिट के करीब की तारीख सेट करने पर, रिपॉज़िटरी का शॉर्ट क्लोन बनाया जा सकता है. भले ही, सर्वर किसी भी कमिट के शॉर्ट फ़ेच के साथ काम न करता हो. git के --shallow-since लागू करने में गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा करने पर, फ़ेच करने में समस्याएं आ सकती हैं.
strip_prefix	स्ट्रिंग; ज़रूरी नहीं निकाली गई फ़ाइलों से हटाने के लिए, डायरेक्ट्री का प्रीफ़िक्स.
tag	स्ट्रिंग; ज़रूरी नहीं टैग को रिमोट रिपॉज़िटरी में चेक आउट किया गया है. ब्रैंच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
verbose	बूलियन; ज़रूरी नहीं
workspace_file	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.
workspace_file_content	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` में से किसी एक का इस्तेमाल किया जा सकता है. इसके अलावा, दोनों का इस्तेमाल नहीं किया जा सकता.