Configura i trigger delle pipeline

Un trigger è ciò che avvia una pipeline. Ognuno è un nodo sul canvas, trascinato dalla sezione Trigger della libreria nodi. Selezionando quel nodo si apre il suo ispettore a destra: non esiste alcun elenco di trigger sempre presente, nessuna scheda dei trigger e nessuna schermata dei trigger.

Apri l’ispettore di un trigger

Vai in Impostazioni → Spazio di lavoro → Modelli di pipeline.
Premi la matita sulla riga del modello per aprire l’editor.
Seleziona un nodo trigger sul canvas. Il pannello di destra compare con le impostazioni di quel trigger. Con nulla selezionato, il pannello è nascosto.

Aggiungi un trigger

La sezione Trigger della libreria nodi elenca ogni tipo di avvio come nodo a sé: manuale, pianificazione, webhook e una scheda per ogni evento di dominio. Cerca merged, ticket o il nome del tipo (PrMerged) e trascina la scheda sul canvas. Un nuovo modello mostra anche un riquadro fantasma Aggiungi un trigger sull’ancora di ingresso: scegli dallo stesso elenco ricercabile.

Il trigger viene inserito immediatamente. I nuovi trigger automatici partono disabilitati, così un trascinamento non avvia un’esecuzione prima che tu lo abbia configurato. Usa l’interruttore Attivato dell’ispettore per attivarlo, oppure l’icona del cestino per eliminarlo.

Consenti le esecuzioni manuali

Trascina Esecuzione manuale (oppure scegliila dal riquadro fantasma) e attiva l’interruttore Attivato nel suo ispettore. È questo che fa comparire il modello nella pagina di esecuzione. Non è un caso speciale: l’interruttore scrive una normale riga di trigger il cui tipo di evento è manual. Viene salvata immediatamente; non c’è nulla da salvare.

Lo stesso interruttore è dietro Esecuzione manuale nell’intestazione dell’editor, dove si trova accanto agli input dichiarati del modello.

Su un evento

Questi eventi avviano un’esecuzione:

Etichetta nel selettore	Evento
PR esterna aperta	`ExternalPrDetected`
PR pubblicata	`PullRequestPublished`
Stato della PR cambiato	`PullRequestStatusChanged`
PR unita	`PrMerged`
Messaggio ricevuto	`MessageReceived`
Ticket creato	`TicketCreated`
Stato del ticket modificato	`TicketStatusChanged`
Ticket assegnato	`TicketAssigned`
Attività completata	`TicketCompleted`
Attività non riuscita	`TicketFailed`
Attività annullata	`TicketCancelled`
Soglia di budget superata	`BudgetThresholdCrossed`
Repository aggiunto	`RepoAdded`
Registrazione della riunione interrotta	`MeetingRecordingStopped`
Competenza aggiornata	`SkillUpdated`
Spazio eliminato	`SpaceDeleted`

SpaceDeleted è l’evento su cui è in ascolto la pipeline integrata di pulizia dei worktree: porta con sé l’id dello spazio eliminato, quindi l’esecuzione recupera esattamente i worktree di quello spazio invece di ripulire l’intero spazio di lavoro.

Per le chiavi del payload che ogni evento porta con sé, vedi il riferimento agli eventi di dominio.

Filtra un trigger di evento

Seleziona il nodo Stato della PR cambiato. Le chip di stato dell’ispettore sono l’unico filtro che l’interfaccia può impostare. Tocca una qualsiasi tra merged, closed, approved, opened, reopened; il trigger si attiva solo quando lo status dell’evento corrisponde a uno di essi. Lasciare tutte le chip deselezionate significa nessun filtro.

Non esiste alcun campo filtro JSON libero. Una chiave di filtro che il payload dell’evento non contiene non corrisponde mai, quindi non scriverne una a mano su una chiave che non hai confermato nel riferimento agli eventi di dominio.

Su una pianificazione

Seleziona il nodo Pianificazione per modificare quando si attiva. I campi dell’ispettore vengono salvati così come li lasci:

Campo	Descrizione
Pianificazione (cron o every:secondi)	Un’espressione cron a cinque campi come `0 9 * * 1`, oppure un intervallo come `every:86400`. Un numero puro viene convertito in `every:<n>`.
Fuso orario (opzionale)	Una zona IANA come `Europe/Paris`. Il valore predefinito è UTC.
Esecuzioni mancate	Cosa fare per le attivazioni perse mentre il server era inattivo: Esegui una volta accorpa ogni slot mancato in una sola attivazione al riavvio (l’impostazione predefinita), Salta riprende dal prossimo slot futuro.

La riga di riepilogo del riquadro sul canvas indica l’intervallo solo per la forma every:<seconds>; un’espressione cron viene mostrata semplicemente come “Pianificazione”.

Tramite un webhook

Trascinando Webhook viene generato un token casuale. Seleziona il nodo per copiare dall’ispettore il percorso POST /webhooks/<token>.

Il token è anche il segreto HMAC: la richiesta deve portare X-Hub-Signature-256: sha256=<hex>, dove l’hex è HMAC-SHA256(body, token). Una consegna che non supera la verifica viene rifiutata e registrata nei log e non è riproducibile. I duplicati vengono ignorati in base alla loro chiave di deduplicazione.

Ogni avvio è un proprio nodo del grafo. Tirare un filo da Pianificazione collega solo Pianificazione; Esecuzione manuale può seguire un percorso diverso (per esempio un nodo condizione) prima di unirsi allo stesso lavoro. Un’esecuzione entra nell’avvio che corrisponde al suo tipo di evento e salta i sottografi che appartengono agli altri avvii.

Come un trigger raggiunge un’esecuzione

Un trigger abilitato il cui tipo di evento e il cui filtro corrispondono entrambi avvia un’esecuzione con il payload dell’evento come payload del trigger dell’esecuzione: è rispetto a questo che si risolve {{key}} nel prompt o nello script di un passaggio. Gli eventi che portano una chiave naturale vengono deduplicati, quindi lo stesso evento che si attiva due volte non avvia due esecuzioni.

Un modello disabilitato viene rifiutato anche quando il suo trigger corrisponde. Otto dei tredici modelli integrati arrivano disabilitati, quindi i loro trigger inizializzati si attivano a vuoto finché non attivi il modello.

Schemi utili

Condiziona solo il percorso manuale — collega Esecuzione manuale attraverso un nodo condizione e Pianificazione direttamente al lavoro. Ogni avvio possiede i propri fili.
Revisiona ogni nuova PR — evento PR pubblicata sul modello pr_review.
Pulisci dopo un merge — evento Stato della PR cambiato, filtrato su merged / closed / approved. Il modello integrato pr_merged_cleanup è già in ascolto così, oltre a ticket completato/annullato, SpaceDeleted e una pianificazione giornaliera che viene forzata ad abilitata a ogni re-inizializzazione perché si tratta di garbage collection.
Scansione notturna — pianificazione 0 2 * * * con un fuso orario, su un modello il cui primo nodo è uno script bash.
Reagisci a un sistema esterno — un trigger webhook, con il sistema chiamante che firma il corpo della richiesta come sopra.