סוכן Azure Pipelines באירוח עצמי יכול להחזיק כללי עקיפת proxy בקובץ .proxybypass בתיקיית הבסיס שלו. כל שורה היא ביטוי רגולרי של ECMAScript שנבדק מול URL.

לדוגמה, כלל עבור מארח פיד פנימי אחד יכול להיראות כך:

^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)

הביטוי מתאים לכתובות HTTP או HTTPS של אותו מארח, עם פורט מספרי אופציונלי. הגבול שאחרי שם המארח מונע התאמה גם לשם ארוך יותר כמו packages.internal.example.other-domain.

זהו הקובץ של התקנת הסוכן, ולא קובץ שהונח באופן שרירותי בעותק קוד המקור. התחביר שלו שונה גם מערך NO_PROXY מופרד בפסיקים. העתקת תו כללי של מעטפת כמו *.internal.example לשדה של ביטוי רגולרי אינה שומרת על אותה משמעות.

לאחר מכן זהו מי מוריד את החבילה

פעולות המקור והארטיפקט המובנות של הסוכן משתמשות בתצורת ה-proxy שלו. משימות יכולות לקבל את פרטי ה-proxy החשופים דרך ספריית המשימות ולהחיל אותם על לקוחות ה-HTTP שלהן.

משימה שקוראת לתהליך חיצוני של NuGet, dotnet או curl מוסיפה צרכן נוסף. ודאו כיצד אותה משימה מספקת לכלי את הגדרות ה-proxy והעקיפה. כלל סוכן נכון אינו מוכיח שכל לקוח חבילה עצמאי קרא אותו.

שמרו את כתובת ה-URL של הפיד הפנימי ברשומת האבחון, כולל הסכימה והפורט. בדקו את הכלל מול הכתובת שאיתה יוצרים קשר, ואז בחנו את תצורת המשימה או הלקוח שאחראית לבקשה הזו.

מאמרים קשורים