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

समस्या की शिकायत करें सोर्स देखें

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इन फ़ंक्शन को @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_strip, 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 देखें.

ATTRIBUTES

name	नाम; ज़रूरी है इस रिपॉज़िटरी के लिए यूनीक नाम.
branch	स्ट्रिंग; ज़रूरी नहीं ब्रांच को रिमोट रिपॉज़िटरी में चेक आउट किया गया है. ब्रांच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
build_file	लेबल; ज़रूरी नहीं है इस रिपॉज़िटरी के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट, ऐब्सलूट लेबल है. मुख्य रिपॉज़िटरी के लिए '@//' का इस्तेमाल करें. यह ज़रूरी नहीं है कि फ़ाइल का नाम BUILD हो. हालांकि, ऐसा किया जा सकता है. जैसे, BUILD.new-repo-name का इस्तेमाल करने से, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में मदद मिल सकती है.
build_file_content	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट.
commit	स्ट्रिंग; ज़रूरी नहीं जांच के लिए कोई खास कमिट. ब्रांच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
init_submodules	बूलियन; ज़रूरी नहीं डेटा स्टोर करने की जगह में सबमॉड्यूल का क्लोन बनाना है या नहीं.
patch_args	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए तर्क. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. `patch_strip` एट्रिब्यूट देखें. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होती है. अगर कई -p आर्ग्युमेंट दिए गए हैं, तो आखिरी आर्ग्युमेंट लागू होगा.अगर -p के अलावा अन्य आर्ग्युमेंट दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा.
patch_cmds	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/macOS पर लागू की जाने वाली Bash कमांड का क्रम.
patch_cmds_win	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को एक्ज़ीक्यूट किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_strip	पूर्णांक; ज़रूरी नहीं इसे `N` पर सेट करने का मतलब है कि `patch_args` की शुरुआत में `-pN` डाला गया है.
patch_tool	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) यूटिलिटी. अगर इसे तय किया जाता है, तो Bazel, Bazel के नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा.
patches	लेबल की सूची; ज़रूरी नहीं यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `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` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है.
workspace_file_content	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `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_strip, 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 देखें.

ATTRIBUTES

name	नाम; ज़रूरी है इस रिपॉज़िटरी के लिए यूनीक नाम.
branch	स्ट्रिंग; ज़रूरी नहीं ब्रांच को रिमोट रिपॉज़िटरी में चेक आउट किया गया है. ब्रांच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
build_file	लेबल; ज़रूरी नहीं है इस रिपॉज़िटरी के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट, ऐब्सलूट लेबल है. मुख्य रिपॉज़िटरी के लिए '@//' का इस्तेमाल करें. यह ज़रूरी नहीं है कि फ़ाइल का नाम BUILD हो. हालांकि, ऐसा किया जा सकता है. जैसे, BUILD.new-repo-name का इस्तेमाल करने से, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में मदद मिल सकती है.
build_file_content	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट.
commit	स्ट्रिंग; ज़रूरी नहीं जांच के लिए कोई खास कमिट. ब्रांच, टैग या कमिट में से किसी एक की जानकारी देना ज़रूरी है.
init_submodules	बूलियन; ज़रूरी नहीं डेटा स्टोर करने की जगह में सबमॉड्यूल का क्लोन बनाना है या नहीं.
patch_args	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए तर्क. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. `patch_strip` एट्रिब्यूट देखें. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होती है. अगर कई -p आर्ग्युमेंट दिए गए हैं, तो आखिरी आर्ग्युमेंट लागू होगा.अगर -p के अलावा अन्य आर्ग्युमेंट दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा.
patch_cmds	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/macOS पर लागू की जाने वाली Bash कमांड का क्रम.
patch_cmds_win	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को एक्ज़ीक्यूट किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_strip	पूर्णांक; ज़रूरी नहीं इसे `N` पर सेट करने का मतलब है कि `patch_args` की शुरुआत में `-pN` डाला गया है.
patch_tool	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) यूटिलिटी. अगर इसे तय किया जाता है, तो Bazel, Bazel के नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा.
patches	लेबल की सूची; ज़रूरी नहीं यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `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` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है.
workspace_file_content	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है.