Hvor Gradle henter proxyinnstillingene sine

Følg Gradles JVM-proxyegenskaper, innstillinger i brukerens hjemmekatalog og klientmiljøet i stedet for å anta at daemonen alltid ignorerer nye variabler.

Et Gradle-bygg startet fra en IDE kan bruke en annen konfigurasjon enn det samme prosjektet startet fra en terminal. Sammenlign Gradles brukerhjem, JVM og proxyegenskaper for hver start før du skylder på en foreldet proxyprosess.

Gradle dokumenterer JVM-proxyegenskaper

For HTTP- og HTTPS-ruter kan en egenskapsfil inneholde:

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

Bruk det tildelte endepunktet; for tillatte ruter til offentlige repositorier gir HTTP-proxylisten mulige verts- og portpar. HTTPS-omgåelsesegenskapen er også http.nonProxyHosts; å finne opp https.nonProxyHosts er ikke den dokumenterte løsningen. Vertsegenskapene inneholder en adresse, ikke en full proxy-URL.

Å eksportere HTTP_PROXY i et skall beviser ikke i seg selv at denne JVM-klienten bruker den som sin proxypolicy. Sjekk egenskapene programmet støtter.

Daemonen mottar faktisk byggeinformasjon

Gjeldende Gradle-dokumentasjon sier at klienten sender byggeinformasjon, inkludert miljøvariabler, til daemonen. Derfor er den generelle forklaringen «daemonen mottar aldri nye miljøvariabler» unøyaktig.

Noen JVM-oppstartsegenskaper, blant annet egenskaper for tillitslageret, er uforanderlige for en JVM som kjører. Et endret Java-hjem eller en endret oppstartskonfigurasjon for tillitslageret kan derfor ha betydning selv når vanlige miljøverdier for bygget sendes videre.

Sammenlign de to oppstartene

Sjekk hvilken Gradle-distribusjon og Java-runtime IDE-en velger. Sjekk om den bruker samme GRADLE_USER_HOME og brukeregenskaper som terminalen. En proxyoppføring i én brukers konfigurasjon viser ikke hva en annen kontekst lastet inn.

Hvis et endret oppstartskrav trenger en annen daemon, bruker du de dokumenterte daemon-kontrollene for den aktuelle Gradle-versjonen. Ikke se på å stoppe daemons som en erstatning for å finne en feil egenskap eller manglende konfigurasjonsfil.

Finn til slutt forespørselen som mislyktes. Wrapper-nedlastinger, løsning av byggeavhengigheter og forespørsler fra forgrenede applikasjons- eller testprosesser er ikke automatisk én nettverkskontekst. Kontroller prosessen som gjør forespørselen før du forventer at en Gradle-egenskap styrer den.

Relaterte artikler