Varifrån Gradle hämtar sina proxyinställningar

Följ Gradles JVM-proxyegenskaper, användarens hemkatalogsinställningar och klientmiljön i stället för att anta att daemonen alltid ignorerar nya variabler.

Ett Gradle-bygge som startas från en IDE kan använda en annan konfiguration än samma projekt som startas från en terminal. Jämför Gradles användarhem, JVM och proxyegenskaper för varje start innan du skyller på en gammal proxyprocess.

Gradle dokumenterar JVM-proxyegenskaper

För HTTP- och HTTPS-rutter kan en egenskapsfil innehålla:

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

Använd den tilldelade slutpunkten; för tillåtna rutter till offentliga arkiv ger HTTP-proxylistan möjliga värd- och portpar. HTTPS-undantagsegenskapen är också http.nonProxyHosts; att hitta på https.nonProxyHosts är inte den dokumenterade lösningen. Värdegenskaperna innehåller en adress, inte en fullständig proxy-URL.

Att exportera HTTP_PROXY i ett skal bevisar inte i sig att denna JVM-klient använder den som proxypolicy. Kontrollera de egenskaper som programmet stöder.

Daemonen tar emot bygginformation

Aktuell Gradle-dokumentation säger att klienten skickar bygginformation, inklusive miljövariabler, till daemonen. Därför är den generella förklaringen ”daemonen tar aldrig emot nya miljövariabler” felaktig.

Vissa JVM-startsegenskaper, bland annat egenskaper för förtroendelagret, är oföränderliga för en körande JVM. Ett ändrat Java home eller en ändrad startkonfiguration för förtroendelagret kan därför spela roll även när vanliga byggmiljövärden skickas vidare.

Jämför de två starterna

Kontrollera vilken Gradle-distribution och Java-runtime IDE:n väljer. Kontrollera om den använder samma GRADLE_USER_HOME och användaregenskaper som terminalen. En proxy-post i en användares konfiguration visar inte vad en annan kontext läste in.

Om ett ändrat startkrav behöver en annan daemon använder du de dokumenterade daemon-kontrollerna för den berörda Gradle-versionen. Se inte stoppade daemons som ersättning för att hitta en felaktig egenskap eller saknad konfigurationsfil.

Identifiera slutligen begäran som misslyckades. Wrapper-nedladdningar, lösning av byggberoenden och begäranden från förgrenade program- eller testprocesser är inte automatiskt samma nätverkskontext. Kontrollera processen som gör begäran innan du förväntar dig att en Gradle-egenskap styr den.

Relaterade artiklar