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

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

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

פעולות GitHub ו-GitLab CI/CD#

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

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

התקשרות 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. failureReason יכול להסביר פעולה שנכשלה. השתמשו ב- queued, running, succeeded, failed, או cancelled עבור status. שמרו עותק אחד של providerRunId לאורך כל הפעולה ותנו למעבר בין מצבים ערך ייחודי eventId. ניסיון חוזר לאותו אירוע צריך לשמור על אותו מזהה; פעולת CI חדשה דורשת מזהה פעולה חדש. חותמת הזמן של האירוע חייבת להיות עדכנית. Coroid בודק את המאגר, הסביבה, ההתחייבות, טווח האישורים ומצב הסיום לפני יישום האירוע; אירועים סותרים נשמרים לבדיקה. פריסה תקינה ללא גרסה מוכנה יכולה ליצור גרסה שנצפתה, השונה באופן ברור ממועמד שאושר מראש.

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

קשור#

• הגדרות גרסה
• גרסאות
• התאוששות ומסלולי גרסאות