AIREITERFactory Automations può avviare una sessione Droid in base a una pianificazione, a un messaggio Slack di primo livello, a un evento GitHub o a una richiesta HTTP in ingresso. I trigger webhook sono ancora in Private Preview, mentre le pianificazioni usano orari UTC fissi e non seguono automaticamente il passaggio all’ora legale. È quindi pronto per un progetto pilota circoscritto, non per un’adozione in produzione senza vincoli.
Cosa esegue davvero Factory Automations
Ogni automazione combina un trigger, una serie di istruzioni, un’identità e una destinazione di esecuzione (documentazione di Factory).
| Trigger | Cosa avvia l’esecuzione | Dettaglio operativo principale |
|---|---|---|
| Pianificato | Frequenza in linguaggio naturale o cron a cinque campi | Viene eseguito su un computer o una destinazione di esecuzione selezionata; i computer gestiti supportano 10 automazioni e 5 pianificate per un minuto |
| Slack | Messaggio di primo livello in un canale che corrisponde ai criteri | Risponde nel thread d’origine |
| GitHub | Pull request, commenti, push, etichette, verifiche o pianificazione | Viene eseguito in GitHub Actions dopo il completamento della configurazione |
| Webhook | Richiesta HTTP POST da un altro servizio | Droid Computer o modello di esecuzione; Private Preview |
Un’automazione può essere privata oppure condivisa con un’organizzazione. La privacy della sessione stabilisce separatamente chi può aprire le sessioni create dalle sue esecuzioni.
Il trigger scelto cambia il modello operativo
Esecuzioni pianificate: il punto di partenza più sicuro
Le pianificazioni accettano formule in linguaggio naturale come “ogni lunedì alle 9 PST” oppure espressioni cron come 0 9 * * 1. Factory mostra in anteprima l’orario risultante, ma cron lavora in UTC. Un fuso orario indicato nel testo viene convertito in una pianificazione UTC fissa, che non si aggiorna da sola quando cambia l’ora legale (documentazione di Factory).
Tra i primi incarichi sensati rientrano un riepilogo quotidiano dello stato, un controllo delle dipendenze, la verifica della documentazione obsoleta o un revisore di PR che raccolga elementi utili senza eseguire il merge del codice.
Messaggi Slack: utili, ma solo per i segnali di primo livello
Un’automazione Slack parte quando in un canale accessibile compare un messaggio di primo livello corrispondente ai criteri. Le risposte nei thread non avviano autonomamente una nuova esecuzione. I filtri possono limitare i messaggi in base al pattern del canale, al tipo di mittente, alle parole chiave, alle parole chiave escluse o ai mittenti esclusi.
Le esecuzioni rispondono nel thread del messaggio che le ha attivate. Se più automazioni corrispondono ai criteri, solo la prima risponde nello stesso thread; le altre pubblicano messaggi separati con un collegamento all’originale. Factory documenta anche questi comportamenti e le regole di accesso ai canali privati (documentazione di Factory). È una soluzione adatta a un canale incidenti ben controllato, ma non ai flussi che devono reagire a ogni risposta successiva.
Eventi GitHub: potenti, ma solo dopo un passaggio di configurazione ben visibile
Le automazioni GitHub personalizzate possono reagire a pull request, push, commenti, modifiche alle etichette, verifiche completate o pianificazioni. Vengono eseguite in GitHub Actions e, durante la creazione, aprono una pull request di configurazione in ciascun repository selezionato.
La pull request di configurazione deve essere sottoposta a merge prima che il workflow diventi attivo. Le esecuzioni avviate prima che il workflow raggiunga il branch predefinito falliscono; fino a quel momento l’automazione non può pubblicare commenti, eseguire push o aprire pull request. GitHub è il trigger più solido quando il lavoro ricorrente è già legato a un evento del repository e la normale revisione tramite pull request deve restare il confine prima della pubblicazione.
Webhook: una funzione reale, ma ancora poco disponibile
Factory descrive le automazioni webhook come una funzione in Private Preview e invita le organizzazioni a contattare il supporto per abilitarle. Un webhook avvia un’esecuzione a partire da una richiesta HTTP POST esterna, ma non può funzionare sul computer locale dell’utente: serve un Droid Computer o un modello di esecuzione.
Factory fornisce un URL webhook, l’opzione per l’header X-Webhook-Secret e una variante dell’URL per i mittenti che non possono impostare header. La documentazione raccomanda l’header perché i secret inclusi negli URL possono finire nei log; il secret viene mostrato una sola volta e la rotazione invalida quello precedente (documentazione webhook di Factory).
La stessa documentazione indica un limite di 200 KiB per il corpo della richiesta, 60 richieste accettate al minuto, registri delle consegne conservati per 30 giorni, una finestra di deduplicazione di 10 minuti per corpi identici e un limite di 10 esecuzioni all’ora. Questi vincoli rendono i webhook abbastanza pratici per testare la risposta agli alert, ma lo stato di anteprima è un ostacolo alla produzione quando l’accesso deve essere prevedibile.
I controlli da valutare prima di automatizzare
Le automazioni pianificate, Slack e webhook possono essere eseguite a nome dell’utente oppure tramite un account di servizio condiviso. L’identità determina l’accesso ai connettori, la fatturazione e l’attribuzione su Slack; le regole relative alle destinazioni di esecuzione sono elencate nella documentazione di Factory.
Mantieni il prompt circoscritto, usa credenziali revocabili, scegli una destinazione di esecuzione dedicata e lascia i permessi di deploy e merge ai controlli già presenti nel repository. La pagina di Factory sullo Slack Marketplace dichiara esplicitamente che l’app può commettere errori e invita a verificare sempre codice e risposte.
Un utente ha segnalato alcune lacune nella supervisione, tra cui l’assenza di un’app desktop Linux e della sincronizzazione tra computer (post di @JoelDeTeves su X); è un aspetto importante per i team che si aspettano di poter controllare attività automatizzate di lunga durata anche lontano dalla propria postazione.
Factory Automations o una semplice GitHub Action?
| Esigenza | Factory Automations | GitHub Action semplice |
|---|---|---|
| Eseguire un prompt su un repository | Sessione Droid nativa e destinazione di esecuzione | Il team deve fornire runtime dell’agente e codice del workflow |
| Lavoro pianificato | Linguaggio naturale o cron, con il limite dell’UTC | Cron di GitHub e logica personalizzata |
| Trigger Slack | Messaggi di primo livello con filtri e risposte nei thread | App Slack o integrazione tramite webhook |
| Evento GitHub | PR di configurazione guidata ed esecuzione in GitHub Actions | File workflow diretto |
| Webhook | Integrato, ma in Private Preview | Endpoint, autenticazione, retry e worker da realizzare |
| Confine della revisione | Può preparare il lavoro per la revisione umana | Dipende dai permessi del workflow |
Scegli una GitHub Action quando il compito consiste in un’integrazione API deterministica, come un riepilogo quotidiano delle PR. Factory ha più senso quando il passaggio ricorrente richiede analisi, contesto del repository, una modifica di codice proposta o una sessione leggibile da una persona. Non conviene adottare una piattaforma per agenti solo per evitare di scrivere un breve script.
Un progetto pilota a basso rischio, con margini per aumentare l’autonomia
- Scegli un’attività ricorrente con input ben delimitati, ad esempio la revisione delle nuove pull request o il controllo dei file generati.
- Inizia con un’automazione pianificata invece che con un webhook: eviti così l’accesso in anteprima e puoi controllare facilmente la frequenza.
- Fai in modo che l’output sia un report o una pull request, non un deploy o un merge.
- Registra esecuzioni fallite, attività bloccate, file modificati e correzioni umane; le sole pull request accettate non bastano come prova.
- Estendi il perimetro una dimensione alla volta: un’altra categoria di attività, un altro repository o un altro trigger.
Le indicazioni di Factory sui workflow raccomandano di riprodurre il problema originale, testare la correzione in un ambiente pulito e verificare un caso analogo prima di conservare un’istruzione riutilizzabile. È uno standard sensato anche per un progetto pilota con Automations.
Domande frequenti
Factory Automations supporta i webhook?
Sì, ma i trigger webhook sono in Private Preview e potrebbero richiedere un’abilitazione a livello di organizzazione. Le esecuzioni richiedono un Droid Computer o un modello di esecuzione. I dettagli sono disponibili nella sezione sui webhook.
Le risposte nei thread Slack attivano un’automazione?
No. L’esecuzione parte solo con un messaggio di primo livello corrispondente ai criteri; vedi la sezione sui messaggi Slack.
La pianificazione segue l’ora legale?
No. Factory salva una pianificazione UTC fissa; quando cambiano le regole locali sull’ora legale è necessario ricontrollarla. Vedi la sezione sulle esecuzioni pianificate.
Le automazioni GitHub vengono eseguite prima del merge della pull request di configurazione?
No. La pull request di configurazione deve prima raggiungere il branch predefinito; le esecuzioni precedenti falliscono. Vedi la sezione sugli eventi GitHub.
Cosa succede quando una consegna webhook viene ripetuta?
Un corpo identico ricevuto entro 10 minuti viene registrato come Deduped e non avvia un’altra esecuzione. Factory registra anche le consegne filtrate, limitate dal rate, ignorate e fallite.
Il compromesso da tenere sempre presente
Avvia un progetto pilota con attività pianificate o attivate da GitHub quando l’output può restare all’interno di un normale ciclo di revisione tramite pull request. Slack è pratico se il team adotta convenzioni chiare sui messaggi di primo livello; i webhook sono abbastanza documentati da poter essere testati, ma lo stato di Private Preview significa che non dovrebbero ancora sostenere un sistema incidenti di produzione.