Hvor Gradle henter sine proxyindstillinger

Følg Gradles JVM-proxyegenskaber, brugerens hjemindstillinger og klientmiljø i stedet for at antage, at dæmonen altid ignorerer nye variabler.

Et Gradle-build, der startes fra et IDE, kan bruge en anden konfiguration end det samme projekt startet fra en terminal. Sammenlign Gradles brugerhjem, JVM og proxyegenskaber for hver start, før du giver en gammel proxyproces skylden.

Gradle dokumenterer JVM-proxyegenskaber

En egenskabsfil til HTTP- og HTTPS-ruter kan indeholde:

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

Brug det tildelte slutpunkt; til tilladte ruter til offentlige arkiver giver HTTP-proxylisten mulige vært-og-port-par. Egenskaben til HTTPS-omgåelse er også http.nonProxyHosts; det er ikke den dokumenterede løsning at opfinde https.nonProxyHosts. Værtegenskaber indeholder en adresse, ikke en fuld proxy-URL.

At eksportere HTTP_PROXY i en shell beviser ikke i sig selv, at denne JVM-klient bruger den som sin proxypolitik. Kontroller de egenskaber, programmet understøtter.

Dæmonen modtager faktisk buildoplysninger

Den aktuelle Gradle-dokumentation siger, at klienten sender buildoplysninger, herunder miljøvariabler, til dæmonen. Derfor er forklaringen “dæmonen modtager aldrig nye miljøvariabler” upræcis som en generel regel.

Nogle JVM-start-egenskaber, herunder trust-store-egenskaber, er uforanderlige for en kørende JVM. Et ændret Java-hjem eller en ændret startkonfiguration for trust store kan derfor have betydning, selv når almindelige buildmiljøværdier sendes videre.

Sammenlign de to starter

Kontroller hvilken Gradle-distribution og Java-runtime IDE’et vælger. Kontroller, om det bruger samme GRADLE_USER_HOME og brugeregenskaber som terminalen. En proxyindstilling i én brugers konfiguration viser ikke, hvad en anden kontekst indlæste.

Hvis et ændret startkrav behøver en anden dæmon, skal du bruge de dokumenterede dæmonkontroller for den pågældende Gradle-version. Se ikke stop af dæmoner som en erstatning for at finde en forkert egenskab eller en manglende konfigurationsfil.

Find til sidst den forespørgsel, der mislykkedes. Wrapper-downloads, løsning af buildafhængigheder og forespørgsler fra forgrenede program- eller testprocesser er ikke automatisk én netværkskontekst. Kontrollér processen, der foretager forespørgslen, før du forventer, at en Gradle-egenskab styrer den.

Relaterede artikler