De unde își ia Gradle setările de proxy

Urmărește proprietățile de proxy ale JVM-ului Gradle, setările directorului personal și mediul clientului în loc să presupui că daemonul ignoră mereu variabilele noi.

Un build Gradle lansat dintr-un IDE poate folosi o configurație diferită de același proiect lansat dintr-un terminal. Înainte să dai vina pe un proces proxy vechi, compară directorul personal Gradle, JVM-ul și proprietățile proxy folosite la fiecare lansare.

Gradle documentează proprietățile proxy ale JVM-ului

Pentru rute HTTP și HTTPS, un fișier de proprietăți poate conține:

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

Folosiți endpointul alocat; pentru rute permise către depozite publice, lista de proxy-uri HTTP oferă perechi candidate de gazdă și port. Proprietatea de ocolire HTTPS este tot http.nonProxyHosts; inventarea lui https.nonProxyHosts nu este soluția documentată. Proprietățile gazdei conțin o adresă, nu un URL complet de proxy.

Exportarea lui HTTP_PROXY într-un shell nu dovedește singură că acest client JVM îl folosește drept politică proxy. Verificați proprietățile acceptate de aplicație.

Daemonul primește informațiile despre build

Documentația actuală Gradle spune că clientul trimite daemonului informații despre build, inclusiv variabile de mediu. Așadar, explicația generală „daemonul nu primește niciodată variabile de mediu noi” este inexactă.

Unele proprietăți de pornire ale JVM-ului, inclusiv cele ale magazinului de încredere, sunt imuabile pentru un JVM care rulează. Un Java home sau o configurație de pornire a magazinului de încredere schimbată poate conta, chiar dacă valorile obișnuite ale mediului de build sunt transmise.

Comparați cele două lansări

Verificați ce distribuție Gradle și ce runtime Java alege IDE-ul. Verificați dacă folosește același GRADLE_USER_HOME și aceleași proprietăți de utilizator ca terminalul. O intrare proxy din configurația unui utilizator nu stabilește ce a încărcat alt context.

Dacă o cerință de pornire schimbată necesită un daemon diferit, folosiți controalele documentate ale daemonului pentru versiunea Gradle vizată. Nu tratați oprirea daemonilor ca înlocuitor pentru găsirea unei proprietăți greșite sau a unui fișier de configurare lipsă.

În cele din urmă, identificați cererea care a eșuat. Descărcările Wrapper, rezolvarea dependențelor buildului și cererile proceselor bifurcate ale aplicației sau testului nu sunt automat același context de rețea. Verificați procesul care face cererea înainte să vă așteptați ca o proprietate Gradle să îl controleze.

Articole similare