Waar Gradle zijn proxy-instellingen vandaan haalt

Volg Gradles JVM-proxy-eigenschappen, gebruikershoofdmap en clientomgeving in plaats van aan te nemen dat de daemon nieuwe variabelen altijd negeert.

Een Gradle-build die vanuit een IDE wordt gestart, kan een andere configuratie gebruiken dan hetzelfde project vanuit een terminal. Vergelijk de Gradle-gebruikershoofdmap, JVM en proxy-eigenschappen van elke start voordat je een oud proxyproces de schuld geeft.

Gradle documenteert JVM-proxy-eigenschappen

Voor HTTP- en HTTPS-routes kan een eigenschappenbestand het volgende bevatten:

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

Gebruik het toegewezen eindpunt; voor toegestane routes naar openbare repositories levert de HTTP-proxylijst kandidaatparen van host en poort. De eigenschap voor HTTPS-omzeiling is ook http.nonProxyHosts; https.nonProxyHosts verzinnen is niet de gedocumenteerde oplossing. Host-eigenschappen bevatten een adres, geen volledige proxy-URL.

HTTP_PROXY exporteren in een shell bewijst op zichzelf niet dat deze JVM-client het als proxybeleid gebruikt. Controleer de eigenschappen die de toepassing ondersteunt.

De daemon ontvangt wel buildinformatie

De huidige Gradle-documentatie zegt dat de client buildinformatie, inclusief omgevingsvariabelen, naar de daemon stuurt. De algemene uitleg ‘de daemon ontvangt nooit nieuwe omgevingsvariabelen’ klopt dus niet.

Sommige JVM-start-eigenschappen, waaronder truststore-eigenschappen, zijn onveranderlijk voor een draaiende JVM. Een gewijzigde Java-home of truststore-startconfiguratie kan daarom van belang zijn, ook als gewone buildomgevingswaarden worden doorgegeven.

Vergelijk de twee starts

Controleer welke Gradle-distributie en Java-runtime de IDE kiest. Controleer of die dezelfde GRADLE_USER_HOME en gebruikerseigenschappen gebruikt als de terminal. Een proxyvermelding in de configuratie van één gebruiker zegt niet wat een andere context heeft geladen.

Als een gewijzigde startvereiste een andere daemon nodig heeft, gebruik dan de gedocumenteerde daemonbesturing voor de betreffende Gradle-versie. Beschouw daemons stoppen niet als vervanging voor het vinden van een verkeerde eigenschap of ontbrekend configuratiebestand.

Bepaal ten slotte welk verzoek mislukte. Wrapper-downloads, het oplossen van buildafhankelijkheden en verzoeken van afgesplitste toepassings- of testprocessen vormen niet automatisch één netwerkcontext. Controleer welk proces het verzoek uitvoert voordat je verwacht dat een Gradle-eigenschap het bestuurt.

Gerelateerde artikelen