מציאת התנהגות שאינה מזיקה בכללי WORKSPACE

לאחר מכן, מחשב מארח הוא המחשב שבו בזל פועלת.

בעת שימוש בהפעלה מרחוק, הבנייה ו/או שלבי הבדיקה בפועל לא מתרחשים במחשב המארח, אלא נשלחים למערכת ההפעלה מרחוק. עם זאת, השלבים לפתרון כללים של סביבת עבודה מתבצעים במחשב המארח. אם כללי העבודה שלך ניגשים למידע על המחשב המארח לשימוש בזמן הביצוע, סביר להניח שה-build יתקלקל עקב אי-תאימות בין הסביבה.

כחלק מהתאמת הכללים של Bazel לביצוע מרחוק, עליך למצוא כללי סביבת עבודה כאלה ולתקן אותם. בדף זה מוסבר איך למצוא כללים לסביבת עבודה שעלולים להיות בעייתיים באמצעות היומן של סביבת העבודה.

חיפוש כללים שאינם הרמטיים

כללי סביבת עבודה מאפשרים למפתח להוסיף יחסי תלות לסביבות עבודה חיצוניות, אבל הם עשירים מספיק כדי לאפשר עיבוד שרירותי למתרחש בתהליך. כל הפקודות הקשורות מתרחשות באופן מקומי, והן עשויות להיות מקור פוטנציאלי לחוסר החשיבה. בדרך כלל התנהגות לא הרמטית מופעלת דרך repository_ctx, המאפשרת אינטראקציה עם המחשב המארח.

החל מ-Bazel 0.18, ניתן לקבל יומן של חלק מהפעולות שאינן הרמטיות, על ידי הוספת הסימון --experimental_workspace_rules_log_file=[PATH] לפקודת Bazel שלך. כאן [PATH] הוא שם קובץ שבאמצעותו ייווצר היומן.

כדאי לשים לב:

• היומן מתעד את האירועים כאשר הם מבוצעים. אם חלק מהשלבים נשמרים במטמון, הם לא יופיעו ביומן, כך שכדי לקבל תוצאה מלאה, אל תשכחו להפעיל bazel clean --expunge לפני כן.

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

• נכון לעכשיו, כללי Workspace מאפשרים לתעד רק אירועים של Starlark.

  .

כדי לבדוק מה הופעל במהלך האתחול של סביבת העבודה:

1. הפעלה של bazel clean --expunge. פקודה זו תנקה את המטמון המקומי וכל מאגרי הקבצים השמורים, ותוודא שכל האתחול יופעל מחדש.

2. צריך להוסיף את --experimental_workspace_rules_log_file=/tmp/workspacelog לפקודה Bazel ולהפעיל את ה-build.

   הבעיה הזו יוצרת קובץ אב בינארי פירוט של הודעות מסוג WorkspaceEvent

3. מורידים את קוד המקור של Bazel ועוברים אל התיקייה Bazel באמצעות הפקודה שלמטה. נדרש קוד מקור כדי לנתח את היומן של סביבת העבודה באמצעות מנתח סביבת העבודה.

   git clone https://github.com/bazelbuild/bazel.git
   cd bazel
   

4. המאגר של קוד המקור ב-Bazel, ממירים את כל יומן סביבת העבודה לטקסט.

   bazel build src/tools/workspacelog:parser
   bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt
   

5. הפלט עשוי להיות מפורט יותר ולכלול פלט של כללי בזל.

   כדי להחריג כללים ספציפיים מהפלט, יש להשתמש באפשרות --exclude_rule. למשל:

   bazel build src/tools/workspacelog:parser
   bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
       --exclude_rule "//external:local_config_cc" \
       --exclude_rule "//external:dep" > /tmp/workspacelog.txt
   

6. יש לפתוח את /tmp/workspacelog.txt ולחפש פעולות לא בטוחות.

היומן מורכב מהודעות WorkspaceEvent מתארות פעולות מסוימות שעלולות להיות לא הרמטיות שבוצעו ב- repository_ctx.

הפעולות שהודגשו כבעלי פוטנציאל לא הרמטי הן אלו:

• execute: מתבצעת פקודת שרירותית בסביבת המארח. בודקים אם התנאים האלה עשויים להביא ליחסי תלות כלשהם בסביבת המארח.

• download, download_and_extract: כדי להבטיח שעיצובים הרמטיים יהיו בטוחים, יש לוודא ש-sha256 מצוין

• file, template: כשלעצמן, הטכניקה אינה תיאורית, אך היא עשויה להיות מנגנון להכנסת יחסי תלות בסביבת המארח למאגר. ודאו שאתם מבינים מה מקור הקלט, ושהוא לא תלוי בסביבת המארח.

• os: שיטה זו אינה תיאורית לכשעצמה, אלא דרך קלה לקבל תלות בסביבת המארח. מכשיר המתאר הרמוט בדרך כלל לא יקרא לה. כשאתם בוחנים אם השימוש שלכם בהרמיט, חשוב לזכור שהדבר פועל במארח ולא אצל העובדים. קבלת פרטים ספציפיים על הסביבה מהמארח בדרך כלל אינה מומלצת לגרסאות build מרוחקות.

• symlink: בדרך כלל בטוח, אך כדאי לחפש סימונים אדומים. סמלים כלשהם מחוץ למאגר או לנתיב מוחלט יגרמו לבעיות בעובד המרוחק. אם הסמל הסימבולי נוצר על סמך מאפיינים של מחשב מארח, סביר להניח שגם הוא בעייתי.

• which: חיפוש תוכניות שמותקנות במארח הוא בדרך כלל בעייתי, כי ייתכן שלעובדים יש תצורות שונות.