Bundlers proxynedladdningar fungerar, men ett Git-beroende misslyckas
Gem-nedladdningar och Git-baserade beroenden kan använda olika nätverksklienter och transporter. Identifiera Git-URL:en innan du ändrar Bundlers fungerande proxyväg.
Om bundle install laddar ner gem och sedan stannar vid ett Git-beroende, undersök källan till det beroendet. De lyckade nedladdningarna bevisar bara vägen som användes för dem.
- Läs den faktiska Git-URL:en i Gemfile eller lockfile. HTTPS, SSH och
git://kräver olika anslutningar. Historiska Bundler-förkortningar kan dölja engit://-URL i en kort deklaration. - Granska det Git-anrop som bygget använder. Jämför dess faktiska konfiguration, miljö och konto med ett fungerande terminalanrop. En byggagent eller ett privilegierat kommando kan se andra indata.
- Följ den valda transporten. För en auktoriserad HTTPS-källa kan inbyggda Gits stödda HTTP-proxykonfiguration gälla. Använd organisationens stödda SSH-väg för SSH. En HTTP-proxyinställning konfigurerar inte varje transport som Bundler kan starta.
För en offentlig HTTPS Git-källa som tillåter offentliga mellanhänder erbjuder HTTP-proxylistan kandidatslutpunkter för den Git-konfigurationen.
Klassificera nu felet. En 407 gäller åtkomst till mellanhanden. Ett privat repositories behörighetsfel efter en lyckad tunnel gäller dess separata konto eller nyckel. Håll proxyuppgifter utanför Gemfile och committede käll-URL:er; dessa deklarationer delas med projektanvändare vars nätverksinställningar kan skilja sig.
Ersätt inte en fungerande proxy och redigera inte ett domänkvalificerat konto bara för att en orelaterad lösning rekommenderar det. Slutförande innebär att hämta den specifika Git-källan via den avsedda vägen. Att upprepa de redan lyckade gem-nedladdningarna lämnar det felet otestat.