যদি bundle install gem ডাউনলোড করে তারপর একটি Git নির্ভরতায় থেমে যায়, তবে সেই নির্ভরতার উৎস পরীক্ষা করুন। সফল ডাউনলোডগুলি কেবল সেই ডাউনলোডগুলির জন্য ব্যবহৃত পথটিই প্রতিষ্ঠা করে।

  1. Gemfile বা lockfile-এ প্রকৃত Git URL পড়ুন। HTTPS, SSH এবং git:// ভিন্ন সংযোগ প্রয়োজন। পুরনো Bundler শর্টকাট একটি সংক্ষিপ্ত ঘোষণায় git:// URL লুকাতে পারে।
  2. বিল্ড যে Git আহ্বান ব্যবহার করে তা পরীক্ষা করুন। এর কার্যকর কনফিগারেশন, পরিবেশ ও অ্যাকাউন্ট একটি কার্যকর টার্মিনাল আহ্বানের সঙ্গে তুলনা করুন। বিল্ড এজেন্ট বা বিশেষাধিকারপ্রাপ্ত কমান্ড ভিন্ন ইনপুট দেখতে পারে।
  3. নির্বাচিত ট্রান্সপোর্ট অনুসরণ করুন। অনুমোদিত HTTPS উৎসের জন্য নেটিভ Git-এর সমর্থিত HTTP প্রক্সি কনফিগারেশন প্রযোজ্য হতে পারে। SSH-এর জন্য সংস্থার সমর্থিত SSH পথ ব্যবহার করুন। HTTP প্রক্সি সেটিং Bundler যে প্রতিটি ট্রান্সপোর্ট শুরু করতে পারে তা কনফিগার করে না।

পাবলিক মধ্যস্থতাকারী অনুমোদন করে এমন পাবলিক HTTPS Git উৎসের জন্য HTTP প্রক্সি তালিকা সেই Git কনফিগারেশনের জন্য প্রার্থী এন্ডপয়েন্ট দেয়।

এখন ত্রুটিটি শ্রেণিবদ্ধ করুন। 407 মধ্যস্থতাকারীতে প্রবেশাধিকার সম্পর্কে। টানেল সফল হওয়ার পর একটি ব্যক্তিগত ভান্ডারের অনুমতি ত্রুটি তার পৃথক অ্যাকাউন্ট বা কী সম্পর্কে। প্রক্সি শংসাপত্র Gemfile ও কমিট করা উৎস URL-এর বাইরে রাখুন; ওই ঘোষণাগুলি এমন প্রকল্প ব্যবহারকারীদের সঙ্গে ভাগ করা হয় যাদের নেটওয়ার্ক সেটিং ভিন্ন হতে পারে।

শুধু একটি অসম্পর্কিত সমাধান সুপারিশ করছে বলে কার্যকর প্রক্সি প্রতিস্থাপন করবেন না বা ডোমেইন-যোগ্য অ্যাকাউন্ট সম্পাদনা করবেন না। সমাপ্তি মানে নির্দিষ্ট Git উৎসটি অভীষ্ট পথে আনা। ইতিমধ্যে সফল gem ডাউনলোড পুনরাবৃত্তি করলে সেই ব্যর্থতা অপরীক্ষিত থেকে যায়।

সম্পর্কিত নিবন্ধ