Bundler प्रॉक्सी डाउनलोड काम करते हैं, पर एक Git निर्भरता विफल हो जाती है
Gem डाउनलोड और Git-आधारित निर्भरताएँ अलग-अलग नेटवर्क क्लाइंट और ट्रांसपोर्ट का उपयोग कर सकती हैं। Bundler का कार्यशील प्रॉक्सी मार्ग बदलने से पहले Git URL पहचानें।
यदि bundle install gem डाउनलोड करता है और फिर किसी Git निर्भरता पर रुक जाता है, तो उस निर्भरता के स्रोत की जाँच करें। सफल डाउनलोड केवल उन डाउनलोड के लिए उपयोग किए गए मार्ग को सिद्ध करते हैं।
- Gemfile या lockfile में वास्तविक Git URL पढ़ें। HTTPS, SSH और
git://को अलग-अलग कनेक्शन चाहिए। पुराने Bundler शॉर्टकट किसी छोटी घोषणा मेंgit://URL छिपा सकते हैं। - बिल्ड द्वारा उपयोग किया गया Git आमंत्रण जाँचें। इसके प्रभावी कॉन्फ़िगरेशन, वातावरण और खाते की तुलना किसी काम करने वाले टर्मिनल आमंत्रण से करें। बिल्ड एजेंट या विशेषाधिकार वाला कमांड अलग इनपुट देख सकता है।
- चुने गए ट्रांसपोर्ट का पालन करें। अधिकृत HTTPS स्रोत के लिए मूल Git का समर्थित HTTP प्रॉक्सी कॉन्फ़िगरेशन लागू हो सकता है। SSH के लिए संगठन का समर्थित SSH मार्ग उपयोग करें। HTTP प्रॉक्सी सेटिंग वह हर ट्रांसपोर्ट कॉन्फ़िगर नहीं करती जिसे Bundler शुरू कर सकता है।
ऐसे सार्वजनिक HTTPS Git स्रोत के लिए जो सार्वजनिक मध्यस्थों की अनुमति देता है, HTTP प्रॉक्सी सूची उस Git कॉन्फ़िगरेशन के लिए संभावित एंडपॉइंट देती है।
अब त्रुटि का वर्गीकरण करें। 407 मध्यस्थ तक पहुँच से संबंधित है। टनल सफल होने के बाद निजी रिपॉज़िटरी की अनुमति त्रुटि उसके अलग खाते या कुंजी से संबंधित है। प्रॉक्सी क्रेडेंशियल को Gemfile और कमिट किए गए स्रोत URL से बाहर रखें; वे घोषणाएँ उन प्रोजेक्ट उपयोगकर्ताओं के साथ साझा होती हैं जिनकी नेटवर्क सेटिंग अलग हो सकती है।
केवल इसलिए कि कोई असंबंधित समाधान इसकी सिफ़ारिश करता है, काम करने वाला प्रॉक्सी न बदलें और न ही डोमेन-योग्य खाते को संपादित करें। पूर्ण होने का अर्थ है विशिष्ट Git स्रोत को इच्छित मार्ग से लाना। पहले से सफल gem डाउनलोड दोहराने से वह विफलता अपरीक्षित रह जाती है।