Откъде Gradle получава прокси настройките си

Проследете JVM прокси свойствата на Gradle, настройките на потребителската директория и средата на клиента, вместо да приемате, че daemon винаги игнорира новите променливи.

Gradle build, стартиран от IDE, може да използва различна конфигурация от същия проект, стартиран в терминал. Преди да обвините стар прокси процес, сравнете потребителската директория на Gradle, JVM и прокси свойствата при всяко стартиране.

Gradle документира JVM прокси свойствата

За HTTP и HTTPS маршрути файлът със свойства може да съдържа:

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

Използвайте зададения endpoint; за разрешени маршрути към публични хранилища списъкът с HTTP проксита дава възможни двойки хост и порт. Свойството за заобикаляне на HTTPS също е http.nonProxyHosts; измислянето на https.nonProxyHosts не е документирано решение. Свойствата на хоста съдържат адрес, а не пълен proxy URL.

Експортирането на HTTP_PROXY в shell само по себе си не доказва, че този JVM клиент го използва като прокси политика. Проверете свойствата, които приложението поддържа.

Daemon получава информация за build-а

Актуалната документация на Gradle казва, че клиентът изпраща на daemon информация за build-а, включително променливи на средата. Затова общото обяснение „daemon никога не получава нови променливи на средата“ е неточно.

Някои стартови свойства на JVM, включително свойствата на trust store, са неизменяеми за работеща JVM. Следователно променен Java home или стартова конфигурация на trust store може да има значение, дори когато обичайните стойности на средата се предават.

Сравнете двете стартирания

Проверете коя Gradle дистрибуция и Java среда избира IDE. Проверете дали използва същото GRADLE_USER_HOME и същите потребителски свойства като терминала. Прокси записът в конфигурацията на един потребител не показва какво е заредил друг контекст.

Ако променено изискване при стартиране изисква друг daemon, използвайте документираните контроли за съответната версия на Gradle. Не заменяйте търсенето на грешно свойство или липсващ конфигурационен файл със спиране на daemon-и.

Накрая определете коя заявка е неуспешна. Изтеглянията на Wrapper, разрешаването на build зависимости и заявките от разклонени процеси на приложение или тест не са автоматично един и същ мрежов контекст. Проверете процеса, който изпраща заявката, преди да очаквате Gradle свойство да го управлява.

Подобни статии