מאין Gradle מקבל את הגדרות ה־proxy שלו

Build של Gradle שהופעל מ־IDE עשוי להשתמש בתצורה שונה מאותו פרויקט שהופעל מהמסוף. לפני שמאשימים תהליך proxy ישן, השוו את ספריית הבית של משתמש Gradle, את ה־JVM ואת מאפייני ה־proxy בכל הפעלה.

Gradle מתעד מאפייני proxy של 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 proxy מספקת זוגות מועמדים של מארח ויציאה. מאפיין עקיפת HTTPS הוא גם http.nonProxyHosts; המצאת https.nonProxyHosts אינה התיקון המתועד. מאפייני המארח מכילים כתובת, לא כתובת URL מלאה של proxy.

ייצוא HTTP_PROXY במעטפת אינו מוכיח כשלעצמו שלקוח JVM זה משתמש בו כמדיניות proxy. בדקו אילו מאפיינים היישום תומך בהם.

ה־daemon אכן מקבל מידע על ה־build

התיעוד העדכני של Gradle אומר שהלקוח שולח ל־daemon מידע על ה־build, כולל משתני סביבה. לכן ההסבר הגורף «ה־daemon לעולם אינו מקבל משתני סביבה חדשים» אינו מדויק.

חלק ממאפייני האתחול של JVM, כולל מאפייני מאגר האמון, אינם ניתנים לשינוי עבור JVM פועל. לכן Java home שהשתנה או תצורת אתחול שונה של מאגר האמון עשויים להיות חשובים גם כאשר ערכי סביבת ה־build הרגילים מועברים הלאה.

השוו בין שתי ההפעלות

בדקו באיזו הפצת Gradle ובאיזו סביבת Java בוחר ה־IDE. בדקו אם הוא משתמש באותו GRADLE_USER_HOME ובאותם מאפייני משתמש כמו המסוף. רשומת proxy בתצורה של משתמש אחד אינה קובעת מה הקשר אחר טען.

אם דרישת אתחול שהשתנתה זקוקה ל־daemon אחר, השתמשו בבקרות ה־daemon המתועדות לגרסת Gradle המתאימה. אל תתייחסו לעצירת daemons כתחליף למציאת מאפיין שגוי או קובץ תצורה חסר.

לבסוף, זהו את הבקשה שנכשלה. הורדות Wrapper, פתרון תלויות build ובקשות מתהליכי יישום או בדיקה מפוצלים אינם אוטומטית אותו הקשר רשת. אמתו את התהליך שמבצע את הבקשה לפני שתצפו שמאפיין Gradle ישלוט בו.