קובען מגיב למשהו שקורה ב־Coroid. אתם בוחרים אירוע, כותבים הוראות בשפה פשוטה, והקובען מתבצע כשהאירוע מתרחש.
תוכלו למצוא אותם במפעל, תחת הכרטיסייה אוטומציות.
יצירה של רוטינת אוטומציה ב־עבודה חדשה: בחרו באפשרות אוטומציה, ולאחר מכן באפשרות כאשר משהו קורה. עבודה חדשה מספקת את אירועי ה־GitHub ואת אירועי ה־Coroid. עיינו ב‑ אוטומציות.
אירועים שניתן להגיב אליהם
קובען מתבצע רק עבור אירוע שמשהו שולח. Coroid שולח את רוב האירועים המופיעים למטה. כמה מהם נשלחים על ידי המערכות שלכם. כל אירוע אחר הוא שמור: העורך לא מציג אותו, וקובען חדש עליו נדחה. אם קובען נשמר על אירוע שמור, העורך והרשימה מסמנים אותו כלא מתבצע לעולם; הוא לא נמחק.
אירועים ש־Coroid שולח
| קטגוריה | אירועים |
|---|---|
| משימה | נוצר, מצב השתנה, הושלם, נכשל |
| סוכן | התחיל, הושלם, שגיאה |
| מאגר | התחייבות נדחפה, ענף נוצר, pull request נפתח, עודכן או מוזג, בעיה נפתחה, תגובה שמזכירה את Coroid |
| ספרינט | נוצר, תכנון התחיל, התחיל, משימה נוספה, משימה הוסרה, ביקורת התחילה, הושלם, בוטל |
| תוכנית | שלב התחיל, הושלם, נכשל |
| לוח זמנים | הפעלה התחילה, הפעלה הושלמה, הפעלה נכשלה |
| דוח | התחיל, הושלם, נכשל |
| איכות | בדיקה התחילה, עברה או נכשלה; לא נפתרה באופן אוטונומי |
| קידום | נתבקש, אושר, נדחה |
| שחרור | נוצר, המועמד השתנה, ההערות השתנו, ההערות אושרו, היקף השתנה, רשימת הבדיקה הושלמה, השער נבדק, השער בוטל, אושר, פורסם, הוחזר |
| פריסה | נמצא בתור, פועל, הצליח, נכשל, בוטל, אושר ידנית, ההחזרה אושרה ידנית, בדיקת בריאות עברה, בדיקת בריאות נכשלה |
| סינכרון | המקור החיצוני עודכן |
| Slack ו־Telegram | הודעה שתואמת את מסנן האוטומציה |
אירועים שהמערכות שלכם שולחות
| קטגוריה | אירועים |
|---|---|
| ניתוח | תלות נמצאה, בעיית אבטחה נמצאה, הניתוח הושלם |
| פריסה חיצונית | התחיל, הושלם, נכשל |
Coroid לא שולח את אלה. צינור CI, סורק או מערכת אחרת שלכם משגרים את הקובען לפי המזהה שלו: הוא קורא ל־ POST /api/v1/organizations/hooks/:id/dispatch
עם המפתח של חשבון שירות
שיש לו את hooks:dispatch ההיקף. הקובען מתבצע עבור האירוע שעליו נשמר. העורך מציג אירועים אלה תחת הכותרת 'נשלח על ידי המערכות שלכם'.
אירועים שמורים
אלה עדיין לא נשלחו או התבצעו, לכן העורך לא מציע אותם:
| קטגוריה | אירועים |
|---|---|
| משימה | שלב השתנה |
| סוכן | איטרציה, כלי שנקרא |
| תוכנית | נוצר, שלב הושלם, ביקורת סופית התחילה, ביקורת סופית הושלמה, לפני pull request של התוכנית |
| לוח זמנים | נוצר, הופעל, נעצר |
| ספרינט | תכנון הושלם, משימה הושלמה, היקף השתנה |
| שחרור | הוכן לשימוש, אושר |
| קידום | לפני pull request של הקידום |
| איכות | הבדיקה אינה זמינה; תיקון התחיל או ניסה; אימות מחדש התחיל; הסכמה הושגה |
כשהעבודה מתחילה ומסתיימת
תוכניות, לוחות זמנים, דוחות, בדיקות איכות, קידומים ושחרורים שולחים אירוע כשהם מתחילים ואירוע כשהם מסתיימים. קובען יכול להגיב לאופן שבו העבודה הסתיימה, והמערכת שלכם יכולה למדוד כמה זמן נדרש לכך.
| עבודה | מתחילה | מסתיימת |
|---|---|---|
| תוכנית | שלב התחיל: הראשון נשלח כשהביצוע של התוכנית מתחיל | הושלם, נכשל |
| לוח זמנים | הפעלה התחילה | הפעלה הושלמה, הפעלה נכשלה |
| דוח | התחיל | הושלם, נכשל |
| בדיקת איכות | בדיקה התחילה | עברה, נכשלה, לא נפתרה באופן אוטונומי |
| קידום | נתבקש | אושר, נדחה |
| שחרור | נוצר | פורסם, הוחזר |
כל אחד מהאירועים האלה רושם את הזמן שבו הוא התרחש ב־ occurredAt. אירוע שמדווח על סיום העבודה רושם גם את זמן תחילת העבודה ב־
startedAt, ואת משך הזמן שנדרש ב־ durationMs. זה startedAt הוא
occurredAt של אירוע ההתחלה, כך שהשניים תמיד תואמים. הזמן שבו העבודה נעצרה נספר כחלק ממשך הזמן.
כל אירוע נשלח פעם אחת, כאשר השינוי נשמר. שינוי שבוטל אינו שולח דבר, וניסיון חוזר אינו שולח דבר פעמיים. אירוע סיום נשלח רק עבור עבודה שהתחילה: הפעלה של לוח זמנים בדרך כלל אינה שולחת דבר, וכך גם דוח שבוטל לפני שהתחיל.
מה שכל אירוע נושא, מלבד הזמנים:
| אירוע | נשלח כאשר | שדות |
|---|---|---|
| שלב התכנון החל | ביצוע התכנון מתחיל (שלבו הראשון), ולאחר מכן בכל פעם שמשימת השלב הראשונה מתחילה. | planId, plan (id, כותרת), phase (id, רצף, כותרת), firstPhase, executionStartedAt |
| התכנון הסתיים או נכשל | ביצוע התכנון מסתיים. תכנון שנכשל במהלך תהליך התכנון אינו שולח דבר. | planId, plan, status, executionStartedAt |
| הפעלת לוח זמנים החלה | הפעלת לוח זמנים מתחילה. | scheduleId, runId, schedule (id, שם), run (סיבה להפעלה, הפעלה אב) |
| הפעלת לוח זמנים הסתיימה או נכשלה | ההפעלה מסתיימת. | אותם שדות, status, ו- tasksCreated או error |
| הדוח החל | הדוח מתחיל להיווצר. הפסקה והמשך פעילות שומרים על אותו נקודת התחלה. | reportId, report (id, סוג, כותרת) |
| הדוח הסתיים או נכשל | הדוח נשמר, או שהוא נכשל או בוטל. | אותם שדות, ו- tokensUsed, costUsd ו- hasActionableFindings, או error |
| בדיקת איכות החלה | בדיקת איכות מתחילה. | qualityRunId, check (נושא, גורם הפעלה, גרסת מדיניות, commit) |
| בדיקת האיכות עברה או נכשלה | הבדיקה מגיעה למסקנה שלה. | אותם שדות, decision, redoCause, failedExpectationIds |
| בדיקת איכות לא נפתרה באופן אוטונומי | Coroid מפסיק לנסות לתקן את מה שנמצא בבדיקה. | qualityRunId, workItemType, workItemId, reason |
| ביקוש לקידום נוצר | קידום נוצר. | promotionId, laneId, promotion (כותרת, מצב, ענפים, pull request) |
| הקידום אושר | הקידום ממוזג: מאושר ב־Coroid, ממוזג בכוח, ממוזג אצל הספק או משולב בגרסה. | אותם שדות, approval, approvedBy, forceReason |
| הקידום נדחה | המבקר מבקש שינויים. | אותם שדות, reason, requestedBy, comment |
| הגרסה פורסמה | הפריסה הראשונה של הגרסה לסביבת ייצור מצליחה. | releaseId, version, commitSha |
| הגרסה הוחזרה | החזרה מחליפה את הגרסה בסביבה. | releaseId, version, rolledBackToReleaseId |
אירועים על עבודה בפרויקט נושאים גם projectId, כך שחיבור המוגבל לפרויקט אחד יופעל רק עבור אותו פרויקט. אם החיבור יצר את העבודה, אירועים אלו נספרים כחלק מעומק השרשרת של אותו חיבור.
מפעילים ויעדים
לכל אוטומציה יש מקור הפעלה, שממנו מגיעים האירועים שלה, ויעד, שקובע מה קורה כאשר אירוע מופעל. שני היעדים הופכים אירוע לעבודה.
| מקור הפעלה | אירועים |
|---|---|
| אירוע זרם עבודה | אירועים ב־Coroid, כפי שמופיע בטבלה לעיל |
| GitHub | בקשת Pull Request נפתחה, עודכנה או ממוזגה; בעיה נפתחה; תגובה המזכירה את Coroid |
| Slack | הודעה התואמת את מסנן האוטומציה |
| Telegram | הודעה התואמת את מסנן האוטומציה, כגון כזו המתחילה ב־/coroid |
| Jira | בעיה חדשה |
| יעד | מה קורה |
|---|---|
| חיבור | מפעיל את ההוראות שלך, לקריאה בלבד, כפי שמתואר בעמוד זה. |
| לאשר עבודה | מאחסן את האירוע כבקשה. לאחר שאישור העבודה עובר, Coroid יוצר את העבודה. |
| Coroid Check | פרש. סקירת Coroid של כל pull request מוגדרת ב־ בקרת איכות; האוטומציות הקיימות הושהו. |
לאירועי GitHub נדרשת האפליקציה של GitHub. תגובה המזכירה את Coroid נספרת רק כאשר למחברה יש גישת כתיבה למאגר. ראה GitHub.
משימה מ־אישור עבודה מתחילה מעצמה רק כאשר מחבר האירוע נחשב אמין: מחבר של GitHub pull request, בעיה או תגובה שיש לו גישת כתיבה למאגר. מחברי Slack, Telegram ו־Jira אינם נחשבים אמינים, כך שמשימותיהם מחכות שמישהו יפעיל אותן. ראה מתי העבודה מתחילה.
בעיות חדשות ב-Jira מגיעות ל-Coroid רק דרך ה-webhook של Jira. הוא מקבל רק נתונים שנחתמו בסודי ה-webhook שהוגדרו עבור Coroid, רק עבור בעיות חדשות, ורק כאשר מפתח הפרויקט של Jira תואם לפרויקט של Coroid. באתר coroid.ai ה-webhook של Jira עדיין לא הוגדר, ולכן המנגנון של Jira אינו מקבל אירועים; יש לייבא את הבעיות מ-Jira במקום זאת. כאשר ה-webhook מוגדר, בעיה חדשה מגיעה לאוטומציות שבמנגנון של Jira, כמו מקור הבקשה מ-Jira ב-בקרת איכות, שיוצר בעיות מסוגים ובעדיפויות שתבחרו עבור תהליך ההתאמה. ללא אוטומציה במנגנון, בעיה חדשה לא תיצור שום תוצאה. עבודה מ-Jira לעולם לא מתחילה מעצמה. ראו. מעקב אחר בעיות.
לקריאה בלבד כברירת מחדל
ה-hooks מנתחים ומדווחים. הם יכולים ליצור משימות נוספות; הם אינם משנים את הקוד שלכם ישירות.
דווקא ברירת המחדל הזו הופכת אותם לבטוחים לשימוש. אוטומציה שמשנה קוד בתגובה לאירוע פועלת ברגע שבו סביר שאיש לא יפקח עליה. hook ש פותח משימה מספק את אותה תוצאה דרך התהליך הרגיל — תיאור, תכנון, אימות, בדיקה, pull request.
- תזמוןזמן
- אוטומציית אירועיםמשהו קורה.
משימה רגילה
מפרט, תוכנית, בנייה, אימות, ביקורת. משתמשת במקום סוכן; הקצו לה עדיפות נמוכה יותר.
P2P3pull request
היא אינה יכולה לאחד את עצמה או לבצע commit לענף הבסיס שלכם.
אתם מאשרים
כתיבת הוראות טובות
הוראות ה-hook מעובדות על ידי מודל, ולכן הן נראות כמו הוראות לעמית ולא כמו קוד. רמת האיכות זהה לזו של תיאור: ציינו מה לבדוק, מה חשוב, ומה לעשות.
היו ספציפיים לגבי מקרה של 'לא לעשות דבר'. ללא זאת, hook ימצא משהו לומר בכל פעם שהוא פועל, ו-hooks שפועלים תמיד הם כאלה שאנשים מפסיקים לקרוא.
מגבלות
קיימות שלושה אמצעי הגנה מכיוון שאוטומציה מבוססת אירועים נכשלת בדרכים צפויות:
מגבלות קצב. לדקה, לשעה וליום, ניתן להגדיר לכל hook. hook על אירוע בתדירות גבוהה עלול לפעול מאות פעמים במהלך מיזוג עמוס.
עומק שרשרת. Hooks יכולים להפעיל אירועים שמפעילים hooks נוספים. עומק שרשרת מרבי מונע היווצרות של לולאה.
הרשאות כלים. מה ש-hook יכול לגשת אליו נשלט — גישת קריאה בלבד, קריאות MCP ויצירת משימות נשלטים בנפרד.
הרשאות
רק בעלי זכויות ומנהלים יכולים ליצור, לשנות, לבדוק או למחוק hook; כל החברים יכולים לראות את ה-hooks ואת היסטוריית הביצועים שלהם. מכיוון ש-hook פועל ברמת הארגון, אי-השוויון הזה מכוון.
מעקב אחריהם
דף ה-hook בפלטפורמה מציג את הפעולות שלו ומה שעשה ב-30 הימים האחרונים: פעולות, כישלונות ועלות. כל פעולת אוטומציה מופיעה גם ב-הגדרות → פעילות, עם סינון לפי אוטומציה. בדקו את הפעולות שלו לאחר הפעלת hook חדש — מצב הכישלון אינו שגיאה, אלא פעולה תמידית שאינה מניבה תוצאה שאיש יפעל לפיה.
Hooks ולוחות זמנים
| מנגנון | מופעל על ידי |
|---|---|
| Hook | אירוע פלטפורמה |
| לוח זמנים | זמן |
שניהם הם אוטומציות, המופיעות יחד בפלטפורמה. ראו אוטומציות.