Gradle-ն որտեղից է ստանում պրոքսիի կարգավորումները

Հետևեք Gradle-ի JVM պրոքսիի հատկություններին, օգտվողի home կարգավորումներին և հաճախորդի միջավայրին՝ չենթադրելով, որ daemon-ը միշտ անտեսում է նոր փոփոխականները։

IDE-ից գործարկված Gradle build-ը կարող է օգտագործել այլ կազմաձև, քան տերմինալից գործարկված նույն նախագիծը։ Հին պրոքսիի գործընթացին մեղադրելուց առաջ համեմատեք յուրաքանչյուր գործարկման Gradle user home-ը, JVM-ը և պրոքսիի հատկությունները։

Gradle-ը փաստագրում է JVM պրոքսիի հատկությունները

HTTP և HTTPS ուղիների համար properties ֆայլը կարող է պարունակել՝

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 պրոքսիների ցանկը տալիս է host-ի և port-ի հնարավոր զույգեր։ HTTPS bypass հատկությունը նույնպես http.nonProxyHosts է. https.nonProxyHosts հորինելը փաստագրված լուծում չէ։ Host հատկությունները պարունակում են հասցե, ոչ ամբողջական proxy URL։

Shell-ում HTTP_PROXY արտահանելն ինքնին չի ապացուցում, որ այս JVM client-ը այն օգտագործում է որպես proxy policy։ Ստուգեք հավելվածի աջակցած հատկությունները։

Daemon-ը ստանում է build-ի տեղեկությունները

Gradle-ի ընթացիկ փաստաթղթերը նշում են, որ client-ը daemon-ին ուղարկում է build information, ներառյալ environment variables-ը։ Հետևաբար «daemon-ը երբեք նոր environment variables չի ստանում» ընդհանուր բացատրությունը սխալ է։

JVM-ի գործարկման որոշ հատկություններ, ներառյալ trust-store-ի հատկությունները, գործող JVM-ի համար անփոփոխ են։ Այդ պատճառով փոխված Java home-ը կամ trust-store-ի գործարկման կազմաձևը կարող է կարևոր լինել, նույնիսկ երբ build-ի միջավայրի սովորական արժեքները փոխանցվում են։

Համեմատեք երկու գործարկումները

Ստուգեք, թե IDE-ն Gradle-ի որ distribution-ն ու Java runtime-ն է ընտրում։ Ստուգեք, արդյոք այն օգտագործում է terminal-ի նույն GRADLE_USER_HOME-ը և user properties-ը։ Մեկ օգտվողի կազմաձևում proxy-ի գրառումը չի ցույց տալիս, թե այլ context-ը ինչ է բեռնել։

Եթե փոխված startup requirement-ը այլ daemon է պահանջում, օգտագործեք համապատասխան Gradle տարբերակի փաստագրված daemon controls-ը։ Daemon-ները կանգնեցնելը մի դարձրեք սխալ property կամ բացակայող configuration file գտնելու փոխարինող։

Վերջում որոշեք, թե որ request-ն է ձախողվել։ Wrapper-ի ներբեռնումները, build dependency resolution-ը և forked application կամ test process-ների request-ները ինքնաբերաբար նույն network context-ը չեն։ Ստուգեք request կատարող process-ը, նախքան սպասելը, որ Gradle property-ն այն կկառավարի։

Առնչվող հոդվածներ