title: "GitHub Actions: עדכוני אפריל 2026 משפרים את הגמישות והאבטחה של CI/CD" slug: "2026-04-02-github-actions-early-april-2026-updates" date: "2026-04-03" lang: "he" source: "https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/" category: "כלי פיתוח" keywords:
- "GitHub Actions"
- "CI/CD"
- "OIDC"
- "קונטיינרי שירות"
- "רשת פרטית ב-Azure"
- "מעבר לגיבוי ב-VNET"
- "אוטומציית זרימת עבודה"
- "אבטחת ענן"
- "DevOps"
- "מאפיינים מותאמים אישית"
- "ביטולי נקודת כניסה"
- "שיפורי אבטחה" meta_description: "GitHub Actions משיקה עדכונים חשובים באפריל 2026, ומציגה ביטולי נקודת כניסה לקונטיינרי שירות, מאפיינים מותאמים אישית של OIDC לאבטחה מדוקדקת, ומעבר לגיבוי ב-Azure VNET עבור צינורות CI/CD חזקים." image: "/images/articles/2026-04-02-github-actions-early-april-2026-updates.png" image_alt: "לוגו GitHub Actions המציג צינור CI/CD מאובטח וגמיש עם אינטגרציית ענן." quality_score: 94 content_score: 93 seo_score: 95 companies:
- GitHub schema_type: "NewsArticle" reading_time: 5 faq:
- question: "מהם ביטולי נקודת הכניסה והפקודה החדשים עבור קונטיינרי שירות ב-GitHub Actions?" answer: "GitHub Actions מאפשרת כעת למפתחים לדרוס ישירות את נקודת הכניסה והפקודה המוגדרות כברירת מחדל עבור קונטיינרי שירות בתוך קובצי YAML של זרימת העבודה שלהם. פונקציונליות חדשה זו מתמודדת עם מגבלות קודמות שלעיתים קרובות דרשו פתרונות עקיפים מורכבים, ומספקת גישה יעילה וגמישה יותר לניהול שירותים מבוססי קונטיינרים. התחביר תוכנן להיות אינטואיטיבי ומוכר, ומשקף את המוסכמות המשמשות ב-Docker Compose, ובכך מפחית את עקומת הלמידה למפתחים המורגלים כבר לסביבות Docker. שיפור זה משפר באופן משמעותי את האופן שבו משתמשים מתקשרים ומתאימים אישית את צינורות ה-CI/CD שלהם בעבודה עם שירותים כמו מסדי נתונים או מטמונים."
- question: "כיצד מאפיינים מותאמים אישית של OIDC משפרים את האבטחה ומפשטים את הגישה לענן ב-GitHub Actions?" answer: "הזמינות הכללית של מאפיינים מותאמים אישית של OIDC עבור אסימוני GitHub Actions היא שדרוג אבטחה משמעותי. תכונה זו מאפשרת לארגונים להטמיע מאפיינים מותאמים אישית המוגדרים על ידי מאגר נתונים כ-'claims' ישירות בתוך אסימוני OpenID Connect (OIDC) שלהם. בכך, הם יכולים ליצור מדיניות אמון מדוקדקת ביותר עם ספקי ענן המבוססת על תכונות ספציפיות כגון סוג סביבה, בעלות צוות, או רמת תאימות, במקום להסתמך על שמות או מזהי מאגר נתונים פחות ספציפיים. זה לא רק מחזק את בקרת הגישה על ידי אכיפת הרשאות מחמירות יותר ומודעות להקשר, אלא גם מפשט באופן דרסטי את עומס הניהול הכרוך בהגדרת תפקידי ענן על בסיס כל מאגר נתונים בנפרד, מה שהופך את הגישה לענן לבטוחה ויעילה יותר."
- question: "מהו מעבר לגיבוי ב-Azure VNET עבור מריצי GitHub Actions מתארחים, וכיצד הוא מבטיח עמידות CI/CD?" answer: "רשת פרטית ב-Azure עבור מריצי GitHub Actions מתארחים כוללת כעת יכולות מעבר לגיבוי ב-VNET, הנמצאות כעת בתצוגה מקדימה ציבורית. תכונה זו מאפשרת לארגונים ולחברות להגדיר רשת משנה משנית ב-Azure, העשויה להיות באזור גיאוגרפי אחר, כגיבוי. במקרה שרשת המשנה הראשית הופכת ללא זמינה עקב הפסקה או בעיות אחרות, המערכת יכולה לעבור אוטומטית או ידנית לרשת משנה משנית זו. פונקציונליות קריטית זו מבטיחה פעולה רציפה של זרימות עבודה של CI/CD, מפחיתה משמעותית את זמן ההשבתה ושומרת על אמינות צינורות הפיתוח, במיוחד עבור יישומים קריטיים הדורשים זמינות גבוהה."
- question: "אילו משתמשי GitHub Actions ייהנו ביותר מיכולות המעבר לגיבוי ב-Azure VNET?" answer: "תכונת המעבר לגיבוי ב-Azure VNET מיועדת באופן ספציפי לחשבונות ארגוניים וחברות המשתמשים ברשת פרטית ב-Azure עם מריצי GitHub מתארחים. היא מועילה במיוחד לארגונים עם דרישות קפדניות לזמן פעולה (uptime), לאלה הפועלים בפריסות מרובות אזורים, או לאלה המטפלים בעומסי עבודה קריטיים שבהם כל הפרעה לצינורות CI/CD עלולה להוביל להשפעה עסקית משמעותית. חברות המעניקות עדיפות לזמינות גבוהה ואסטרטגיות התאוששות מאסון עבור תשתית הפיתוח שלהן ימצאו תכונה זו בעלת ערך רב לשמירה על המשכיות תפעולית ושיפור העמידות הכוללת של מחזור אספקת התוכנה שלהן, ומציעה שקט נפשי במהלך הפסקות אזוריות."
- question: "כיצד מאפיינים מותאמים אישית חדשים של OIDC מפחיתים את העומס התפעולי בניהול גישת משאבי ענן?" answer: "הצגת מאפיינים מותאמים אישית של OIDC מפחיתה באופן משמעותי את העומס התפעולי על ידי מעבר מתיאור מאגרים בודדים למדיניות גישת ענן. במקום להגדיר ולתחזק תפקידי ענן ידנית עבור כל מאגר בודד, ארגונים יכולים כעת להגדיר מדיניות אמון רחבה יותר המבוססת על ערכי מאפיינים מותאמים אישית כמו 'סביבת ייצור' או 'תאימות צוות פיננסי'. זה מאפשר אכיפת מדיניות על פני קטגוריות של מאגרים, ומפחית באופן דרמטי את הנטל הניהולי. שינויים במבנה הארגוני או בסיווגי מאגרים יכולים להיות מנוהלים באופן מרכזי באמצעות מאפיינים מותאמים אישית, אשר מופצים אוטומטית ל-'OIDC claims', ובכך מפשטים את הציות וניהול בקרת הגישה בקנה מידה."
- question: "האם תוכל לספק דוגמאות כיצד ניתן להשתמש במאפיינים מותאמים אישית של OIDC להגדרת מדיניות אמון מדוקדקת?" answer: "בהחלט. עם מאפיינים מותאמים אישית של OIDC, ארגונים יכולים להגדיר מדיניות אמון ספציפית להפליא. לדוגמה, ניתן להשתמש במאפיין בשם 'environment' עם ערכים כמו 'dev', 'staging', ו-'production'. מדיניות יכולה לקבוע שאסימוני OIDC רק ממאגרים המסומנים 'environment: production' מורשים לפרוס לקבוצת משאבים של Azure בסביבת ייצור. באופן דומה, מאפיין 'compliance_tier' יכול לסווג מאגרים כ-'PCI-DSS' או 'HIPAA-compliant', ולאפשר רק לאסימונים ממאגרים אלה לגשת לאחסון ענן רגיש. מקרה שימוש נוסף הוא 'team_ownership', שבו רק אסימונים ממאגרי 'team_A' יכולים לשנות שירותי ענן ספציפיים של 'team_A', תוך התאמת הגישה למבנים ארגוניים פנימיים ואחריות."
- question: "אילו סוגי התראות יכולים משתמשים לצפות במהלך אירוע מעבר לגיבוי ב-Azure VNET?" answer: "במהלך אירוע מעבר לגיבוי ב-Azure VNET, GitHub מוודאת שמנהלי ארגונים וחברות יישארו מעודכנים באמצעות מספר ערוצים. כאשר מתרחש מעבר לגיבוי, בין אם הופעל ידנית או אוטומטית על ידי GitHub עקב הפסקה אזורית, נוצרים אירועי יומן ביקורת רלוונטיים. בנוסף ליומני ביקורת, מנהלים מושפעים יקבלו גם התראות בדוא'ל. מערכת התראות מרובת ערוצים זו חיונית לתקשורת שקופה, ומאפשרת למנהלים להבין במהירות את מצב תשתית ה-CI/CD שלהם, לפקח על תהליך המעבר לגיבוי, ולנקוט בכל פעולות מעקב נחוצות, כגון חזרה ידנית לאזור הראשי ברגע שהוא הופך לזמין."
## GitHub Actions חושפת עדכונים מהותיים לשיפור גמישות ואבטחת CI/CD
**סן פרנסיסקו, קליפורניה – 3 באפריל 2026** – GitHub Actions, אבן יסוד לשילוב מתמשך ואספקה מתמשכת (CI/CD) בקהילת המפתחים, השיקה סדרת עדכונים משמעותיים שנועדו לשפר את גמישות זרימת העבודה, לחזק את האבטחה ולהבטיח עמידות רבה יותר לצינורות פיתוח מודרניים. מהדורות אלה של תחילת אפריל 2026 מתייחסות לבקשות משתמשים ארוכות טווח ולצרכים תפעוליים קריטיים, ומעניקות למפתחים ולארגונים שליטה ואמינות רבה יותר בזרימות העבודה האוטומטיות שלהם.
העדכונים המרכזיים כוללים את היכולת המצופה מאוד לדרוס נקודות כניסה ופקודות עבור קונטיינרי שירות, תמיכה זמינה כללית במאפיינים מותאמים אישית של מאגרי נתונים באסימוני OpenID Connect (OIDC), ותצוגה מקדימה ציבורית של מעבר לגיבוי ב-Azure VNET עבור מריצי GitHub מתארחים. יחד, תכונות אלו מסמלות את המחויבות המתמשכת של GitHub לפתח את פלטפורמת ה-CI/CD שלה כדי לעמוד בדרישות המתוחכמות של נוף פיתוח התוכנה כיום.
## שיפור זרימות עבודה של GitHub Actions עם ביטולי קונטיינרי שירות
במשך שנים, מפתחים המשתמשים ב-GitHub Actions הביעו רצון לשליטה מדוקדקת יותר על קונטיינרי שירות בתוך זרימות העבודה שלהם. בעבר, דריסה של נקודת הכניסה או הפקודה המוגדרות כברירת מחדל של [קונטיינרי שירות](https://docs.github.com/actions/tutorials/use-containerized-services/use-docker-service-containers) דרשה פתרונות עקיפים מסורבלים, ולעיתים קרובות סיבכה קובצי YAML של זרימת העבודה והפריעה לתהליכי CI/CD יעילים.
GitHub התמודדה עם אתגר זה ישירות עם הצגת מפתחות `entrypoint` ו-`command` חדשים. כעת, משתמשים יכולים לדרוס בצורה חלקה את תצורות האימג'ים המוגדרות כברירת מחדל ישירות מקובץ ה-YAML של זרימת העבודה שלהם, ומשקף את התחביר המוכר והאינטואיטיבי המשמש ב-Docker Compose. עדכון זה מייעל באופן משמעותי את ניהול השירותים מבוססי קונטיינרים כמו מסדי נתונים, מטמונים או כלים מותאמים אישית במהלך ביצוע זרימת העבודה, ומספק גמישות חסרת תקדים. מפתחים יכולים כעת להגדיר בקלות את קונטיינרי השירות שלהם להתנהג בדיוק כפי הנדרש לסביבות בדיקה או בנייה, תוך הפחתת קוד boilerplate ושיפור קריאות זרימת העבודה.
## חיזוק האבטחה: אסימוני OIDC עם מאפיינים מותאמים אישית של מאגרי נתונים
האבטחה בסביבות ענן-נייטיב היא בעלת חשיבות עליונה, ו-GitHub Actions ממשיכה לקדם את יכולותיה בתחום זה. התמיכה במאפיינים מותאמים אישית של מאגרי נתונים בתוך אסימוני OpenID Connect (OIDC) של GitHub Actions זמינה כעת באופן כללי, ועוברת מעבר למעמדה הקודם כתצוגה מקדימה ציבורית. שיפור קריטי זה מאפשר לארגונים להטמיע מאפיינים מותאמים אישית המוגדרים על ידי המשתמש ממאגרי הנתונים שלהם ישירות לתוך אסימוני ה-OIDC המונפקים על ידי GitHub Actions.
מאפיינים מותאמים אישית אלו משמשים כ-'claims' בעלי ערך בתוך אסימון ה-OIDC, ומאפשרים מדיניות אמון מתוחכמת ומדוקדקת יותר עם ספקי ענן שונים. לדוגמה, ארגון יכול להגדיר מאפיין מותאם אישית כמו `environment_type` (לדוגמה, "production", "staging", "development") או `team_ownership` (לדוגמה, "frontend", "backend", "security") ישירות על מאגר נתונים. כאשר זרימת עבודה ממאגר נתונים זה מבקשת אסימון OIDC, מאפיינים אלו נכללים כ-'claims', אשר יכולים להיבחן לאחר מכן על ידי מערכת ניהול זהויות וגישה (IAM) של ספק הענן. מהלך זה לעבר אימות מודע להקשר מחזק את עמדת האבטחה הכוללת של צינורות CI/CD המחוברים לענן.
## ייעול גישת ענן באמצעות מדיניות אמון מדוקדקת של OIDC
השילוב של מאפיינים מותאמים אישית של מאגרי נתונים באסימוני OIDC מציע יתרונות עמוקים לניהול גישת משאבי ענן. הוא מאפשר לארגונים ליצור מדיניות אמון מדוקדקת באמת, תוך חריגה ממגבלות התיאור של שמות או מזהי מאגרי נתונים בודדים בתצורות ספקי ענן. יכולת זו משנה את פניה עבור ארגונים גדולים עם מודלים מורכבים של ממשל.
עם עדכון זה, צוותים יכולים כעת:
* **הגדרת מדיניות אמון מבוססת הקשר**: יצירת כללים המעניקים גישה על בסיס ערכי מאפיינים מותאמים אישית כגון סוג סביבה, בעלות צוות, רגישות נתונים, או רמות תאימות. לדוגמה, רק זרימות עבודה ממאגרים המתויגים `compliance_tier: PCI-DSS` עשויות לקבל גישה למשאבי ענן ספציפיים ומאובטחים ביותר.
* **הפחתת עומס תפעולי**: קיצוץ דרסטי במאמץ הידני הכרוך בתחזוקת תצורות תפקידי ענן לכל מאגר בנפרד. במקום זאת, ניתן להגדיר מדיניות פעם אחת וליישם אותה באופן רחב על בסיס מאפייני המאגר, מה שמפשט את הניהול ככל שמספר המאגרים גדל.
* **התאמה לממשל ארגוני**: שילוב חלק של בקרות גישה לענן עם מודלים קיימים של ממשל מאגרים ארגוניים. זה מבטיח שמדיניות האבטחה תהיה עקבית בין כלים ותהליכים שונים, ומשפר את התאימות ואת יכולת הביקורת.
על ידי מינוף תכונה זו, ארגונים יכולים להשיג גישה חזקה וניתנת להרחבה יותר לאבטחת ענן בתוך זרימות העבודה של GitHub Actions, מה שמקל על [פיתוח מונחה סוכן במדע יישומי של Copilot](/he/agent-driven-development-in-copilot-applied-science) ותרחישי אוטומציה מתקדמים אחרים. לפרטים נוספים על אבטחת זרימות העבודה שלכם, שקלו לבחון משאבים כמו [כיצד לסרוק פגיעויות עם מסגרת מבוססת בינה מלאכותית בקוד פתוח של GitHub Security Labs](/he/how-to-scan-for-vulnerabilities-with-github-security-labs-open-source-ai-powered-framework).
## הבטחת עמידות CI/CD: מעבר לגיבוי ב-Azure Private Networking VNET
בעולם שבו אספקה מתמשכת היא המלך, הבטחת פעולה בלתי פוסקת של צינורות CI/CD היא קריטית. GitHub Actions עושה צעד משמעותי לחיזוק אמינות זו עם התצוגה המקדימה הציבורית של רשת פרטית ב-Azure התומכת במעבר לגיבוי ב-VNET עבור מריצי GitHub מתארחים. תכונה זו מאפשרת לארגונים להגדיר רשת משנה משנית ב-Azure, שיכולה להיות ממוקמת באזור שונה, כדי לשמש כגיבוי.
במקרה שרשת המשנה הראשית הופכת ללא זמינה – אולי עקב הפסקה אזורית או בעיית רשת – זרימות העבודה יכולות להמשיך לרוץ בצורה חלקה ברשת המשנה המיועדת לגיבוי. תהליך המעבר לגיבוי יכול להיות מופעל ידנית באמצעות ממשק המשתמש של תצורת הרשת או ה-REST API, ומספק למנהלים שליטה ישירה, או אוטומטית על ידי GitHub במהלך הפסקה אזורית מזוהה.
הנה סיכום של התכונות החדשות:
| תכונה | תיאור | יתרון מרכזי |
| :---------------------------------- | :------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------- |
| ביטולי נקודת כניסה לקונטיינרי שירות | הגדרת נקודות כניסה ופקודות מותאמות אישית עבור קונטיינרי שירות של Docker ישירות בזרימות עבודה. | גמישות מוגברת, פחות פתרונות עקיפים, תחביר מוכר של Docker Compose. |
| מאפיינים מותאמים אישית של מאגרי OIDC | שילוב מאפיינים מותאמים אישית המוגדרים במאגר כ-'claims' באסימוני OIDC. | בקרת גישה מדוקדקת, תחזוקה מופחתת לתפקידי ענן, מתיישר עם ממשל ארגוני. |
| מעבר לגיבוי ב-Azure VNET | הגדרת רשת משנה משנית ב-Azure עבור מריצים מתארחים, המבטיחה המשכיות במהלך הפסקות. | עמידות משופרת של CI/CD, מעבר לגיבוי אוטומטי/ידני, זמן השבתה מופחת עבור זרימות עבודה קריטיות. |
## צעדים יזומים: מעבר לגיבוי ב-Azure VNET לפעולות בלתי פוסקות
יכולת המעבר לגיבוי ב-VNET היא מחליף משחק עבור חשבונות ארגוניים וחברות המסתמכים במידה רבה על רשת פרטית ב-Azure עבור מריצי GitHub המתארחים שלהם. במהלך אירוע מעבר לגיבוי, מנהלים אינם נשארים בחוסר ידיעה; אירועי יומן ביקורת והודעות דוא"ל נשלחים כדי ליידע את מנהלי הארגונים והחברות על השינוי במצב התפעולי. שקיפות זו חיונית לתגובה לאירועים ולמודעות תפעולית.
חשוב לציין שבעוד שמעבר לגיבוי אוטומטי מספק המשכיות מיידית, אם מעבר לגיבוי מופעל ידנית, המנהלים שומרים על האחריות לחזור לאזור הראשי ברגע שהוא התאושש וזמין במלואו. גישה כפולה זו מציעה גם עמידות אוטומטית וגם שליטה ניהולית, ומאפשרת לארגונים לנהל את תשתית ה-CI/CD שלהם בביטחון ובדיוק. תכונה זו מדגישה את מחויבותה של GitHub לספק תשתית חזקה ואמינה לעומסי עבודה קריטיים בפיתוח.
## עתיד ה-DevOps: זריזות ואבטחה ב-GitHub Actions
עדכונים אחרונים אלה ל-GitHub Actions מדגימים כיוון אסטרטגי ברור: העצמת מפתחים עם יותר שליטה, שיפור האבטחה באמצעות מנגנונים מתוחכמים, והבטחת זמינות מרבית עבור צינורות CI/CD. מפישוט ניהול קונטיינרי שירות ועד להצעת בקרות גישה מתקדמות מבוססות OIDC ורשת Azure עמידה, GitHub מחדדת ומשפרת ללא הרף את הפלטפורמה שלה כדי לעמוד בצרכים המתפתחים של פיתוח תוכנה מודרני. ככל שקצב החדשנות מאיץ, כלים כמו GitHub Actions הם הכרחיים לשמירה על זרימות עבודה זריזות, מאובטחות ויעילות בפיתוח.
שאלות נפוצות
What are the new entrypoint and command overrides for GitHub Actions service containers?
GitHub Actions now allows developers to directly override the default entrypoint and command for service containers within their workflow YAML files. This new functionality addresses previous limitations that often required complex workarounds, providing a more streamlined and flexible approach to managing containerized services. The syntax is designed to be intuitive and familiar, mirroring the conventions used in Docker Compose, thereby reducing the learning curve for developers already accustomed to Docker environments. This enhancement significantly improves how users interact with and customize their CI/CD pipelines when working with services like databases or caches.
How do OIDC custom properties enhance security and simplify cloud access in GitHub Actions?
The general availability of OIDC custom properties for GitHub Actions tokens is a major security upgrade. This feature allows organizations to embed repository-defined custom properties as claims directly within their OpenID Connect (OIDC) tokens. By doing so, they can establish highly granular trust policies with cloud providers based on specific attributes such as environment type, team ownership, or compliance tier, rather than relying on less specific repository names or IDs. This not only strengthens access control by enforcing stricter, context-aware permissions but also drastically simplifies the management overhead associated with configuring cloud roles on a per-repository basis, making cloud access more secure and efficient.
What is Azure VNET failover for GitHub Actions hosted runners, and how does it ensure CI/CD resilience?
Azure private networking for GitHub Actions hosted runners now includes VNET failover capabilities, currently in public preview. This feature allows enterprises and organizations to configure a secondary Azure subnet, potentially in a different geographical region, as a backup. In the event that the primary subnet becomes unavailable due to an outage or other issues, the system can automatically or manually switch to this secondary subnet. This critical functionality ensures continuous operation of CI/CD workflows, significantly reducing downtime and maintaining the reliability of development pipelines, especially for mission-critical applications that demand high availability.
Which GitHub Actions users will benefit most from the new Azure VNET failover capabilities?
The Azure VNET failover feature is specifically designed for enterprise and organization accounts that utilize Azure private networking with GitHub-hosted runners. It is particularly beneficial for organizations with stringent uptime requirements, those operating in multi-region deployments, or those handling critical workloads where any disruption to CI/CD pipelines can lead to significant business impact. Companies prioritizing high availability and disaster recovery strategies for their development infrastructure will find this feature invaluable for maintaining operational continuity and enhancing the overall resilience of their software delivery lifecycle, offering peace of mind during regional outages.
How do the new OIDC custom properties reduce operational overhead for cloud resource access management?
The introduction of OIDC custom properties significantly reduces operational overhead by moving away from individual repository enumeration for cloud access policies. Instead of manually configuring and maintaining cloud roles for every single repository, organizations can now define broader trust policies based on custom property values like 'production-environment' or 'finance-team-compliance'. This allows for policy enforcement across categories of repositories, dramatically cutting down the administrative burden. Changes to organizational structure or repository classifications can be managed centrally via custom properties, which automatically propagate to OIDC claims, simplifying compliance and access control management at scale.
Can you provide examples of how OIDC custom properties can be used to define granular trust policies?
Certainly. With OIDC custom properties, organizations can define incredibly specific trust policies. For example, a property called `environment` with values like `dev`, `staging`, and `production` can be used. A policy could then dictate that only OIDC tokens from repositories marked `environment: production` are allowed to deploy to a production Azure resource group. Similarly, a `compliance_tier` property could classify repositories as `PCI-DSS` or `HIPAA-compliant`, allowing only tokens from these repositories to access sensitive cloud storage. Another use case is `team_ownership`, where only tokens from `team_A` repositories can modify `team_A` specific cloud services, aligning access with internal organizational structures and responsibilities.
What kind of notifications can users expect during an Azure VNET failover event?
During an Azure VNET failover event, GitHub ensures that enterprise and organization administrators are kept informed through multiple channels. When a failover occurs, whether triggered manually or automatically by GitHub due to a regional outage, relevant audit log events are generated. In addition to audit logs, affected administrators will also receive email notifications. This multi-channel notification system is crucial for transparent communication, allowing administrators to quickly understand the status of their CI/CD infrastructure, monitor the failover process, and take any necessary follow-up actions, such as manually switching back to the primary region once it becomes available.
הישארו מעודכנים
קבלו את חדשות ה-AI האחרונות לתיבת הדוא״ל.
