Звідки 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 ним керуватиме.

Схожі статті