Un hook reacciona ante algo que ocurre en Coroid. Tú eliges un evento, escribes instrucciones en lenguaje sencillo y el hook se ejecuta cuando se produce el evento.
Encuéntralos en la fábrica, bajo la sección de Automatizaciones.
Cree uno en Nuevo trabajo: seleccione Automatización y luego la opción Cuando algo ocurra. Nuevo trabajo incluye los eventos de GitHub y los eventos de Coroid. Consulte Automatizaciones.
Eventos ante los que puedes reaccionar
Un hook solo se activa para un evento que envía algo. Coroid envía la mayoría de los eventos que se indican a continuación. Algunos los generan tus propios sistemas. Cualquier otro evento está reservado: el editor no lo muestra y se rechaza la creación de un hook para él. Si un hook se guardó para un evento reservado, el editor y la lista lo marcarán como si nunca se activara; no se elimina.
Eventos que envía Coroid
| Categoría | Eventos |
|---|---|
| Tarea | Creado, cambio de estado, completado, fallido |
| Agente | Iniciado, completado, error |
| Repositorio | Se ha enviado un commit, se ha creado una rama, se ha abierto, actualizado o fusionado un pull request, se ha abierto un issue, un comentario que menciona a Coroid |
| Sprint | Creado, inicio de la planificación, iniciado, tarea añadida, tarea eliminada, inicio de la revisión, completado, cancelado |
| Plan | Inicio de la fase, completado, fallido |
| Programación | Inicio de la ejecución, ejecución completada, ejecución fallida |
| Informe | Iniciado, completado, fallido |
| Calidad | Inicio de la comprobación, aprobada o fallida; resuelta de forma autónoma |
| Promoción | Solicitada, aprobada, rechazada |
| Lanzamiento | Creado, cambio de candidato, cambio de notas, notas aprobadas, cambio de alcance, lista de verificación completada, evaluación del control, anulación del control, aprobado, publicado, revertido |
| Despliegue | En cola, en ejecución, exitoso, fallido, cancelado, verificación manual, verificación manual de reversión, comprobación de estado superada, comprobación de estado fallida |
| Sincronización | Actualización de la fuente externa |
| Slack y Telegram | Un mensaje que coincida con el filtro de la automatización |
Eventos que generan tus propios sistemas
| Categoría | Eventos |
|---|---|
| Análisis | Dependencia encontrada, problema de seguridad detectado, análisis completado |
| Despliegue externo | Iniciado, completado, fallido |
Coroid no envía estos eventos. Una canalización CI, un escáner u otro sistema tuyo activa el hook mediante su id: llama a POST /api/v1/organizations/hooks/:id/dispatch
con la clave de un cuenta de servicio
que tiene el hooks:dispatch ámbito. El hook se ejecuta para el evento en el que se guardó. El editor muestra estos eventos bajo el título 'Generados por tus propios sistemas'.
Eventos reservados
Estos aún no se han enviado ni activado, por lo que el editor no los ofrece:
| Categoría | Eventos |
|---|---|
| Tarea | Cambio de fase |
| Agente | Iteración, herramienta invocada |
| Plan | Creado, fase completada, inicio de la revisión final, revisión final completada, antes del pull request del plan |
| Programación | Creado, activado, en pausa |
| Sprint | Planificación completada, tarea completada, cambio de alcance |
| Lanzamiento | En etapa, validado |
| Promoción | Antes del pull request de la promoción |
| Calidad | La comprobación no está disponible; se ha iniciado o intentado la reparación; se ha iniciado la revalidación; se ha alcanzado el consenso |
Cuándo comienza y termina el trabajo
Los planes, programaciones, informes, comprobaciones de calidad, promociones y lanzamientos envían un evento cuando comienzan y otro cuando terminan. Un hook puede reaccionar a cómo finalizó el trabajo y tu sistema puede medir cuánto tiempo tardó.
| Trabajo | Inicios | Finales |
|---|---|---|
| Plan | Inicio de la fase: el primero se envía cuando comienza la ejecución del plan | Completado, fallido |
| Programación | Inicio de la ejecución | Ejecución completada, ejecución fallida |
| Informe | Iniciado | Completado, fallido |
| Comprobación de calidad | Inicio de la comprobación | Aprobada, fallida, resuelta de forma autónoma |
| Promoción | Solicitada | Aprobada, rechazada |
| Lanzamiento | Creado | Publicado, revertido |
Cada uno de estos eventos registra la hora en la que ocurrió en occurredAt. Un evento que indique cómo finalizó el trabajo también registrará cuándo comenzó en
startedAt, y cuánto tiempo tardó en durationMs. Eso startedAt es el
occurredAt del evento de inicio, por lo que ambos siempre coinciden. El tiempo dedicado al trabajo
en pausa se cuenta dentro de la duración.
Cada evento se envía una sola vez, al guardar el cambio. Un cambio que se deshaga no genera ningún envío, y una reintentona no genera dos envíos. Un evento de fin solo se envía para trabajos que hayan comenzado: una ejecución de planificación en modo simulación no genera nada, y tampoco lo hace un informe cancelado antes de iniciarse.
Lo que contiene cada evento, además de las horas:
| Evento | Se envía cuando | Campos |
|---|---|---|
| Inicio de la fase de planificación | La ejecución del plan comienza (su primera fase), y después cada vez que inicia la primera tarea de otra fase | planId, plan (id, título), phase (id, secuencia, título), firstPhase, executionStartedAt |
| Planificación completada o fallida | La ejecución del plan finaliza. Un plan que falle mientras se está planificando no genera ningún evento. | planId, plan, status, executionStartedAt |
| Inicio de la ejecución de la programación | Comienza una ejecución de programación | scheduleId, runId, schedule (id, nombre), run (motivo del disparador, ejecución principal) |
| Ejecución de la programación completada o fallida | La ejecución finaliza | Los mismos campos, status, y tasksCreated o error |
| Inicio del informe | Un informe comienza a generarse. Al pausar y reanudar se mantiene el mismo inicio. | reportId, report (id, tipo, título) |
| Informe completado o fallido | El informe se guarda, o bien falla o se cancela | Los mismos campos, y tokensUsed, costUsd y hasActionableFindings, o error |
| Inicio de la verificación de calidad | Comienza una verificación de calidad | qualityRunId, check (sujeto, disparador, versión de política, commit) |
| Verificación de calidad aprobada o fallida | La verificación llega a su decisión | Los mismos campos, decision, redoCause, failedExpectationIds |
| Calidad sin resolver de forma autónoma | Coroid deja de intentar reparar lo que detectó una verificación. | qualityRunId, workItemType, workItemId, reason |
| Solicitud de promoción | Se crea una promoción | promotionId, laneId, promotion (título, estado, ramas, pull request) |
| Promoción aprobada | La promoción se fusiona: aprobada en Coroid, fusión forzada, fusionada en el proveedor o incluida en un lanzamiento. | Los mismos campos, approval, approvedBy, forceReason |
| Promoción rechazada | Un revisor solicita cambios | Los mismos campos, reason, requestedBy, comment |
| Lanzamiento publicado | La primera implementación en producción del lanzamiento tiene éxito | releaseId, version, commitSha |
| Lanzamiento revertido | Una reversión sustituye el lanzamiento en un entorno | releaseId, version, rolledBackToReleaseId |
Los eventos sobre el trabajo en un proyecto también incluyen projectId, por lo que un hook limitado a un
proyecto solo se activa para ese proyecto. Si un hook creó el trabajo, estos eventos
cuentan dentro de la profundidad de cadena de ese hook.
Disparadores y destinos
Toda automatización tiene una fuente de disparador, de donde provienen sus eventos, y un destino, que decide qué ocurre al activarse uno. Dos de los destinos transforman un evento en trabajo.
| Fuente de disparador | Eventos |
|---|---|
| Evento de flujo de trabajo | Eventos en Coroid, como se muestra en la tabla anterior |
| GitHub | Se abre, actualiza o fusiona una solicitud de extracción; se abre un issue; un comentario que mencione a Coroid |
| Slack | Un mensaje que coincida con el filtro de la automatización |
| Telegram | Un mensaje que coincida con el filtro de la automatización, como uno que empiece por /coroid |
| Jira | Un nuevo issue |
| Destino | Qué ocurre |
|---|---|
| Hook | Ejecuta tus instrucciones, en modo de solo lectura, tal como se describe en esta página. |
| Calificar trabajo | Registra el evento como una solicitud. Una vez que la Calificación sea positiva, Coroid crea el trabajo. |
| Coroid Check | Retirado. La Coroid Revisión de cada pull request se configura en Control de Calidad; las automatizaciones existentes se pusieron en pausa. |
Los eventos de GitHub requieren la aplicación de GitHub. Un comentario que mencione a Coroid solo cuenta cuando su autor tenga acceso de escritura al repositorio. Ver GitHub.
Una tarea de Calificar trabajo solo se inicia por sí sola si el autor del evento es trustworthy: el autor de un GitHub pull request, issue o comentario que tenga acceso de escritura al repositorio. Los autores de Slack, Telegram y Jira nunca son trustworthy, por lo que sus tareas esperan a que alguien las inicie. Ver Cuándo comienza el trabajo.
Los nuevos incidencias de Jira llegan a Coroid únicamente a través de su webhook de Jira. Solo acepta entregas firmadas con el secreto del webhook configurado para Coroid, solo para incidencias nuevas y solo cuando la clave del proyecto de Jira coincida con un proyecto de Coroid. En coroid.ai todavía no se ha configurado el webhook de Jira, por lo que el disparador de Jira no recibe eventos; en su lugar, importe las incidencias de Jira. Donde sí esté configurado el webhook, una nueva incidencia se envía a las automatizaciones del disparador de Jira, como la fuente de solicitud de Jira en Control de Calidad, que registra las incidencias de los tipos y prioridades que haya seleccionado para la cualificación. Si no hay automatización en el disparador, una nueva incidencia no genera ningún registro. El trabajo desde Jira nunca comienza por sí solo. Ver Seguimiento de incidencias.
De solo lectura por defecto
Los hooks analizan e informan. Pueden crear tareas de seguimiento; no modifican su código directamente.
Ese comportamiento por defecto es lo que los hace seguros de adoptar. Una automatización que edita código en respuesta a un evento actúa en el momento menos probable de ser supervisada. Un hook que abre una tarea produce el mismo resultado a través del proceso habitual: especificación, planificación, verificación, revisión y pull request.
- ProgramarHora
- Automatización de eventosAlgo ocurre.
Una tarea ordinaria
Especificación, plan, desarrollo, verificación, revisión. Utiliza un espacio de agente; asigna una prioridad más baja.
P2P3Una solicitud de incorporación de cambios de pull request
No puede fusionarse por sí mismo ni confirmar cambios en tu rama base.
Tú apruebas
Redactar buenas instrucciones
Las instrucciones de los hooks son procesadas por un modelo, por lo que se leen como instrucciones dirigidas a un compañero en lugar de código. El nivel de calidad es el mismo que para una especificación: indique qué observar, qué es importante y qué hacer.
Sea específico sobre el caso de "no hacer nada". Sin ello, un hook encontrará algo que decir cada vez que se ejecute, y los hooks que se activan siempre son aquellos que la gente deja de leer.
Protecciones
Existen tres protecciones porque la automatización basada en eventos falla de maneras predecibles:
Límites de frecuencia. Por minuto, hora y día, configurables por hook. Un hook vinculado a un evento de alta frecuencia podría activarse cientos de veces durante una fusión intensa.
Profundidad de cadena. Los hooks pueden disparar eventos que a su vez activan otros hooks. Una profundidad máxima de cadena evita que se convierta en un bucle.
Permisos de herramientas. Lo que un hook puede acceder está controlado: el acceso de solo lectura, las llamadas MCP y la creación de tareas se gestionan por separado.
Permisos
Solo los propietarios y administradores pueden crear, modificar, probar o eliminar un hook; todos los miembros pueden ver los hooks y su historial de ejecución. Dado que un hook opera con alcance a nivel de organización, esa asimetría es intencionada.
Supervisándolos
La página de cada hook en la plataforma muestra sus ejecuciones y lo que realizó en los últimos 30 días: ejecuciones, errores y coste. Cada ejecución de automatización también aparece en Configuración → Actividad, filtrada por Automatización. Compruebe sus ejecuciones después de habilitar un nuevo hook: el modo de fallo no es un error, sino que se activa constantemente sin producir resultados que requieran acción.
Hooks y programaciones
| Mecanismo | Disparado por |
|---|---|
| Hook | Un evento de la plataforma |
| Programación | Hora |
Ambos son automatizaciones, listadas juntas en la plataforma. Ver Automatizaciones.