Ein Hook reagiert auf ein Ereignis in Coroid. Sie wählen ein Ereignis aus, verfassen die Anweisungen in einfacher Sprache – der Hook wird ausgelöst, sobald das Ereignis eintritt.
Sie finden sie im System unter Automatisierungen.
Erstellen Sie eine neue Aufgabe unter Neue Aufgaben: Wählen Sie Automatisierung aus und anschließend die Option „Wenn etwas passiert“. Neue Aufgaben bieten die GitHub-Ereignisse sowie die Ereignisse von Coroid an. Weitere Informationen finden Sie unter Automatisierungen.
Ereignisse, auf die reagiert werden kann
Ein Hook wird nur für ein Ereignis ausgelöst, das von einem System gesendet wird. Coroid sendet die meisten der unten aufgeführten Ereignisse. Einige werden von Ihren eigenen Systemen ausgelöst. Alle anderen Ereignisse sind reserviert: Der Editor listet sie nicht auf, und ein neuer Hook für solche Ereignisse wird abgelehnt. Wenn ein Hook für ein reserviertes Ereignis gespeichert wurde, kennzeichnen der Editor und die Liste ihn als niemals auslösend; er wird jedoch nicht gelöscht.
Ereignisse, die Coroid sendet
| Kategorie | Ereignisse |
|---|---|
| Aufgabe | Erstellt, Status geändert, abgeschlossen, fehlgeschlagen |
| Agent | Gestartet, abgeschlossen, Fehler |
| Repository | Commit gepusht, Branch erstellt, pull request geöffnet, aktualisiert oder zusammengeführt, Issue geöffnet, Kommentar, der Coroid erwähnt |
| Sprint | Erstellt, Planung gestartet, gestartet, Aufgabe hinzugefügt, Aufgabe entfernt, Review gestartet, abgeschlossen, abgebrochen |
| Plan | Phase gestartet, abgeschlossen, fehlgeschlagen |
| Zeitplan | Ausführung gestartet, Ausführung abgeschlossen, Ausführung fehlgeschlagen |
| Bericht | Gestartet, abgeschlossen, fehlgeschlagen |
| Qualität | Prüfung gestartet, bestanden oder fehlgeschlagen; automatisch nicht gelöst |
| Promotion | Angefordert, genehmigt, abgelehnt |
| Release | Erstellt, Kandidat geändert, Notizen geändert, Notizen genehmigt, Umfang geändert, Checkliste abgeschlossen, Prüfschritt ausgewertet, Prüfschritt überschrieben, genehmigt, veröffentlicht, zurückgerollt |
| Bereitstellung | In der Warteschlange, läuft, erfolgreich, fehlgeschlagen, abgebrochen, manuell bestätigt, Rollback manuell bestätigt, Health-Check bestanden, Health-Check fehlgeschlagen |
| Synchronisation | Externe Quelle aktualisiert |
| Slack und Telegram | Eine Nachricht, die dem Filter der Automatisierung entspricht |
Ereignisse, die von Ihren eigenen Systemen ausgelöst werden
| Kategorie | Ereignisse |
|---|---|
| Analyse | Abhängigkeit gefunden, Sicherheitsproblem gefunden, Analyse abgeschlossen |
| Externe Bereitstellung | Gestartet, abgeschlossen, fehlgeschlagen |
Coroid sendet diese Ereignisse nicht. Eine CI-Pipeline, ein Scanner oder ein anderes Ihrer Systeme löst den Hook über seine ID aus: dafür wird POST /api/v1/organizations/hooks/:id/dispatch
mit dem Schlüssel eines Dienstkontos
verwendet, das das hooks:dispatch Scope besitzt. Der Hook wird für das Ereignis ausgelöst, für das er gespeichert wurde. Der Editor listet diese Ereignisse unter „Von Ihren eigenen Systemen ausgelöst“ auf.
Reservierte Ereignisse
Diese Ereignisse wurden noch nicht gesendet oder ausgelöst – daher bietet der Editor sie nicht an:
| Kategorie | Ereignisse |
|---|---|
| Aufgabe | Phase geändert |
| Agent | Iteration, Tool aufgerufen |
| Plan | Erstellt, Phase abgeschlossen, finale Review gestartet, finale Review abgeschlossen, vor dem pull request des Plans |
| Zeitplan | Erstellt, aktiviert, pausiert |
| Sprint | Planung abgeschlossen, Aufgabe abgeschlossen, Umfang geändert |
| Release | Staging-Phase, validiert |
| Promotion | Vor dem pull request der Promotion |
| Qualität | Prüfung nicht verfügbar; Reparatur gestartet oder versucht; Revalidierung gestartet; Konsens erreicht |
Wann die Arbeit beginnt und endet
Pläne, Zeitpläne, Berichte, Qualitätsprüfungen, Promotions und Releases senden ein Ereignis beim Start und ein Ereignis beim Ende. Ein Hook kann auf das Ergebnis der Arbeit reagieren – Ihr System kann außerdem die Dauer der Arbeit messen.
| Arbeit | Beginnt | Endet |
|---|---|---|
| Plan | Phase gestartet: Das erste Ereignis wird gesendet, sobald die Ausführung des Plans beginnt. | Abgeschlossen, fehlgeschlagen |
| Zeitplan | Ausführung gestartet | Ausführung abgeschlossen, Ausführung fehlgeschlagen |
| Bericht | Gestartet | Abgeschlossen, fehlgeschlagen |
| Qualitätsprüfung | Prüfung gestartet | Bestanden, fehlgeschlagen, automatisch nicht gelöst |
| Promotion | Angefordert | Genehmigt, abgelehnt |
| Release | Erstellt | Veröffentlicht, zurückgerollt |
Jedes dieser Ereignisse protokolliert den Zeitpunkt seines Eintretens in occurredAt. Ein Ereignis, das das Ende der Arbeit meldet, protokolliert auch den Startzeitpunkt der Arbeit in
startedAt, und die Dauer der Arbeit in durationMs. Das startedAt ist der
occurredAt des Start-Ereignisses – die beiden stimmen daher immer überein. Die während einer Pause verbrachte Zeit zählt zur Dauer dazu.
Jedes Ereignis wird einmal gesendet, wenn die Änderung gespeichert wird. Eine rückgängig gemachte Änderung sendet nichts, und ein erneuter Versuch sendet ebenfalls nichts zweimal. Ein End-Ereignis wird nur für begonnene Aufgaben gesendet: Ein Trockenlauf eines Plans sendet nichts, genauso wie ein Bericht, der vor dem Start abgebrochen wurde.
Was jedes Ereignis neben den Zeiten enthält:
| Ereignis | Wird gesendet bei | Felder |
|---|---|---|
| Planungsphase gestartet | Die Ausführung des Plans beginnt (seine erste Phase), und später jeweils, wenn die erste Aufgabe einer weiteren Phase startet. | planId, plan (id, Titel), phase (id, Reihenfolge, Titel), firstPhase, executionStartedAt |
| Plan abgeschlossen oder fehlgeschlagen | Die Ausführung des Plans endet. Ein Plan, der während der Planung fehlschlägt, sendet nichts. | planId, plan, status, executionStartedAt |
| Scheduling-Lauf gestartet | Ein Scheduling-Lauf beginnt. | scheduleId, runId, schedule (id, Name), run (Auslöser-Grund, übergeordneter Lauf) |
| Scheduling-Lauf abgeschlossen oder fehlgeschlagen | Der Lauf endet. | Die gleichen Felder, status, und tasksCreated oder error |
| Bericht gestartet | Ein Bericht beginnt mit der Erstellung. Beim Pausieren und Fortsetzen bleibt der Startzeitpunkt gleich. | reportId, report (id, Typ, Titel) |
| Bericht abgeschlossen oder fehlgeschlagen | Der Bericht wird gespeichert, oder er schlägt fehl bzw. wird abgebrochen. | Die gleichen Felder, und tokensUsed, costUsd und hasActionableFindings, oder error |
| Qualitätsprüfung gestartet | Eine Qualitätsprüfung beginnt. | qualityRunId, check (Betreff, Auslöser, Richtlinienversion, Commit) |
| Qualitätsprüfung bestanden oder fehlgeschlagen | Die Prüfung erreicht ihr Ergebnis. | Die gleichen Felder, decision, redoCause, failedExpectationIds |
| Qualität automatisch nicht gelöst | Coroid versucht nicht mehr, das von einer Prüfung festgestellte Problem zu beheben. | qualityRunId, workItemType, workItemId, reason |
| Promotion angefordert | Eine Promotion wird erstellt. | promotionId, laneId, promotion (Titel, Status, Branches, pull request) |
| Promotion genehmigt | Die Promotion wird zusammengeführt: In Coroid genehmigt, erzwungen zusammengeführt, beim Provider zusammengeführt oder in einem Release ausgeliefert. | Die gleichen Felder, approval, approvedBy, forceReason |
| Promotion abgelehnt | Ein Prüfer fordert Änderungen an. | Die gleichen Felder, reason, requestedBy, comment |
| Release veröffentlicht | Die erste Produktionsbereitstellung des Releases ist erfolgreich. | releaseId, version, commitSha |
| Release zurückgesetzt | Ein Rollback ersetzt den Release in einer Umgebung. | releaseId, version, rolledBackToReleaseId |
Ereignisse zu Aufgaben in einem Projekt enthalten auch projectId, sodass ein Hook, der auf ein
Projekt beschränkt ist, nur für dieses Projekt ausgelöst wird. Wenn ein Hook die Aufgabe erstellt hat, zählen diese Ereignisse zur Kettentiefe dieses Hooks.
Auslöser und Ziele
Jede Automatisierung hat eine Auslöserquelle, aus der ihre Ereignisse stammen, sowie ein Ziel, das bestimmt, was beim Auslösen geschieht. Zwei der Ziele wandeln ein Ereignis in eine Aufgabe um.
| Auslöserquelle | Ereignisse |
|---|---|
| Workflow-Ereignis | Ereignisse in Coroid, wie in der obigen Tabelle dargestellt. |
| GitHub | Pull-Request geöffnet, aktualisiert oder zusammengeführt; Issue geöffnet; ein Kommentar, der Coroid erwähnt. |
| Slack | Eine Nachricht, die dem Filter der Automatisierung entspricht. |
| Telegram | Eine Nachricht, die dem Filter der Automatisierung entspricht, etwa eine, die mit /coroid beginnt. |
| Jira | Ein neues Issue |
| Ziel | Was geschieht? |
|---|---|
| Hook | Führt Ihre Anweisungen aus – nur zum Lesen, wie auf dieser Seite beschrieben. |
| Aufgabe qualifizieren | Das Ereignis wird als Anfrage gespeichert. Sobald die Qualifikation erfolgreich ist, erstellt Coroid die Aufgabe. |
| Coroid Check | Nicht mehr verwendet. Die Coroid Rezension aller pull request wird in Qualitätskontrolle; bestehende Automatisierungen wurden pausiert. |
GitHub-Ereignisse benötigen die GitHub App. Ein Kommentar, der Coroid erwähnt, zählt nur, wenn sein Autor Schreibzugriff auf das Repository hat. Siehe GitHub.
Eine Aufgabe aus „Aufgabe qualifizieren“ startet von selbst nur, wenn der Autor des Ereignisses vertrauenswürdig ist: der Autor eines GitHub pull request, Issues oder Kommentars, der Schreibzugriff auf das Repository hat. Autoren aus Slack, Telegram und Jira sind niemals vertrauenswürdig – ihre Aufgaben warten darauf, dass jemand sie startet. Siehe Wann die Aufgabe startet.
Neue Jira-Tickets erreichen Coroid ausschließlich über dessen Jira-Webhook. Er akzeptiert nur Zustellungen, die mit dem für Coroid eingerichteten Webhook-Geheimnis signiert sind, nur für neue Tickets und nur, wenn der Jira-Projektschlüssel des Tickets zu einem Coroid-Projekt passt. Auf coroid.ai ist der Jira-Webhook noch nicht eingerichtet, weshalb ein Jira-Trigger keine Ereignisse empfängt; importieren Sie Jira-Tickets stattdessen. Wo der Webhook eingerichtet ist, gelangt ein neues Ticket zu den Automatisierungen im Jira-Trigger, wie etwa zur Jira-Anfragenquelle in der Qualitätskontrolle, die Tickets der von Ihnen für die Qualifizierung gewählten Typen und Prioritäten erstellt. Ohne Automatisierung im Trigger wird kein Ticket erstellt. Die Arbeit aus Jira beginnt niemals von selbst. Siehe Issue-Tracker.
Standardmäßig nur zum Lesen
Hooks analysieren und berichten. Sie können nachfolgende Arbeiten erstellen; sie ändern Ihren Code jedoch nicht direkt.
Dieser Standard macht ihre Einführung sicher. Eine Automatisierung, die in Reaktion auf ein Ereignis Code bearbeitet, wirkt genau zu einem Zeitpunkt, zu dem kaum eine Überwachung stattfindet. Ein Hook, der eine Aufgabe öffnet erzielt dasselbe Ergebnis über den normalen Weg – Spezifikation, Planung, Verifizierung, Review, pull request.
- ZeitplanZeit
- Ereignisbasierte AutomatisierungEtwas tritt ein.
Eine gewöhnliche Aufgabe
Spezifikation, Plan, Erstellung, Überprüfung, Review. Nutzt einen Agenten-Slot; weisen Sie ihm eine niedrigere Priorität zu.
P2P3Ein pull request
Es kann sich nicht selbst zusammenführen oder in Ihren Basis-Branch committen.
Sie genehmigen
Gute Anweisungen schreiben
Hook-Anweisungen werden von einem Modell verarbeitet, weshalb sie wie Anweisungen an einen Kollegen klingen und nicht wie Code. Der Qualitätsstandard entspricht dem für eine Spezifikation: Beschreiben Sie, worauf zu achten ist, was von Bedeutung ist und was zu tun ist.
Seien Sie beim Fall „nichts tun“ konkret. Ohne diese Angabe würde ein Hook jedes Mal etwas zu sagen haben, und Hooks, die ständig ausgelöst werden, werden von den Nutzern nicht mehr gelesen.
Sicherheitsvorkehrungen
Es gibt drei Schutzmechanismen, weil ereignisgesteuerte Automatisierungen vorhersehbare Fehler aufweisen:
Auslastungsgrenzen. Pro Minute, Stunde und Tag konfigurierbar pro Hook. Ein Hook für ein Ereignis mit hoher Frequenz könnte sonst während eines aktiven Merge-Vorgangs hunderte Male ausgelöst werden.
Kettenlänge. Hooks können Ereignisse auslösen, die wiederum Hooks auslösen. Eine maximale Kettenlänge verhindert, dass daraus eine Schleife entsteht.
Tool-Berechtigungen. Was ein Hook erreichen darf, wird gesteuert – Lesezugriff, MCP-Aufrufe und die Erstellung von Aufgaben werden getrennt reguliert.
Berechtigungen
Nur Inhaber und Admins können einen Hook erstellen, ändern, testen oder löschen; alle Mitglieder können Hooks und deren Ausführungsverlauf einsehen. Da ein Hook organisationsweite Reichweite hat, ist diese Asymmetrie beabsichtigt.
Sie überwachen
Die Seite jedes Hooks in der Factory listet seine Ausführungen und seine Aktivitäten der letzten 30 Tage auf: Ausführungen, Fehler und Kosten. Jede Automatisierungsausführung finden Sie auch unter Einstellungen → Aktivität, gefiltert nach Automatisierung. Prüfen Sie die Ausführungen nach der Aktivierung eines neuen Hooks – der Fehlerfall besteht nicht darin, dass etwas schiefgeht, sondern darin, dass der Hook ständig ausgelöst wird und nichts ergibt, worauf jemand reagieren könnte.
Hooks und Zeitpläne
| Mechanismus | Ausgelöst durch |
|---|---|
| Hook | Ein Plattform-Ereignis |
| Zeitplan | Zeit |
Beides sind Automatisierungen, die gemeinsam in der Factory aufgelistet werden. Siehe Automatisierungen.