Cargo-registrydownloads werken, maar Git-afhankelijkheden mislukken

Scheid Cargos HTTP-pad voor de registry van het ophalen van Git-bronnen en kies bewust een Git-implementatie wanneer het proxygedrag verschilt.

Lees de URL van de mislukte bron voordat je Cargos proxy wijzigt. Registrymetadata, een crate-archief en een Git-afhankelijkheid kunnen verschillende paden voor ophalen en authenticatie gebruiken. Een SSH Git-URL heeft ook een andere transportinrichting nodig dan HTTPS.

Voor de relevante HTTP-verzoeken van Cargo kan de route zo worden ingesteld:

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

Vervang het documentatie-endpoint door je HTTP-proxy. Voor een openbare registryroute waarvoor openbare proxy's zijn toegestaan, staan kandidaten in de HTTP-proxylijst. Dit bewijst niet dat een extern Git-programma dezelfde configuratie heeft ontvangen.

Als de mislukte bron Git is, kan Cargo de Git CLI kiezen in plaats van de ingebouwde implementatie:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true kiest die voor één opdracht. De externe Git heeft nu een eigen proxyconfiguratie en inloggegevens nodig. Vergelijk dezelfde Git-URL in dezelfde startomgeving; een niet-gerelateerde repository die in een andere terminal werkt is niet de test.

Een ontbrekende revisie, geweigerde repositorytoegang of SSH-hostkeyfout blijft hetzelfde probleem na het wisselen van implementatie. De optie kiest een ondersteunde client en repareert afhankelijkheden niet algemeen.

Houd de diagnose binnen de project- of opdrachtscope: globale Git-instellingen en Cargo-instellingen van de gebruiker kunnen andere werkruimten beïnvloeden. Een registry-URL kiest pakketgegevens, geen tussenpersoon. Voer de volledige bedoelde Cargo-bewerking opnieuw uit zodra het Git-pad werkt, want archieven, omleidingen en downloads tijdens het bouwen kunnen andere routes toevoegen.

Gerelateerde artikelen