Kvar Gradle får proxyinnstillingane sine frå

Følg Gradle sine JVM-proxyegenskapar, innstillingane i brukarheimen og klientmiljøet i staden for å gå ut frå at daemonen alltid ignorerer nye variablar.

Eit Gradle-bygg som blir starta frå ein IDE, kan bruke ei anna konfigurasjon enn det same prosjektet starta frå ein terminal. Samanlikn Gradle-brukarheimen, JVM-en og proxyegenskapane for kvar start før du skulder på ein forelda proxyprosess.

Gradle dokumenterer JVM-proxyegenskapar

For HTTP- og HTTPS-ruter kan ei eigenskapsfil innehalde:

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 tillatne ruter til offentlege repository gir HTTP-proxylista moglege par av vert og port. Eigenskapen for å gå utanom HTTPS er òg http.nonProxyHosts; å finne på https.nonProxyHosts er ikkje den dokumenterte løysinga. Vertseigenskapane inneheld ei adresse, ikkje ein full proxy-URL.

Å eksportere HTTP_PROXY i eit skal er ikkje i seg sjølv prov på at denne JVM-klienten bruker det som proxyregel. Sjekk eigenskapane programmet støttar.

Daemonen får byggjeinformasjon

Gjeldande Gradle-dokumentasjon seier at klienten sender byggjeinformasjon, medrekna miljøvariablar, til daemonen. Difor er den generelle forklaringa «daemonen får aldri nye miljøvariablar» unøyaktig.

Nokre JVM-startseigenskapar, mellom anna eigenskapar for tillitslageret, kan ikkje endrast for ein JVM som køyrer. Eit endra Java-home eller ei endra oppstartskonfigurasjon for tillitslageret kan difor ha noko å seie sjølv når vanlege miljøverdiar frå bygget blir sende vidare.

Samanlikn dei to startane

Sjekk kva for Gradle-distribusjon og Java-køyretid IDE-en vel. Sjekk om han bruker same GRADLE_USER_HOME og brukareigenskapar som terminalen. Ei proxyoppføring i konfigurasjonen til éin brukar viser ikkje kva ein annan kontekst lasta.

Viss eit endra oppstartskrav treng ein annan daemon, bruker du dei dokumenterte daemonkontrollane for den aktuelle Gradle-versjonen. Ikkje sjå på å stoppe daemonar som ein erstatning for å finne ein feil eigenskap eller ei manglande konfigurasjonsfil.

Finn til slutt førespurnaden som feila. Wrapper-nedlastingar, løysing av byggjeavhengnader og førespurnader frå forgreina program- eller testprosessar er ikkje automatisk éin nettverkskontekst. Kontroller prosessen som gjer førespurnaden før du ventar at ein Gradle-eigenskap skal styre han.

Relaterte artiklar