Bundler-ի պրոքսի ներբեռնումները աշխատում են, բայց Git կախվածությունը ձախողվում է

Gem ներբեռնումները և Git-ի վրա հիմնված կախվածությունները կարող են օգտագործել տարբեր ցանցային հաճախորդներ և փոխադրամիջոցներ: Նշեք Git URL-ը նախքան Bundler-ի աշխատող պրոքսի ուղին փոխելը:

Եթե bundle install-ը ներբեռնում է gem-երը և հետո կանգ է առնում Git կախվածության վրա, ուսումնասիրեք այդ կախվածության աղբյուրը: Հաջող ներբեռնումները հաստատում են միայն այդ ներբեռնումների համար օգտագործված ուղին:

  1. Կարդացեք փաստացի Git URL-ը Gemfile-ում կամ lockfile-ում: HTTPS-ը, SSH-ը և git://-ը տարբեր կապեր են պահանջում: Հին Bundler կրճատումները կարող են թաքցնել git:// URL-ը կարճ հայտարարության մեջ:
  2. Ուսումնասիրեք build-ի կողմից օգտագործվող Git կանչը: Համեմատեք դրա փաստացի կազմաձևը, միջավայրը և հաշիվը աշխատող տերմինալային կանչի հետ: Build գործակալը կամ արտոնյալ հրամանը կարող են տեսնել տարբեր մուտքեր:
  3. Հետևեք ընտրված փոխադրմանը: Թույլատրված HTTPS աղբյուրի համար կարող է կիրառվել native Git-ի աջակցվող HTTP պրոքսի կազմաձևը: SSH-ի համար օգտագործեք կազմակերպության աջակցվող SSH ուղին: HTTP պրոքսի կարգավորումը չի կարգավորում բոլոր փոխադրումները, որոնք Bundler-ը կարող է գործարկել:

Հանրային HTTPS Git աղբյուրի համար, որը թույլ է տալիս հանրային միջնորդների, HTTP պրոքսիների ցանկը առաջարկում է թեկնածու վերջնակետեր այդ Git կազմաձևի համար:

Այժմ դասակարգեք սխալը: 407-ը վերաբերում է միջնորդի հասանելիությանը: Մասնավոր պահոցի թույլտվության սխալը թունելի հաջողությունից հետո վերաբերում է դրա առանձին հաշվին կամ բանալուն: Պրոքսի հավատարմագրերը պահեք Gemfile-ից և commit արված աղբյուր URL-ներից դուրս. այդ հայտարարությունները կիսվում են նախագծի օգտատերերի հետ, ում ցանցային կարգավորումները կարող են տարբերվել:

Չփոխարինեք աշխատող պրոքսին և չխմբագրեք տիրույթով որակավորված հաշիվը միայն այն պատճառով, որ անկապ լուծում է դա խորհուրդ տալիս: Ավարտումը նշանակում է կոնկրետ Git աղբյուրը նախատեսված ուղով ստանալը: Արդեն հաջող gem ներբեռնումների կրկնումը թողնում է այդ ձախողումը չփորձարկված:

Առնչվող հոդվածներ