Nga i merr Gradle cilësimet e proxy-t

Ndiqni vetitë e proxy-t të JVM-së së Gradle, cilësimet e dosjes së përdoruesit dhe mjedisin e klientit, në vend që të supozoni se daemon-i i shpërfill gjithmonë ndryshoret e reja.

Një build i Gradle i nisur nga një IDE mund të përdorë konfigurim tjetër nga i njëjti projekt i nisur nga terminali. Para se të fajësoni një proces të vjetër proxy, krahasoni dosjen kryesore të përdoruesit të Gradle, JVM-në dhe vetitë e proxy-t për çdo nisje.

Gradle dokumenton vetitë e proxy-t të JVM-së

Për rrugët HTTP dhe HTTPS, një skedar vetish mund të përmbajë:

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

Përdorni pikën fundore të caktuar; për rrugët e lejuara drejt depove publike, lista e proxy-ve HTTP jep çifte kandidate hosti dhe porte. Vetia e anashkalimit të HTTPS është gjithashtu http.nonProxyHosts; shpikja e https.nonProxyHosts nuk është zgjidhja e dokumentuar. Vetitë e hostit përmbajnë adresë, jo URL të plotë proxy-je.

Eksportimi i HTTP_PROXY në shell nuk provon vetë se ky klient JVM e përdor si politikë proxy-je. Kontrolloni vetitë që mbështet aplikacioni.

Daemon-i merr vërtet informacionet e build-it

Dokumentacioni aktual i Gradle thotë se klienti i dërgon daemon-it informacionet e build-it, përfshirë ndryshoret e mjedisit. Prandaj shpjegimi i përgjithshëm “daemon-i nuk merr kurrë ndryshore të reja mjedisi” është i pasaktë.

Disa veti nisjeje të JVM-së, përfshirë vetitë e magazinës së besimit, janë të pandryshueshme për një JVM që po ekzekutohet. Një Java home ose konfigurim nisjeje i magazinës së besimit i ndryshuar mund të ketë rëndësi edhe kur vlerat e zakonshme të mjedisit të build-it kalohen më tej.

Krahasoni dy nisjet

Kontrolloni cilën shpërndarje Gradle dhe cilin runtime Java zgjedh IDE-ja. Kontrolloni nëse përdor të njëjtin GRADLE_USER_HOME dhe vetitë e përdoruesit si terminali. Një hyrje proxy-je në konfigurimin e një përdoruesi nuk tregon çfarë ngarkoi një kontekst tjetër.

Nëse një kërkesë nisjeje e ndryshuar ka nevojë për daemon tjetër, përdorni kontrollet e dokumentuara të daemon-it për versionin përkatës të Gradle. Mos e trajtoni ndalimin e daemon-ëve si zëvendësim për gjetjen e një vetie të gabuar ose skedari konfigurimi që mungon.

Në fund, identifikoni kërkesën që dështoi. Shkarkimet e Wrapper-it, zgjidhja e varësive të build-it dhe kërkesat nga proceset e ndara të aplikacionit ose testit nuk janë automatikisht i njëjti kontekst rrjeti. Verifikoni procesin që bën kërkesën para se të prisni që një veti Gradle ta kontrollojë.

Artikuj të ngjashëm