AIREITERFactory Automations puede iniciar una sesión de Droid mediante una programación, un mensaje principal de Slack, un evento de GitHub o una solicitud HTTP entrante. Los activadores por webhook siguen en Private Preview, mientras que las programaciones usan horarios fijos en UTC y no se ajustan automáticamente a los cambios de hora. Está listo para un piloto acotado, no para desplegarlo en producción sin restricciones.
Qué ejecuta realmente Factory Automations
Cada automatización combina un activador, unas instrucciones, una identidad y un destino de ejecución (documentación de Factory).
| Activador | Qué inicia la ejecución | Detalle principal de la ejecución |
|---|---|---|
| Programado | Una frecuencia en lenguaje natural o un cron de cinco campos | Se ejecuta en un ordenador o destino de ejecución seleccionado; los ordenadores gestionados admiten 10 automatizaciones y 5 programadas para ejecutarse cada minuto |
| Slack | Un mensaje principal de canal que coincide con los filtros | Responde en el hilo de origen |
| GitHub | Pull requests, comentarios, pushes, etiquetas, comprobaciones o una programación | Se ejecuta en GitHub Actions una vez completada la configuración |
| Webhook | Una solicitud HTTP POST de otro servicio | Droid Computer o plantilla de ejecución; Private Preview |
Una automatización puede ser privada o compartirse con una organización. La privacidad de las sesiones es un ajuste independiente que determina quién puede abrir las sesiones creadas por sus ejecuciones.
El activador también determina cómo se opera
Ejecuciones programadas: el punto de partida más seguro
Las programaciones aceptan expresiones como “every Monday at 9am PST” o un cron como 0 9 * * 1. Factory muestra una vista previa de la hora resultante, pero cron funciona en UTC. Cuando se indica una zona horaria, se convierte en una programación UTC fija que no se adapta por sí sola al horario de verano (documentación de Factory).
Para empezar, encajan bien un resumen diario de estado, una auditoría de dependencias, una comprobación de documentación desactualizada o un revisor de pull requests que recopile evidencias en lugar de fusionar código.
Mensajes de Slack: útiles, pero solo para señales principales
Una automatización de Slack se inicia cuando aparece un mensaje principal que coincide con los filtros en un canal accesible. Las respuestas dentro de un hilo no activan una ejecución por sí solas. Los filtros pueden limitar los mensajes por patrón de canal, tipo de remitente, palabras clave, palabras excluidas o remitentes excluidos.
Las ejecuciones responden en el hilo del mensaje que las activó. Si coinciden varias automatizaciones, solo la primera responde allí; las demás publican mensajes independientes con un enlace al original. Factory documenta estos comportamientos, incluidas las reglas de acceso a canales privados (documentación de Factory). Funciona bien para un canal de incidentes controlado, pero no para flujos que dependan de cada respuesta posterior.
Eventos de GitHub: potentes, pero con un paso de configuración visible
Las automatizaciones personalizadas de GitHub pueden reaccionar a pull requests, pushes, comentarios, cambios de etiquetas, comprobaciones completadas o una programación. Se ejecutan en GitHub Actions y, al crearlas, abren un pull request de configuración en cada repositorio seleccionado.
Ese pull request de configuración debe fusionarse antes de que el flujo quede activo. Las ejecuciones iniciadas antes de que el flujo llegue a la rama predeterminada fallan, y la automatización no puede publicar comentarios, hacer pushes ni abrir pull requests hasta entonces. GitHub es el activador más sólido cuando el trabajo recurrente ya está ligado a un evento del repositorio y la revisión normal de pull requests sigue siendo el límite antes de publicar cambios.
Webhooks: capacidad real, disponibilidad limitada
Factory documenta las automatizaciones por webhook como Private Preview y pide a las organizaciones que contacten con soporte para habilitarlas. Un webhook inicia una ejecución a partir de un HTTP POST externo, pero no puede ejecutarse en el ordenador local de un usuario: necesita un Droid Computer o una plantilla de ejecución.
Factory proporciona una URL de webhook, la opción de usar la cabecera X-Webhook-Secret y un formato de URL para los emisores que no pueden establecer cabeceras. La documentación recomienda la cabecera porque los secretos incluidos en la URL pueden terminar en los registros; el secreto se muestra una sola vez y la rotación invalida el valor anterior (documentación de webhooks de Factory).
La misma documentación establece un límite de 200 KiB por cuerpo, 60 solicitudes aceptadas por minuto, registros de entregas durante 30 días, una ventana de deduplicación de 10 minutos para cuerpos idénticos y un máximo de 10 ejecuciones por hora. Estos controles hacen que los webhooks se puedan probar para responder a alertas, pero su estado de vista previa es un bloqueo para producción cuando el acceso debe ser predecible.
Los controles que determinan si es seguro automatizar
Las automatizaciones programadas, de Slack y de webhook pueden ejecutarse como el usuario o como una cuenta de servicio compartida. La identidad afecta al acceso a conectores, la facturación y la atribución en Slack; las reglas sobre los destinos de ejecución aparecen en la documentación de Factory.
Limita el alcance del prompt, usa credenciales revocables, selecciona un destino de ejecución dedicado y mantén el despliegue y la capacidad de fusionar cambios bajo los controles existentes del repositorio. La ficha de Factory en Slack Marketplace advierte explícitamente de que la aplicación puede cometer errores y recomienda revisar el código y las respuestas.
Un usuario señaló algunas carencias de supervisión, como la ausencia de una aplicación de escritorio para Linux y de sincronización entre ordenadores (publicación de @JoelDeTeves en X); es un aspecto relevante cuando el equipo espera supervisar trabajo automatizado de larga duración lejos del escritorio.
Factory Automations frente a un GitHub Action sencillo
| Necesidad | Factory Automations | GitHub Action sencillo |
|---|---|---|
| Ejecutar un prompt contra un repositorio | Sesión nativa de Droid y destino de ejecución | El equipo aporta el runtime del agente y el código del workflow |
| Trabajo programado | Lenguaje natural o cron, con la salvedad de UTC | Cron de GitHub y lógica personalizada |
| Activador de Slack | Mensajes principales con filtros y respuestas en hilos | Configuración de una aplicación de Slack o de un webhook |
| Evento de GitHub | Pull request de configuración guiado y ejecución en GitHub Actions | Archivo de workflow directo |
| Webhook | Incluido, pero en Private Preview | Hay que crear el endpoint, la autenticación, los reintentos y el worker |
| Límite de revisión | Puede preparar trabajo para que lo revise una persona | Depende de los permisos del workflow |
Usa un GitHub Action cuando la tarea sea una integración determinista con APIs, como un resumen diario de pull requests. Elige Factory cuando el paso recurrente requiera investigación, contexto del repositorio, una propuesta de cambio de código o una sesión legible para una persona. No elijas una plataforma de agentes solo para evitar escribir un script corto.
Un piloto de bajo riesgo que puede ganar autoridad
- Elige una tarea recurrente con una entrada bien delimitada, como revisar pull requests nuevos o comprobar archivos generados.
- Empieza con una automatización programada en lugar de un webhook; así evitas depender del acceso a la vista previa y puedes inspeccionar fácilmente la cadencia.
- Haz que el resultado sea un informe o un pull request, no un despliegue ni una fusión.
- Registra las ejecuciones fallidas, el trabajo bloqueado, los archivos modificados y las correcciones humanas; los pull requests aceptados por sí solos no bastan como evidencia.
- Amplía el alcance de una sola dimensión cada vez: otra clase de tarea, otro repositorio u otro activador.
La guía de workflows de Factory recomienda reproducir el fallo original, probar la corrección en un entorno limpio y comprobar un caso cercano antes de conservar una instrucción reutilizable. Es un criterio sensato para un piloto de Automation.
Preguntas frecuentes
¿Factory Automations admite webhooks?
Sí, pero los activadores por webhook están en Private Preview y pueden requerir habilitación a nivel de organización. Las ejecuciones necesitan un Droid Computer o una plantilla de ejecución. Los detalles aparecen en la sección de webhooks anterior.
¿Las respuestas en hilos de Slack activan una automatización?
No. La ejecución solo empieza con un mensaje principal que coincida con los filtros; consulta Mensajes de Slack.
¿La programación se adapta al horario de verano?
No. Factory guarda una programación UTC fija; revísala cuando cambien las reglas locales del horario de verano. Consulta Ejecuciones programadas.
¿Las automatizaciones de GitHub se ejecutan antes de fusionar el pull request de configuración?
No. El pull request de configuración debe llegar primero a la rama predeterminada; las ejecuciones anteriores fallan. Consulta Eventos de GitHub.
¿Qué ocurre cuando se repite la entrega de un webhook?
Un cuerpo idéntico recibido durante los 10 minutos siguientes se registra como Deduped y no inicia otra ejecución. Factory también registra las entregas filtradas, limitadas por tasa, omitidas y fallidas.
El intercambio que conviene tener presente
Pon a prueba trabajos activados por una programación o por GitHub cuando el resultado pueda mantenerse dentro de un ciclo de revisión mediante pull request. Slack resulta práctico si se establecen convenciones para los mensajes principales; los webhooks ofrecen suficiente detalle para probarlos, pero su estado de Private Preview indica que todavía no deberían sostener un sistema de incidentes en producción.