@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 हो. हालांकि, ऐसा किया जा सकता है. जैसे, 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 के अलावा अन्य तर्क दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; ज़रूरी नहीं
पैच लागू होने के बाद, Linux/Macos पर लागू की जाने वाली Bash कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; ज़रूरी नहीं
पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को चलाया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; ज़रूरी नहीं
इस्तेमाल की जाने वाली patch(1) यूटिलिटी. अगर इसकी जानकारी दी जाती है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `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 फ़ाइल का कॉन्टेंट. `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.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 के अलावा अन्य तर्क दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा. |
patch_cmds |
स्ट्रिंग की सूची; ज़रूरी नहीं
पैच लागू होने के बाद, Linux/Macos पर लागू की जाने वाली Bash कमांड का क्रम. |
patch_cmds_win |
स्ट्रिंग की सूची; ज़रूरी नहीं
पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को चलाया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है. |
patch_tool |
स्ट्रिंग; ज़रूरी नहीं
इस्तेमाल की जाने वाली patch(1) यूटिलिटी. अगर इसकी जानकारी दी जाती है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा. |
patches |
लेबल की सूची; ज़रूरी नहीं
यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `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 फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है. |