Coroidמפעל התוכנה שלך של AI
תיעוד

אירועי פריסה והגדרת CI

חברו את GitHub Actions, GitLab CI/CD או מערכת CI אחרת להיסטוריית הפריסות של Release.

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

Coroid

ה-CI/CD שלכם

סביבה

  1. 1.התחלה עבור התיקון המדויק
  2. 2.פריסה התיקון המקובע
  3. 3.דוח התהליך פועל, לאחר מכן מצליח או נכשל – יחד עם הגרסה שהופצה.
  4. 4.מעקב אחר המצב התקין עם בדיקת קנרי
פריסה נספרת רק לאחר שהפייפליין שלכם מדווח על הצלחה. שלב 1 מושמט כאשר הפייפליין מתחיל באופן עצמאי.

כל ההגדרות שלהלן מוגדרות לפי סביבה בהגדרות הפרויקט: הגדרות → גרסאות → צינור פריסהיצרו שם אסימון דיווח. בעלים או מנהל רואים אותו פעם אחת בלבד. שמרו אותו כסוד בצינור ה-CI של אותה סביבה. Coroid שומר רק על גיבוב, והחלפת האסימון מבטלת מיד את הקודם. האסימון יכול לדווח רק עבור הפרויקט והסביבה שלו. לעולם לא שמרו אותו בקובץ מאגר או בבקשת דפדפן.

GitHub Actions ו-GitLab CI/CD

אם ברצונכם שה- פריסה ל… כפתור בדף הפריסה, בחרו Coroid מפעיל תהליך עבודה של GitHub Actions או Coroid מפעיל צינור של GitLab CI/CD בהגדרות צינור הפריסה של הסביבה. הזינו את שם משימת הפריסה המדויק, את הענף או התג, ואת שם קובץ התהליך של GitHub ככל שחל על כך. הענף/תג חייבים להצביע על קומיט השחרור בזמן הבקשה. תהליך העבודה של GitHub מקבל coroid_release_id, coroid_attempt_id, coroid_commit_sha, ו- coroid_environment קלטים, בנוסף coroid_version, coroid_build_number ו- coroid_release_name כאשר תהליך העבודה מגדיר אותם. GitLab מקבל את המשתנים המרומזים באותיות גדולות המקבילים COROID_* משתנים. השתמשו בערכים אלה כדי לבצע פריסה ולדווח על ה-SHA והניסיון המדויקים. הזינו את הגרסה בבנייה שלכם מסביר כיצד לסמן את הגרסה בבנייה.

שמרו את אסימון ההתקשרות של הסביבה בסודות של GitHub Actions או במשתנים מוסתרים של GitLab CI/CD. שלחו running אירוע כאשר משימת הפריסה מתחילה ו- succeeded, failed, או cancelled אירוע כאשר היא מסתיימת. Coroid בודק את הפעולה של הספק, הקומיט והמשימה המסוימת לפני שמקבל הצלחה עבור צינור פריסה מוגדר. כתובת ה-URL של הפעולה של הספק נשארת המקום לבדיקת לוגים. ה תהליך העבודה לייצור של Coroid מכיל דוגמה מעשית של GitHub Actions; התאימו את שמות הסודות והמשימה למאגר שלכם.

התקשרות CI כללית

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

POST /api/v1/release-deployment-events
Authorization: Bearer <environment-callback-token>
Content-Type: application/json
{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-24T12:00:00Z",
  "runUrl": "https://ci.example.com/runs/812"
}

כללו releaseId ו- attemptId כאשר מדווחים על פעולה שנדרשה על ידי Coroid. הוסיפו version ו- buildNumber כדי לתעד מה פרסמתם. עבור פרויקט המאוחסן ב-Coroid, repository הוא מזהה הפרויקט. failureReason יכול להסביר פעולה שנכשלה. השתמשו ב- queued, running, succeeded, failed, או cancelled עבור status. שמרו על אחד providerRunId לאורך כל הפעולה ותנו למעבר בין מצבים זיהוי ייחודי eventId. ניסיון חוזר של אותו אירוע צריך לשמור על אותו מזהה; פעולת CI חדשה דורשת מזהה פעולה חדש. חותמת הזמן של האירוע חייבת להיות עדכנית. Coroid בודק את המאגר, הסביבה, הקומיט, טווח האישורים ומצב הסיום לפני יישום; אירועים סותרים נשמרים לביקורת. פריסה תקינה ללא שחרור מוכן יכולה ליצור שחרור שנצפה, השונה באופן ברור ממועמד שאושר מראש.

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