საიდან იღებს Gradle პროქსის პარამეტრებს

IDE-დან გაშვებულმა Gradle build-მა შეიძლება სხვა კონფიგურაცია გამოიყენოს, ვიდრე იმავე პროექტმა ტერმინალიდან. ძველი პროქსის პროცესის დადანაშაულებამდე შეადარეთ თითოეული გაშვების Gradle user home, JVM და proxy თვისებები.

Gradle JVM proxy თვისებებს დოკუმენტირებს

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 proxy სია კანდიდატ host და port წყვილებს იძლევა. HTTPS bypass თვისებაც http.nonProxyHosts-ია; https.nonProxyHosts-ის მოგონება დოკუმენტირებული გამოსწორება არ არის. Host თვისებები მისამართს შეიცავს და არა სრულ proxy URL-ს.

Shell-ში HTTP_PROXY-ის export თავისთავად არ ამტკიცებს, რომ ეს JVM client მას proxy policy-ად იყენებს. შეამოწმეთ application-ის მხარდაჭერილი properties.

Daemon build ინფორმაციას იღებს

Gradle-ის მიმდინარე დოკუმენტაცია ამბობს, რომ client daemon-ს build information-ს, მათ შორის environment variables-ს, უგზავნის. ამიტომ ზოგადი ახსნა, თითქოს „daemon ახალ environment variables-ს არასოდეს იღებს“, არაზუსტია.

JVM startup-ის ზოგიერთი თვისება, მათ შორის trust-store-ის თვისებები, გაშვებული JVM-ისთვის უცვლელია. ამიტომ შეცვლილ Java home-ს ან trust-store startup configuration-ს შეიძლება მნიშვნელობა ჰქონდეს მაშინაც, როცა ჩვეულებრივი build გარემოს მნიშვნელობები გადაეცემა.

შეადარეთ ორი გაშვება

შეამოწმეთ, რომელ Gradle distribution-სა და Java runtime-ს ირჩევს IDE. შეამოწმეთ, იყენებს თუ არა terminal-ის მსგავს GRADLE_USER_HOME-სა და user properties-ს. ერთი მომხმარებლის configuration-ში proxy entry არ აჩვენებს, სხვა context-მა რა ჩატვირთა.

თუ შეცვლილი startup requirement სხვა daemon-ს მოითხოვს, გამოიყენეთ შესაბამისი Gradle version-ის დოკუმენტირებული daemon controls. daemon-ის გაჩერება არ აქციოთ არასწორი property-ის ან დაკარგული configuration file-ის პოვნის შემცვლელად.

ბოლოს განსაზღვრეთ, რომელი request ჩავარდა. Wrapper downloads, build dependency resolution და forked application ან test process-ების requests ავტომატურად ერთი network context არ არის. request-ის გამგზავნი process შეამოწმეთ, სანამ Gradle property მის კონტროლს ელით.