Si bundle install télécharge des gems puis s'arrête sur une dépendance Git, examinez la source de cette dépendance. Les téléchargements réussis n'établissent que l'itinéraire utilisé pour ces téléchargements.

  1. Lisez l'URL Git réelle dans le Gemfile ou le lockfile. HTTPS, SSH et git:// nécessitent des connexions différentes. Les anciens raccourcis de Bundler peuvent masquer une URL git:// dans une déclaration courte.
  2. Inspectez l'appel Git utilisé par le build. Comparez sa configuration effective, son environnement et son compte avec un appel fonctionnel dans un terminal. Un agent de build ou une commande privilégiée peut voir des entrées différentes.
  3. Suivez le transport sélectionné. Pour une source HTTPS autorisée, la configuration de proxy HTTP prise en charge de Git natif peut s'appliquer. Pour SSH, utilisez l'itinéraire SSH pris en charge par l'organisation. Un réglage de proxy HTTP ne configure pas tous les transports que Bundler peut lancer.

Pour une source Git HTTPS publique qui autorise des intermédiaires publics, la liste de proxys HTTP propose des points de terminaison candidats pour cette configuration Git.

Classez maintenant l'erreur. Un 407 concerne l'accès à l'intermédiaire. L'erreur de permission d'un dépôt privé après la réussite d'un tunnel concerne son compte ou sa clé distincts. Gardez les identifiants du proxy hors du Gemfile et des URL de source commitées ; ces déclarations sont partagées avec les utilisateurs du projet dont les paramètres réseau peuvent différer.

Ne remplacez pas un proxy fonctionnel et ne modifiez pas un compte qualifié par domaine simplement parce qu'une solution de contournement sans rapport le recommande. Terminer signifie récupérer la source Git précise par l'itinéraire prévu. Répéter les téléchargements de gems déjà réussis laisse cet échec non testé.

Articles similaires