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

Отслеживайте свойства прокси JVM в Gradle, настройки домашнего каталога пользователя и окружение клиента, а не предполагайте, что демон всегда игнорирует новые переменные.

Сборка Gradle, запущенная из 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

Используйте назначенную конечную точку; для разрешённых маршрутов к публичным репозиториям список HTTP-прокси предлагает пары хоста и порта. Свойство обхода HTTPS также называется http.nonProxyHosts; выдумывать https.nonProxyHosts — не документированное решение. Свойства хоста содержат адрес, а не полный URL прокси.

Экспорт HTTP_PROXY в оболочку сам по себе не доказывает, что этот JVM-клиент использует его как политику прокси. Проверьте свойства, которые поддерживает приложение.

Демон действительно получает сведения о сборке

Согласно актуальной документации Gradle, клиент отправляет демону сведения о сборке, включая переменные окружения. Поэтому общее объяснение «демон никогда не получает новые переменные окружения» неточно.

Некоторые свойства запуска JVM, включая свойства хранилища доверия, неизменяемы для работающей JVM. Поэтому изменённый Java home или конфигурация запуска хранилища доверия могут иметь значение, даже когда обычные значения окружения сборки передаются дальше.

Сравните два запуска

Проверьте, какой дистрибутив Gradle и какую среду выполнения Java выбирает IDE. Проверьте, использует ли она те же GRADLE_USER_HOME и пользовательские свойства, что и терминал. Запись прокси в конфигурации одного пользователя не показывает, что загрузил другой контекст.

Если изменённое требование запуска нуждается в другом демоне, используйте документированные средства управления демоном для соответствующей версии Gradle. Не считайте остановку демонов заменой поиску неправильного свойства или отсутствующего файла конфигурации.

Наконец, определите неудачный запрос. Загрузки Wrapper, разрешение зависимостей сборки и запросы раздвоенных процессов приложения или тестов не являются автоматически одним сетевым контекстом. Проверьте процесс, выполняющий запрос, прежде чем ожидать, что свойство Gradle будет им управлять.

Похожие статьи