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