Cargo reģistra lejupielādes darbojas, bet Git atkarības neizdodas

Atdaliet Cargo reģistra HTTP ceļu no Git avotu iegūšanas un apzināti izvēlieties Git implementāciju, ja starpniekservera uzvedība atšķiras.

Pirms maināt Cargo starpniekserveri, izlasiet neizdevušā avota URL. Reģistra metadati, crate arhīvs un Git atkarība var izmantot atšķirīgus iegūšanas un autentifikācijas ceļus. SSH Git URL ir nepieciešams arī cits transporta izkārtojums nekā HTTPS.

Cargo atbilstošajiem HTTP pieprasījumiem maršrutu var iestatīt šādi:

[http]
proxy = "http://203.0.113.10:8080"

Dokumentācijas endpoint aizstājiet ar savu HTTP starpniekserveri. Publiskam reģistra ceļam, kurā atļauts izmantot publiskus starpniekserverus, kandidāti ir HTTP starpniekserveru sarakstā. Tas nepierāda, ka ārējais Git izpildfails saņēma tādu pašu konfigurāciju.

Ja neizdevies avots ir Git, Cargo var izvēlēties Git CLI, nevis iebūvēto implementāciju:

[net]
git-fetch-with-cli = true

CARGO_NET_GIT_FETCH_WITH_CLI=true to izvēlas vienai komandai. Ārējam Git tagad nepieciešama sava starpniekservera konfigurācija un akreditācijas dati. Salīdziniet to pašu Git URL tajā pašā palaišanas vidē; nesaistīts repozitorijs, kas darbojas citā terminālī, nav tests.

Trūkstoša revīzija, liegtas repozitorija atļaujas vai SSH host-key kļūda pēc implementācijas maiņas joprojām ir tā pati problēma. Šī opcija izvēlas atbalstītu klientu, nevis vispārēji labo atkarības.

Saglabājiet diagnostiku projekta vai komandas tvērumā: globālie Git un lietotāja Cargo iestatījumi var ietekmēt citas darba telpas. Reģistra URL izvēlas pakotnes datus, nevis starpnieku. Kad Git ceļš darbojas, vēlreiz palaidiet visu paredzēto Cargo darbību, jo arhīvi, pāradresācijas un būvēšanas lejupielādes var ieviest citus ceļus.

Saistītie raksti