אנציקלופדיה לבדיקה

מפרט מקיף של סביבת ביצוע הבדיקה.

רקע

שפת Bazel BUILD כוללת כללים שבהם ניתן להשתמש כדי להגדיר תוכניות בדיקה אוטומטיות בשפות רבות.

הבדיקות פועלות באמצעות bazel test.

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

הבדיקות צריכות להיות הירמטיות: כלומר, היא צריכה לגשת רק למשאבים שבהם יש להם תלות מוצהרת. אם הבדיקות לא מתנהלות בצורה תקינה, הן לא מספקות תוצאות שניתן לשחזר באופן היסטורי. זו יכולה להיות בעיה משמעותית למציאת פושעים (קביעה איזה שינוי גרם לבדיקות), לניראות הנדסת הפצה ולבידוד משאבים (בדיקות בדיקה אוטומטיות לא צריכות להיות שרת DDOS, כי חלק מהבדיקות מדברים אליו).

מטרה

מטרת הדף הזה היא לבסס בצורה רשמית את סביבת זמן הריצה וההתנהגות הצפויה של בדיקות Bazel. היא גם תציב דרישות כשה לבצע את הבדיקה ומערכת ה-build.

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

דף זה נועד להיות נורמלי וגם מהימן. אם המפרטים האלה וההתנהגות המוטמעת של מפעיל הבדיקה לא מסכימים עם המפרט הזה.

מפרט מוצע

מילות המפתח &"MUST", "MUST NOT", "required", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY " ו-"OPTIONAL;quot

מטרת הבדיקות

המטרה של בדיקות Bazel היא לאמת נכס כלשהו של קובצי המקור שנבדקו. (בדף הזה, & "מקור קובצי " כולל נתוני בדיקה, פלטי זהב וכל פריט אחר שנשמר במסגרת בקרת הגרסה.) משתמש אחד כותב בדיקה כדי להצהיר בעלות על חשבון קבוע שהוא מצפה לשמור. משתמשים אחרים יבצעו את הבדיקה מאוחר יותר כדי לבדוק אם יש פגם. אם הבדיקה תלויה במשתנים אחרים מלבד קובצי מקור (לא על בסיס הירמטי), הערך שלה נמוך יותר, כי המשתמשים במועד מאוחר יותר לא יכולים להיות בטוחים שהשינויים שלהם תקצו בתום הבדיקה.

לכן, התוצאה של בדיקה תלויה רק ב:

• קובצי מקור שבהם הבדיקה קיבלה תלות
• מוצרים של מערכת ה-build שבה הבדיקה מוגדרת תלות תלויה
• משאבים שהתנהגות הבדיקה שלהם מבטיחה שההתנהגות שלהם תישאר קבועה

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

התפקיד של מערכת ה-build

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

מערכת ה-build עשויה להשתמש בקובצי ה-runלב כדי להעביר קוד ונתונים. (הפרמטר הזה עשוי לשמש לאופטימיזציה, כדי לצמצם את כל הקבצים הבינאריים לבדיקה על ידי שיתוף קבצים בבדיקות שונות, למשל באמצעות קישור דינמי). מערכת ה-build צריכה לוודא שקובץ ההפעלה שנוצר טוען את הקבצים האלה דרך תמונת הריצה שסופקה על ידי הרצת הבדיקה, במקום לבצע קידוד קשיח של מיקומים מוחלטים בעץ המקור או בפלט.

התפקיד של אפקט הבדיקה

מנקודת המבט של הרצת הבדיקה, כל בדיקה היא תוכנית שאפשר להפעיל עם execve(). ייתכן שיש דרכים אחרות לבצע בדיקות. לדוגמה, בסביבת פיתוח משולבת (IDE) אפשר לבצע בדיקות Java בתהליך. עם זאת, תוצאות הפעלת הבדיקה כתהליך עצמאי צריכות להיחשב כמהימנות. אם תהליך בדיקה פועל ומסתיים כרגיל עם קוד יציאה של אפס, הבדיקה עברה. כל תוצאה אחרת נחשבת כשגיאת בדיקה. באופן ספציפי, כתיבת אחת מהמחרוזות PASS או FAIL ל-stdout אינה בעלת חשיבות למפעיל הבדיקה.

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

משך הבדיקה הכולל (לא שיטות בודדות או בדיקות) מקבל פרק זמן מוגבל עד להשלמתו. מגבלת הזמן לבדיקה מבוססת על המאפיין timeout שלה בהתאם לטבלה הבאה:

זמן קצוב לתפוגה	מגבלת זמן (שניות)
סרטון קצר	60
מתון	300
long	900
קבוע	3600

בבדיקות שלא מצוין בהן זמן קצוב לתפוגה יש משתמעת אחת על סמך הבדיקה size:

size [מידה]	תווית זמן קצוב משתמע
small	סרטון קצר
medium	מתון
large	long
עצום	קבוע

הבדיקה תוקצה להפעלה של "large" וללא הגדרת זמן קצוב לתפוגה מפורשת, 900 שניות. "medium&PLURAL; תוקצה לזמן קצוב של 60 שניות.

בניגוד ל-timeout, בנוסף ל-size נקבע שימוש הה שיא המותר במשאבים אחרים (כגון RAM) בעת ביצוע הבדיקה באופן מקומי, כפי שמתואר בהגדרות הנפוצות.

כל השילובים של תוויות size ו-timeout הם חוקיים, לכן יש להכריז על בדיקה של &מירכאות; ענק ו&; סביר להניח שזה יקרה מהר מאוד.

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

ניתן לבטל את הזמן הקצוב לתפוגה של בדיקה עם סימון הבסיס --test_timeout, אם הפעולה הידנית מתבצעת בתנאים שידוע שהם איטיים. הערכים של --test_timeout הם בשניות. לדוגמה, ההגדרה של --test_timeout=120 קובעת את הזמן הקצוב לתפוגה של הבדיקה למשך שתי דקות.

בנוסף, מומלץ להגדיר סף תחתון לזמן קצוב לתפוגה של בדיקות:

זמן קצוב לתפוגה	מינימום זמן (שניות)
סרטון קצר	0
מתון	30
long	300
קבוע	900

לדוגמה, אם בדיקה "mediumrate" מסתיימת ב-5.5 שניות, כדאי להגדיר את timeout = "short" או את size = "small". אם משתמשים באפשרות של שורת הפקודה --test_verbose_timeout_warnings במסגרת, יוצגו הבדיקות שהגודל שלהן גדול מדי.

גודלי הבדיקות והזמן הקצוב לתפוגה מסומנים בקובץ BUILD בהתאם למפרט כאן. אם לא צוין ערך, ברירת המחדל של גודל בדיקה היא "medium"

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

בדיקת הפיצול

ניתן לבצע בדיקות במקביל באמצעות פיצול בדיקה. כדאי לעיין ב---test_sharding_strategy וב-shard_count כדי להפעיל את הפיצול בבדיקות. כאשר הפיצול מופעל, הרצת הבדיקה מופעלת פעם אחת לכל פיצול. משתנה הסביבה TEST_TOTAL_SHARDS הוא מספר הפיצולים ו-TEST_SHARD_INDEX הוא האינדקס של הפיצול, שמתחיל ב-0. ריצה משתמשת במידע הזה כדי לבחור אילו בדיקות להפעיל. לדוגמה, באמצעות אסטרטגיית עיגול. לא כל מתקנים לריצה תומכים בפיצול. אם רץ תומך בפיצול, עליו ליצור או לעדכן את תאריך השינוי האחרון של הקובץ שצוין ב-TEST_SHARD_STATUS_FILE. אחרת, בזל מניחה שהיא לא תומכת בפיצול ולא תפעיל עוד רצים.

תנאים ראשוניים

בעת ביצוע בדיקה, הרצת הבדיקה חייבת לעמוד בתנאים מסוימים.

על אחראי הריצה להפעיל כל בדיקה עם הנתיב לביצוע ההרצה ב-argv[0]. הנתיב הזה חייב להיות יחסי ומתחת לספרייה הנוכחית של הבדיקה הרצת הבדיקה לא אמורה להעביר ארגומנטים אחרים לבדיקה, אלא אם המשתמש ביקש זאת במפורש.

חסימת הסביבה הראשונית תיכתב כך:

משתנה	ערך	סטטוס
HOME	הערך של $TEST_TMPDIR	מומלץ
LANG	ביטול הגדרות	חובה
LANGUAGE	ביטול הגדרות	חובה
LC_ALL	ביטול הגדרות	חובה
LC_COLLATE	ביטול הגדרות	חובה
LC_CTYPE	ביטול הגדרות	חובה
LC_MESSAGES	ביטול הגדרות	חובה
LC_MONETARY	ביטול הגדרות	חובה
LC_NUMERIC	ביטול הגדרות	חובה
LC_TIME	ביטול הגדרות	חובה
LD_LIBRARY_PATH	רשימת ספריות עם ערכים מופרדים בנקודתיים	אופציונלי
JAVA_RUNFILES	הערך של $TEST_SRCDIR	הוצא משימוש
LOGNAME	הערך של $USER	חובה
PATH	/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.	מומלץ
PWD	$TEST_SRCDIR/workspace-name	מומלץ
SHLVL	2	מומלץ
TEST_INFRASTRUCTURE_FAILURE_FILE	נתיב מוחלט לקובץ פרטי בספרייה ניתנת לכתיבה (יש להשתמש בקובץ רק כדי לדווח על כשלים שמקורם בתשתית הבדיקה, ולא כמנגנון כללי לדיווח על כשלים ניסיוניים בבדיקות. בהקשר הזה, תשתית הבדיקה מוגדרת כמערכות או ספריות שאינן ספציפיות לבדיקה, אבל עלולות לגרום לכשלים בבדיקה. השורה הראשונה היא שם הרכיב של תשתית הבדיקה שגרם לכשל, בשורה השנייה יש תיאור שקריא למשתמשים. המערכת מתעלמת משורות נוספות.)	אופציונלי
TEST_LOGSPLITTER_OUTPUT_FILE	נתיב מוחלט לקובץ פרטי בספרייה הניתנת לכתיבה (משמשת לכתיבה של יומן יומן פרוטוטר של Logsplitter)	אופציונלי
TEST_PREMATURE_EXIT_FILE	נתיב מוחלט לקובץ פרטי בספרייה שאפשר לכתוב (משמש לתיעוד שיחות אל exit())	אופציונלי
TEST_RANDOM_SEED	אם האפשרות --runs_per_test בשימוש, המדיניות TEST_RANDOM_SEED מוגדרת לערך run number (מתחיל ב-1) בכל הרצת בדיקה נפרדת.	אופציונלי
TEST_RUN_NUMBER	אם האפשרות --runs_per_test בשימוש, המדיניות TEST_RUN_NUMBER מוגדרת לערך run number (מתחיל ב-1) בכל הרצת בדיקה נפרדת.	אופציונלי
TEST_TARGET	שם היעד שנבדק	אופציונלי
TEST_SIZE	הבדיקה size	אופציונלי
TEST_TIMEOUT	הבדיקה timeout בשניות	אופציונלי
TEST_SHARD_INDEX	אינדקס פיצול, אם נעשה שימוש ב-sharding	אופציונלי
TEST_SHARD_STATUS_FILE	נתיב לקובץ לנגיעה כדי לציין תמיכה עבור sharding	אופציונלי
TEST_SRCDIR	נתיב מוחלט לבסיס של עץ הריצה	חובה
TEST_TOTAL_SHARDS	סה"כ shard count, אם נעשה שימוש ב-sharding	אופציונלי
TEST_TMPDIR	נתיב מוחלט לספרייה פרטית הניתנת לכתיבה	חובה
TEST_WORKSPACE	שם סביבת העבודה של המאגר המקומי	אופציונלי
TEST_UNDECLARED_OUTPUTS_DIR	נתיב מוחלט לספרייה כתובה פרטית (משמשת לכתיבת פלט של בדיקה לא מוצהרת)	אופציונלי
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR	נתיב מוחלט לספרייה ניתנת לכתיבה פרטית (משמשת לכתיבת הערה של פלט בדיקה לא מוצהר .part ו-.pb).	אופציונלי
TEST_WARNINGS_OUTPUT_FILE	נתיב מוחלט לקובץ פרטי בספרייה הניתנת לכתיבה (משמשת לכתיבת אזהרות לגבי יעד לבדיקה)	אופציונלי
TESTBRIDGE_TEST_ONLY	הערך של --test_filter, אם צוין	אופציונלי
TZ	UTC	חובה
USER	הערך של getpwuid(getuid())->pw_name	חובה
XML_OUTPUT_FILE	המיקום שבו פעולות הבדיקה צריכות לכתוב קובץ פלט תוצאה של בדיקה. אחרת, Bazel יוצרת קובץ פלט XML המוגדר כברירת מחדל, עוטף את יומן הבדיקה כחלק מפעולת הבדיקה. סכימת ה-XML מבוססת על סכימת תוצאות הבדיקה של JUnit.	אופציונלי
BAZEL_TEST	מציין הפעלה של bazel test המופעלת	חובה

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

ספריית העבודה הראשונית תהיה $TEST_SRCDIR/$TEST_WORKSPACE.

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

מתאר הקובץ 0 (stdin) יהיה פתוח לקריאה, אבל הקובץ שאליו הוא מצורף לא צוין. אין לקרוא ממנה בדיקות. תיאורי הקובץ 1 (stdout) ו-2 (stderr) פתוחים לכתיבה, אבל הקבצים המצורפים אליהם לא צוינו. היא יכולה להיות מסוף, קו אנכי, קובץ רגיל או כל תו אחר שאפשר לכתוב בו. הם יכולים לשתף רשומה בטבלת הקבצים הפתוחים (כלומר, הם לא יכולים לחפש באופן עצמאי). הבדיקות לא צריכות לרשת תיאורי קבצים פתוחים אחרים.

ערך ההרשאה הראשוני יהיה 022 או 027.

אין שעונים מעוררים או טיימרים למרווחי זמן.

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

יש להגדיר את מגבלות המשאבים הראשוניות, הן הרכות והן קשות, באופן הבא:

משאב	מגבלה
RLIMIT_AS	ללא הגבלה
RLIMIT_CORE	לא צוין
RLIMIT_CPU	ללא הגבלה
RLIMIT_DATA	ללא הגבלה
RLIMIT_FSIZE	ללא הגבלה
RLIMIT_LOCKS	ללא הגבלה
RLIMIT_MEMLOCK	ללא הגבלה
RLIMIT_MSGQUEUE	לא צוין
RLIMIT_NICE	לא צוין
RLIMIT_NOFILE	1024 לפחות
RLIMIT_NPROC	לא צוין
RLIMIT_RSS	ללא הגבלה
RLIMIT_RTPRIO	לא צוין
RLIMIT_SIGPENDING	לא צוין
RLIMIT_STACK	ללא הגבלה, או 2044KB <= rlim <= 8192KB

לא צוינו זמני התהליך הראשוניים (כפי שהוחזרו על ידי times()) והשימוש במשאבים (כפי שהוחזרו על ידי getrusage()).

המדיניות והעדיפות של התזמון הראשוני לא צוינו.

התפקיד של מערכת האירוח

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

מערכת קבצים

ספריית הבסיס שנבדקה עשויה להיות ספריית הבסיס האמיתית, או לא.

הטעינה של /proc תתבצע.

כל כלי ה-build יופיעו בנתיבים המוחלטים בקטע /usr המשמשים בהתקנה מקומית.

ייתכן שנתיבים שמתחילים ב-/home לא יהיו זמינים. הבדיקות לא יכולות לגשת לנתיבים כאלה.

ניתן יהיה לכתוב ב/tmp, אבל מומלץ להימנע משימוש בנתיבים האלה.

חשוב להשתמש בבדיקות כדי לוודא שלא קיים נתיב קבוע לשימושם הבלעדי.

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

משתמשים וקבוצות

הגרסה הבסיסית של המשתמש, אף אחד ויחידת משנה חייבים להתקיים. הרמה הבסיסית (root), אף אחד ו-Engs חייבים להתקיים.

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

למזהה המשתמש ולמזהה הקבוצה הנוכחיים צריכים להיות שמות תואמים שניתן לאחזר עם getpwuid() ועם getgrgid(). זה לא יכול להיות נכון לגבי מזהי קבוצות משלימים.

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

Networking

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

משאבים נוספים

בדיקות מקבלות לפחות יחידת ליבה אחת של מעבד (CPU). ייתכן שאחרים יהיו זמינים, אבל זה לא מובטח. לא צוינו היבטים אחרים של הביצועים של הליבה הזו. אפשר להגדיל את ההזמנה למספר גבוה יותר של ליבות מעבד (CPU) על ידי הוספת התג "cpu:n" (כאשר n הוא מספר חיובי) לכלל בדיקה. אם למעבד יש פחות ליבות מעבד (CPU) סה"כ מהמותר, Bazel עדיין תריץ את הבדיקה. אם בבדיקה מסוימת נעשה שימוש בפיצול, כל פיצול מעבד שומר את מספר הליבות של המעבד (CPU).

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

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

תאריך ושעה

התאריך והשעה הנוכחיים לא צוינו. אזור הזמן של המערכת לא צוין.

ייתכן ש-Windows Windows לא יהיה זמין. בדיקות שמחייבות שרת X צריכות להתחיל ב-Xvfb.

בדיקת האינטראקציה עם מערכת הקבצים

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

הבדיקות צריכות ליצור קבצים רק בתוך הספריות שצוינו על ידי $TEST_TMPDIR ו-$TEST_UNDECLARED_OUTPUTS_DIR (אם הוגדר).

הספריות האלה יהיו ריקות בהתחלה.

אין לנסות להסיר ספריות, לשנות אותן או לשנות אותן בכל דרך אחרת.

הספריות האלה יכולות להיות קישורים סימבוליים.

סוג מערכת הקבצים $TEST_TMPDIR/. לא צוין.

בבדיקות עשויות גם להופיע קובצי .part $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR כדי להוסיף הערות לקובצי פלט לא מוצהרים.

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

לחלק ממסגרות הבדיקה הפופולריות, כמו JUnit4 TemporaryFolder או Go TempDir, יש דרכים משלה ליצירת ספרייה זמנית בקטע /tmp. משימות הבדיקה האלה כוללות פונקציונליות לניקוי קבצים ב-/tmp, לכן אפשר להשתמש בהן למרות שהן יוצרות קבצים מחוץ ל-TEST_TMPDIR.

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

הבדיקות לא יכולות לגשת לפלט של מערכת ה-build בנתיבים שהמערכת מפיקה מהמיקום של קובץ ההפעלה שלה.

לא מצוין אם עץ ה-runfiles מכיל קבצים רגילים, קישורים סימבוליים או שילוב. עץ ה-runfiles יכול להכיל קישורים סימבוליים לספריות. מומלץ להימנע משימוש בנתיבים שמכילים רכיבים של .. בעץ הריצה.

לא צריכה להיות אפשרות לכתיבה של ספרייה, קובץ או קישור סימבוליים בעץ הריצה (כולל נתיבים של קישורים סימבוליים). (כתוצאה מכך, הספרייה הראשונית לא צריכה להיות ניתנת לכתיבה). לא ניתן להניח שחלקים מהקבצים ניתנים לכתיבה או שהם בבעלות המשתמש הנוכחי (לדוגמה, chmod ו-chgrp עלולים להיכשל).

עץ ה-runfiles (כולל נתיבים שמעבירים קישורים סימבוליים) לא יכול להשתנות במהלך ביצוע בדיקה. לא ניתן לשנות את הספריות והתושבות של קובצי ההורה לשום אופן שמשפיע על התוצאה של פתרון נתיב בעץ הריצה.

כדי לאתר את היציאה המוקדמת, הבדיקה עשויה ליצור קובץ בנתיב שצוין על ידי TEST_PREMATURE_EXIT_FILE בתחילת הקובץ ולהסיר אותו ביציאה. אם Bazel רואה את הקובץ בסיום הבדיקה, היא מניחה שהבדיקה הסתיימה מוקדם מדי וסומנה שהיא נכשלה.

מוסכמות של תגים

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

תג	משמעות
exclusive	לא להריץ בדיקות אחרות בו-זמנית
external	לבדיקה יש תלות חיצונית. אפשר להשבית את השמירה במטמון
large	מוסכמה test_suite; חבילה של בדיקות גדולות
manual *	אין לכלול יעד בדיקה בתבניות יעד בתווים כלליים לחיפוש, כמו :..., :* או :all
medium	מוסיפה test_suite; חבילה של בדיקות בינוניות
small	מוסכמה test_suite; חבילה של בדיקות קטנות
smoke	מוסכמה test_suite; יש להריץ אותה לפני ביצוע שינויים בקוד במערכת בקרת הגרסאות

קובצי Runrun

בדוגמה הבאה, נניח שיש כלל *_binary() עם התווית //foo/bar:unittest, עם תלות בזמן ריצה בכלל המסומן בתווית //deps/server:server.

מיקום

ספריית קובצי העזר של היעד //foo/bar:unittest היא הספרייה $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. הנתיב הזה נקרא runfiles_dir.

יחסי תלות

ספריית ה-runfiles הוצהרה כתלויה בזמן הידור של הכלל *_binary(). ספריית קובצי ה-ריצה עצמה תלויה בקבוצת קובצי BUILD שמשפיעים על הכלל *_binary() או על התלות שלו בזמן הריצה או על זמן הריצה. שינוי קובצי המקור לא משפיע על המבנה של ספריית קובצי הרצה, ולכן לא מפעיל בנייה מחדש.

תוכן עניינים

ספריית ה-runfiles כוללת את הפרטים הבאים:

• קישורי MIME לתלויות בזמן ריצה: כל פלט קובץ ו-CommandRule שהם יחסי תלות בזמן ריצה של הכלל *_binary() מיוצגים על ידי קישור קישור אחד בספריית Runfiles. השם של הקישור הסמלי הוא $(WORKSPACE)/package_name/rule_name. לדוגמה, הסמל הסימולטני של השרת ייקרא $(WORKSPACE)/deps/server/server, והנתיב המלא יהיה $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. היעד של הקישור הסימולי הוא פלטFileName() ב-פלטFile או CommandRule, כנתיב מוחלט. לכן, היעד של הקישור הסמלי עשוי להיות $(WORKSPACE)/linux-dbg/deps/server/42/server.
• קישורי ריצה לקובצי משנה: לכל *_binary() Z שתלויה בזמן ריצה של *_binary() C, יש קישור שני בספרייה Runruns של C ל-runfiles של Z. השם של הקישור הסמלי הוא $(WORKSPACE)/package_name/rule_name.runfiles. המטרה של הקישור הסמלי היא ספריית הריצה. לדוגמה, לכל תתי-התוכניות יש ספריית ריצה משותפת.