Automazioni

​

Concetti fondamentali

​

Tipi di azione

​

Fonti di attivazione

​

Creare un’automazione

​

Dalla pagina delle automazioni

1. Vai su automazione nella barra laterale
2. Fai clic su Crea automazione e scegli Create per aprire un editor vuoto (se non hai ancora alcuna automazione, fai invece clic su Create manually nella pagina iniziale). Lo stesso menu offre anche Template (apre la galleria dei template) e Generate with Devin (avvia una sessione che crea l’automazione insieme a te)
3. Configura il trigger, le condizioni e l’action
4. Fai clic su Crea automazione

​

Da un template

1. Vai a Automazioni nella barra laterale
2. Fai clic su Crea automazione > Template (se non hai ancora alcuna automazione, fai invece clic su Crea da template nella pagina iniziale), oppure vai direttamente a /automations/templates
3. Sfoglia la galleria dei template: ogni template è un’automazione preconfigurata per un flusso di lavoro comune
4. Fai clic su un template per precompilare l’editor con il trigger, l’action e i limiti consigliati
5. Personalizza la configurazione (ad es. seleziona il canale Slack o la repo) e fai clic su Crea automazione

​

Uso del linguaggio naturale

​

Configurazione dei trigger

​

Trigger Slack

• Messaggio Slack: Si attiva alla pubblicazione di nuovi messaggi. Per default viene aggiunta una condizione sul canale; puoi rimuoverla per intercettare i messaggi di più canali, ma in tal caso ogni gruppo di condizioni necessita di almeno un altro filtro (ad esempio il testo del messaggio o il tipo di mittente — Include thread replies da solo non è sufficiente).
• Gruppo di utenti menzionato: Si attiva quando viene menzionato un gruppo di utenti Slack (ad esempio @oncall). Seleziona il gruppo o inserisci il suo ID Slack (inizia con S) e, facoltativamente, limitalo a canali specifici.
• Reazione Slack: Si attiva quando a un messaggio viene aggiunta una specifica reazione emoji (ad es. 🚨 per gli incidenti). Puoi filtrare in base al nome della reazione e al canale.

​

Trigger di GitHub

• Issue: Si attiva sugli eventi della issue (apertura, chiusura, riapertura, modifica, aggiunta di label).
• Commento su issue: Si attiva quando viene pubblicato un commento su una issue di GitHub. In genere viene usato con una condizione starts_with "/devin", così gli utenti possono digitare /devin su qualsiasi issue per attivare Devin.
• Pull request: Si attiva sugli eventi della PR (apertura, sincronizzazione, ecc.).
• Review della pull request: Si attiva quando viene inviata una review su una PR.
• Commento di review della pull request: Si attiva sui singoli commenti di review.
• Check run (CI): Si attiva quando un controllo CI viene completato. Filtra per conclusion = failure per correggere automaticamente le build non riuscite.
• Push: Si attiva quando viene eseguito un push su un branch.

​

Trigger GitLab

• Merge request: si attiva sulle azioni relative alle MR (aperta, chiusa, merged, riaperta, approvata, aggiornata).
• Commento MR: si attiva quando viene pubblicato un commento (nota) su una merge request, inclusi i thread di review dei diff.
• Issue: si attiva sulle azioni relative alle issue (aperta, chiusa, riaperta, aggiornata).
• commento su issue: si attiva quando viene pubblicato un commento su una issue.
• Push: si attiva sui push verso un branch.
• Pipeline: si attiva quando una pipeline raggiunge un determinato status: filtra per status (ad es. failed) per correggere automaticamente le pipeline non riuscite.

​

Trigger di Linear

• Issue creata: Si attiva quando viene creata una nuova issue nel team selezionato.
• etichetta aggiunta: Si attiva quando una label viene applicata a un’issue (ad es. bug, devin).
• Stato modificato: Si attiva quando cambia lo stato di un’issue (ad es. viene spostata in “In Progress”).
• Priorità modificata: Si attiva quando cambia la priorità di un’issue.
• Assegnata: Si attiva quando un’issue viene assegnata a qualcuno.
• Issue spostata: Si attiva quando un’issue viene spostata in un altro team: il filtro per team del trigger corrisponde al team di destinazione.

​

Trigger Jira

• Issue creata: si attiva alla creazione di una nuova issue.
• issue aggiornata: si attiva quando cambiano i campi di una issue.
• etichetta aggiunta: si attiva quando una label viene applicata a una issue.
• stato modificato: si attiva quando cambia lo status di una issue.
• assegnata: si attiva quando una issue viene assegnata a qualcuno.
• Comment created or edited: si attiva quando un commento viene aggiunto o modificato su una issue.

​

Trigger di pianificazione

• Ricorrente: imposta la frequenza (oraria, giornaliera, settimanale) e l’ora. Dietro le quinte, le pianificazioni usano il formato RRULE di iCalendar. Scegli Pianificazione personalizzata per creare una ricorrenza personalizzata (ripeti ogni N minuti/ore/giorni/settimane/mesi) oppure inserisci direttamente una stringa RRULE grezza (ad es. FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0) per cadenze più complesse.
• Esegui una volta: si attiva una sola volta a una data e ora future specifiche, poi si disattiva automaticamente. Utile per attività differite una tantum, ad es. “sveglia Devin tra 12 ore per eseguire un’attività”. Scegli la data e l’ora (per impostazione predefinita è un’ora da adesso); devono essere nel futuro.

​

Trigger webhook

1. Crea un’automazione con un trigger Webhook
2. Copia l’URL del webhook e il segreto mostrati nella configurazione del trigger
3. Configura il tuo sistema esterno (PagerDuty, Datadog, Sentry o qualsiasi strumento personalizzato) in modo che invii richieste HTTP POST a questo URL
4. Facoltativamente aggiungi un filtro del payload — un pattern regex a cui il corpo della richiesta deve corrispondere affinché l’automazione si attivi

• header X-Webhook-Secret: <secret>
• header Authorization: Bearer <secret>
• parametro di query ?secret=<secret>

​

Segreto del webhook

curl -X POST '<webhook-url>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Secret: <secret>' \
  -d '{"test": true}'

​

Controlli Preflight

​

Filtro LLM

​

Configurare e testare uno script Preflight

1. Crea un’automazione o modificane una esistente, quindi configurane i trigger e le condizioni.
2. Fai clic su Add a step before the agent runs sotto la sezione dei trigger e seleziona Run a script nella scheda Before the agent runs.
3. Fai clic su Edit script, scegli Python, Node (JavaScript) o Bash nel selettore del runtime e modifica lo script iniziale.
4. Se necessario, usa Select secrets nell’editor degli script per associare i segreti dell’organizzazione. Vengono iniettati come variabili d’ambiente solo i segreti selezionati. Per salvare o testare uno script con segreti associati è necessaria l’autorizzazione a gestire i segreti dell’organizzazione.
5. Imposta Timeout (seconds) nella scheda: il valore predefinito è 60 secondi e l’intervallo consentito va da 1 a 300 secondi. Per impostazione predefinita, lo script usa il Minimal environment; se sono disponibili snapshot della macchina, il selettore Environment consente anche di scegliere uno snapshot dell’organizzazione che includa le tue dipendenze.
6. Nell’editor degli script, scegli un evento in Test against e fai clic su Run. Puoi testare lo script non salvato su un evento di esempio di un trigger configurato oppure su un evento recente di un’automazione esistente. Esamina il risultato, i log e, per gli elementi emessi, l’anteprima di quanti verrebbero eseguiti, risulterebbero duplicati o verrebbero rinviati.
7. Fai clic su Save script per applicare le modifiche apportate nell’editor, quindi su Crea automazione oppure salva l’automazione per rendere persistente la configurazione.

​

Input e output dello script

import json
import os

with open(os.environ["EVENT_FILE"]) as f:
    event = json.load(f)

text = event.get("payload", {}).get("text", "")
should_run = "urgent" in text.lower()

with open(os.environ["OUTPUT_FILE"], "w") as f:
    json.dump({"run": should_run, "reason": "Urgency filter"}, f)

​

Elementi dello script, stato e limiti

• Prevenzione dei duplicati: l’id di un elemento identifica un’unità di lavoro all’interno di questa automazione, non semplicemente un’entità. {"id": "INC-1"} viene gestito una sola volta; per elaborare una nuova occorrenza dello stesso incidente, aggiungi una version, ad esempio il timestamp dell’ultimo aggiornamento nel sistema di origine. Senza un id, Preflight identifica l’elemento tramite un hash del suo contenuto, quindi modificarne il contenuto può causare un’altra run.
• Limite di elementi per run: per impostazione predefinita, vengono inviati al massimo 10 nuovi elementi per run; il limite massimo consentito dal sistema è 50. Gli elementi che superano il limite non vengono gestiti né pianificati automaticamente: la run successiva dello script dovrà emetterli di nuovo. Non far avanzare un cursore oltre il lavoro rinviato solo perché è comparso nel tuo output.
• Esiti precedenti: usa LAST_RUN_FILE per distinguere il lavoro in esecuzione, completato, non riuscito o saltato. Un elemento la cui run non riesce viene rilasciato, in modo che una run successiva dello script possa emetterlo di nuovo.
• Stato persistente: le run live dello script di un’automazione vengono eseguite una alla volta. Gli script non riusciti non fanno avanzare lo stato salvato né contrassegnano gli elementi come gestiti. Clear state cancella sia lo stato JSON salvato sia la cronologia degli elementi già gestiti; dopo questa reimpostazione, gli elementi gestiti in precedenza possono essere eseguiti di nuovo.
• Limiti di dimensione: il sorgente e l’output dello script sono limitati a 256 KiB ciascuno, lo stato salvato a 64 KiB e i log acquisiti a 1 MiB.
• Errori: un codice di uscita diverso da zero, un timeout, un output o uno stato non validi o un errore dell’infrastruttura interrompono l’evento prima che vengano eseguite le relative azioni. Lo script non viene ritentato automaticamente per quell’evento; un trigger successivo può eseguirlo di nuovo.
• Accesso alla rete: la VM dello script rispetta le restrizioni di rete dell’automazione e il profilo di sicurezza applicabile. Ad esempio, per interrogare periodicamente un servizio di avvisi esterno, il relativo host deve essere consentito. Associare un segreto non concede l’accesso alla rete.

​

Configurare le actions

​

Avvia sessione

• Prompt: Le istruzioni che Devin segue. Scrivilo come faresti con un normale prompt per Devin.
• Playbook (facoltativo): Usa @playbook-name nel tuo prompt per includere un playbook con istruzioni aggiuntive.
• Tag (facoltativo): Aggiungi tag alle sessioni create da questa automazione per facilitare il filtraggio.

​

Invia un messaggio a una sessione

​

Triage con Devin (monitor)

​

Notifica email

• Sempre — a ogni esecuzione
• In caso di errore — solo quando la sessione non riesce o si verifica un errore
• In caso di successo — solo quando la sessione si completa correttamente

​

Limiti e protezioni

​

Limite di ACU

​

Limite di invocazione

​

Accodamento

• Concurrent runs: il numero massimo di run simultanei di questa automazione. Gli eventi in eccesso restano in coda. Un run smette di essere conteggiato ai fini del limite non appena la sua sessione termina e resta in attesa di nuove istruzioni.
• Queue depth: il numero massimo di eventi che possono restare in coda. Gli eventi che arrivano quando la coda è piena vengono scartati.

​

Policy di rete

​

Integrazioni MCP

​

Accesso agli strumenti di Slack

​

Attività e monitoraggio

• Invocazioni recenti con timestamp
• Se ogni invocazione è riuscita o è stata ignorata
• Collegamenti alle sessioni Devin create
• Messaggi di errore per le invocazioni non riuscite

​

Attivazione e disattivazione

​

Template