Roadmap

Integrazione Cloud Secret Manager Leggi #

Le organizzazioni che utilizzano piattaforme cloud necessitano di un modo per recuperare i segreti direttamente dal servizio di gestione dei segreti del proprio cloud provider a runtime, evitando la duplicazione delle credenziali e sfruttando le politiche di rotazione esistenti. Questa funzionalita aggiunge integrazioni native con AWS Secrets Manager e Azure Key Vault come funzionalita esclusivamente Enterprise.

Enterprise #

• Integrazione AWS Secrets Manager – recupera i segreti a runtime da AWS Secrets Manager utilizzando ruoli IAM, chiavi di accesso o ruoli assunti. Supporta segreti strutturati in JSON con estrazione dei campi e rotazione automatica. (#2248)
• Integrazione Azure Key Vault – recupera i segreti a runtime da Azure Key Vault utilizzando identita gestita o autenticazione tramite service principal. Supporta segreti, chiavi e certificati con rotazione automatica. (#2248, #3170)
• Caching dei segreti – riduce le chiamate API ai cloud provider memorizzando in cache i segreti risolti in memoria.

Cache persistente del repository #

Attualmente, Semaphore clona (o esegue il pull) del repository in una directory separata per ogni modello di attivita, il che puo essere lento per repository di grandi dimensioni e spreca operazioni di I/O su disco. Questa funzionalita aggiunge un flag per repository che passa a un clone condiviso e persistente, aggiornato periodicamente in background – simile a come AWX gestisce gli aggiornamenti dei progetti. Quando abilitato, tutti i modelli che fanno riferimento al repository condividono una singola copia di lavoro (lo stesso modello gia utilizzato per i repository locali in Semaphore), e le singole esecuzioni delle attivita non attivano piu un clone o un pull.

Community #

• Flag “Cache Repository” nelle impostazioni del repository – aggiunge un toggle a ciascun repository che, quando abilitato, mantiene un singolo clone persistente invece di clonare per ogni esecuzione di attivita. Il clone e condiviso tra tutti i modelli che utilizzano il repository, replicando il comportamento gia presente per i repository locali. (#1212)
• Sincronizzazione periodica in background – quando il flag della cache e abilitato, esegue il pull degli aggiornamenti a un intervallo configurabile (ad esempio, ogni 5 minuti) in un worker in background anziche all’avvio dell’attivita, cosi che le attivita vengano sempre avviate istantaneamente su un checkout recente.
• Azione di sincronizzazione manuale – fornisce un pulsante “Sincronizza ora” nell’interfaccia del repository e un endpoint API corrispondente per attivare un pull immediato al di fuori della pianificazione periodica.
• Resilienza a force-push / riscrittura della cronologia – gestisce i force-push upstream in modo corretto (ad esempio, git fetch --all && git reset --hard origin/<branch>) invece di fallire con un pull normale. (#800)
• Recupero dell’albero di lavoro sporco – rileva e pulisce automaticamente un albero di lavoro sporco (ad esempio, file .retry residui) prima del pull, prevenendo errori di “modifiche locali”. (#308)
• Pulizia dei cloni obsoleti – raccolta dei cloni nella cache per repository che sono stati eliminati o il cui URL e cambiato, recuperando spazio su disco. (#1497, #2679)
• Visibilita dello stato di sincronizzazione – mostra il timestamp e lo stato dell’ultima sincronizzazione (successo/fallimento) nella pagina dei dettagli del repository, cosi che gli utenti sappiano quanto e aggiornata la copia di lavoro.
• Pianificazione di sincronizzazione per repository – consente di sovrascrivere l’intervallo di sincronizzazione globale sui singoli repository (ad esempio, repository ad alto tasso di modifiche ogni minuto, repository stabili ogni ora).

Mappatura dei gruppi LDAP e OpenID #

Semaphore supporta LDAP e OpenID Connect (OIDC) per l’autenticazione, ma l’integrazione si ferma al login – non esiste un’assegnazione automatica di ruoli o progetti basata sull’appartenenza ai gruppi del provider di identita. Ogni utente OIDC/LDAP deve essere assegnato manualmente a progetti e ruoli dopo il primo accesso. Inoltre, ci sono numerosi bug nella gestione del redirect OIDC, nel parsing dei claim e nella configurazione LDAP che rendono l’esperienza di autenticazione inaffidabile.

Community #

• Limitazione del login OIDC per claim – consente l’accesso solo agli utenti con valori di claim specifici (ad esempio, appartenenza a un gruppo richiesto o dominio email). (#2626, #2938)
• Auto-login SSO – salta la schermata di login e reindirizza direttamente al provider OIDC/SSO, con un URL di sicurezza per il recupero se SSO non e disponibile. (#2548, #2899)
• Supporto OIDC PKCE – aggiunge il Proof Key for Code Exchange al flusso del codice di autorizzazione OIDC come raccomandato dalla RFC 9700. (#3072)
• Configurazione OIDC tramite variabili di ambiente – consente di configurare i provider OIDC tramite variabili di ambiente invece che solo tramite file di configurazione, semplificando la gestione dei segreti nei container. (#2528, #3120)
• Correzione del redirect OIDC con web_host/web_root – risolve gli errori 404 dopo il login OIDC quando web_host e vuoto o web_root e impostato su un sottopercorso. (#2681, #1524, #2532, #3121)
• Correzione della gestione dei claim OIDC – risolve i problemi con username_claim ignorato, il claim email non riconosciuto e client_secret_file che produce richieste malformate. (#1731, #2818, #3122)
• Correzione delle espressioni dei claim LDAP – risolve le espressioni template non funzionanti nella mappatura LDAP (ad esempio, mail | {{ .username }}@domain.com che si risolve in <no value>). (#3127)
• Correzione dell’assegnazione del nome utente LDAP – assicura che gli utenti LDAP ottengano il loro effettivo nome utente LDAP invece di una stringa generata casualmente. (#3688)
• Fallback autenticazione locale LDAP – consente agli account amministratore locali di effettuare comunque il login quando LDAP e abilitato, prevenendo il blocco se il server LDAP non e raggiungibile. (#1363)
• Logging di debug LDAP – aggiunge output di log utili per i fallimenti di autenticazione LDAP per rendere possibile la risoluzione dei problemi. (#2932)
• Collegamento utente OIDC/LDAP ad account locale – consente di convertire o collegare account locali esistenti a provider di identita esterni senza creare duplicati. (#3339)
• Logout dal provider OIDC – termina la sessione IdP (ad esempio, Keycloak) quando si esce da Semaphore, consentendo il corretto cambio di account. (#1496)

Pro #

• Sincronizzazione delle credenziali LDAP con le chiavi di accesso – aggiorna opzionalmente in automatico la password della chiave di accesso quando la password LDAP cambia al login, mantenendo le credenziali Ansible sincronizzate. (#3696)

Enterprise #

• Mappatura gruppo-ruolo OIDC – assegna automaticamente ruoli Semaphore e appartenenze ai progetti in base ai claim OIDC (ad esempio, claim groups), eliminando la configurazione manuale dell’utente dopo il primo accesso. (#1499, #2483)
• Mappatura gruppo-ruolo LDAP – mappa i gruppi Active Directory / LDAP sui ruoli Semaphore, inclusa l’assegnazione del ruolo di amministratore tramite appartenenza al gruppo. (#3226, #1316)
• RBAC completo con integrazione LDAP/OIDC – implementa un controllo degli accessi granulare basato sui ruoli (amministratore globale, amministratore del progetto, utente del progetto, sola lettura) con assegnazione automatica dei ruoli dai gruppi del provider di identita esterno. (#891)
• Architettura di autenticazione pluggable – astrae l’autenticazione in un’interfaccia provider per supportare piu backend di autenticazione e semplificare l’aggiunta di nuovi provider. (#465, #1820)
• Correzione dell’eliminazione utente che lascia dati orfani – assicura che l’eliminazione di un utente pulisca le mappature project__user per prevenire crash nella vista Team. (#3514)

Sistema di notifica flessibile #

L’attuale sistema di notifica nell’interfaccia utente di Semaphore e configurato esclusivamente tramite config.json, supporta un set limitato di canali (Email, Telegram, Slack, MS Teams) e opera a livello globale con una personalizzazione minima per progetto. Questa funzionalita riprogetta le notifiche da zero per renderle gestite dall’interfaccia utente, estensibili e configurabili a livello di granularita di progetto e modello.

Community #

• Architettura di canale estensibile – definisce un’interfaccia comune per i canali di notifica con implementazioni per canale, semplificando l’aggiunta di nuovi canali senza modificare la logica di base. Si consideri l’adozione di una libreria di notifica universale (ad esempio, nikoksr/notify) o di un gateway (ad esempio, Apprise) per coprire molti provider contemporaneamente. (#2325, #1290)
• Configurazione delle notifiche gestita dall’interfaccia utente – sposta la configurazione delle notifiche dai file di configurazione nell’interfaccia Web con granularita per progetto e per modello, supportando piu istanze dello stesso tipo di canale. (#3387, #1821, #3588)
• Personalizzazione dei messaggi basata su modelli – supporta modelli di messaggio definiti dall’utente archiviati come file su disco anziche nel database.
• Selezione del canale per progetto – consente agli utenti di configurare quali canali di notifica sono attivi per progetto tramite le impostazioni del progetto. (#3588)
• Eventi webhook in uscita – definisce i tipi di evento (START, SUCCESS, FAILURE) e consente la creazione di modelli webhook per progetto con URL, intestazioni e autenticazione HMAC configurabili. (#1825, #2594, #3066)
• Nuovi canali di notifica – aggiunge il supporto per Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) e Pushover (#2594).
• Notifiche “Fixed” – invia una notifica alla prima esecuzione riuscita dopo un fallimento, simile agli avvisi di recovery di GitLab CI. (#3380)
• Disabilita tutte le notifiche per modello – aggiunge un’opzione “Disabilita tutte le notifiche” accanto alla casella di controllo esistente “Disabilita notifiche di successo”. (#3724)
• Email in caso di successo – include l’email nel percorso di notifica di successo (attualmente solo Telegram/Slack/MS Teams si attivano in caso di successo). (#3503)
• Correzione dell’URL dell’attivita nelle notifiche – assicura che tutti i canali (email, Slack, MS Teams) ricevano un URL dell’attivita completo con schema e host, non un percorso relativo. (#2097, #2311, #3292)
• Correzione dei problemi di consegna email – risolve il supporto della porta SMTP 465 (TLS implicito), l’ordine autenticazione-prima-di-TLS e la formattazione dell’intestazione Date. (#2201, #2971, #3542, #3209)
• Supporto thread/topic di Telegram – consente di inviare notifiche a thread specifici di gruppi Telegram tramite message_thread_id, configurabile per progetto e per modello. (#3493, #1456)
• Miglioramenti al modello Slack – espone i campi di livello superiore (title, text, color) per la compatibilita con Slack Workflow Builder. (#2607)
• Supporto proxy per gli avvisi – consente di configurare un proxy HTTP per le richieste di notifica in uscita senza richiedere un proxy a livello di sistema. (#1484)

Pro #

• Canali di notifica esclusivi Pro – supporta canali di notifica specifici esclusivamente nel piano Pro.
• Avvisi per attivita di lunga durata – attiva una notifica quando un’attivita supera una soglia di durata configurabile. (#1393)

Enterprise #

• Registro di audit per le notifiche – mantiene un registro ricercabile di tutte le notifiche inviate con stato di consegna, timestamp e dettagli del destinatario. Migliora la registrazione degli errori per includere il contesto del destinatario in caso di fallimento. (#3410)
• Integrazione con piattaforme di gestione degli incidenti – integrazioni native con PagerDuty, Opsgenie e ServiceNow per la creazione automatica degli incidenti e il tracciamento del ciclo di vita.
• Controllo degli accessi alle notifiche basato sui ruoli – limita chi puo configurare regole e canali di notifica in base ai ruoli e alle autorizzazioni dell’organizzazione.

Inventari multipli per modello #

La CLI di Ansible supporta nativamente il passaggio di piu argomenti -i per comporre inventari (ad esempio, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Semaphore attualmente limita ogni modello di attivita a un singolo inventario, costringendo gli utenti a soluzioni alternative come script di inventario, file uniti o variabili di ambiente aggiuntive. Questa funzionalita rimuove tale restrizione e affronta l’insieme piu ampio di lacune nella gestione dell’inventario.

Community #

• Supporto multi-inventario – consente di allegare piu inventari a un singolo modello di attivita, passati come argomenti -i sequenziali ad Ansible (ad esempio, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Risolve la limitazione di un inventario per modello. (#2093)
• Campo inventario opzionale – rende il campo inventario nei modelli opzionale per i casi in cui ansible.cfg specifica gia l’origine dell’inventario. (#1574)
• Origine inventario URL/HTTP – supporta il recupero dell’inventario da un URL remoto o un endpoint API, essenziale per ambienti ospitati/SaaS senza accesso al filesystem. (#1924)
• Selezione dell’inventario a runtime – consente agli utenti di selezionare un inventario al momento dell’avvio dell’attivita tramite un menu a discesa, sostituendo l’attuale soluzione alternativa con testo libero. (#1354)
• Correzione della persistenza dell’inventario nelle attivita pianificate – assicura che l’inventario selezionato nella finestra di pianificazione venga salvato e utilizzato al momento dell’esecuzione, invece di tornare al modello predefinito. (#3566, #3293)
• Correzione dell’esportazione/ripristino del progetto che perde il collegamento al repository dell’inventario – le associazioni inventario-repository vengono perse durante l’esportazione del progetto e non ripristinate all’importazione. (#3369, #3177)
• Passaggio delle variabili di ambiente all’inventario dinamico – assicura che le variabili di ambiente container/host siano disponibili per script e plugin di inventario dinamico (ad esempio, script Python, microsoft.ad.ldap). (#2724, #2783)
• Correzione dell’autenticazione dell’inventario basato su git – utilizza le credenziali del repository durante il recupero dei branch remoti per l’inventario, correggendo i tentativi di accesso non autenticati. (#3539)
• Override delle credenziali per host – impedisce l’override di ansible_user per host e delle variabili di connessione definite nell’inventario con --extra-vars globali. Consente pattern di inventario multi-utente. (#1464, #1621)
• Visualizzazione del contenuto dell’inventario nell’interfaccia – visualizza i contenuti dell’inventario basato su file e dinamico nell’interfaccia per ispezione e debug, con un collegamento al file sorgente nel repository esterno. (#3169, #1555, #3543)
• Esposizione del nome dell’inventario nel contesto dell’attivita – rende il nome dell’inventario disponibile in semaphore_vars o come variabile di ambiente cosi che i playbook possano fare riferimento all’inventario attivo. (#1580)

Pro #

• Affinita inventario-runner – associa gli host dell’inventario ai tag dei runner cosi che le attivita vengano inviate solo ai runner con accesso di rete agli host di destinazione, evitando fallimenti in ambienti multi-rete. (#3322)
• Chiavi SSH multiple per inventario – consente di assegnare piu voci del key store a un singolo inventario per flotte in cui ogni host utilizza una chiave SSH univoca. (#3336)
• Integrazione inventario con hypervisor – integrazione nativa con le API degli hypervisor (VMware, Proxmox) per generare e aggiornare automaticamente gli inventari dinamici. (#2709)
• API di gestione dei gruppi host – fornisce un’API per aggiungere/rimuovere host dai gruppi di inventario senza riscrivere l’intero payload dell’inventario. (#1560)

Enterprise #

• Limitazione degli inventari consentiti per modello – quando un modello ha abilitato “chiedi l’inventario”, limita gli inventari selezionabili a una lista consentita definita dall’amministratore, prevenendo il targeting accidentale di ambienti errati. (#3587)
• Registro host centrale – fornisce un livello di gestione host condiviso cosi che le modifiche agli host (ad esempio, aggiornamenti di hostname o IP) si propaghino a tutti gli inventari che fanno riferimento a quell’host senza modifiche manuali. (#564)
• Archiviazione e visualizzazione dei fatti sugli host – archivia i fatti Ansible per host e visualizza lo stato prima/dopo le esecuzioni delle attivita con funzionalita di diff e cronologia. (#930)

Gruppi di variabili multipli per modello #

Semaphore attualmente consente di allegare un singolo gruppo di variabili (ambiente) a ciascun modello di attivita. Questo costringe gli utenti a duplicare le variabili tra i gruppi quando piu modelli condividono impostazioni comuni, o a creare gruppi di variabili monolitici che contengono tutto. Questa funzionalita consente di comporre piu gruppi di variabili per modello e corregge i numerosi bug nella gestione delle variabili – serializzazione, precedenza, propagazione e ciclo di vita delle variabili survey.

Community #

• Composizione multi-ambiente – consente di allegare piu gruppi di variabili a un singolo modello di attivita cosi che i set di variabili condivisi (ad esempio, valori predefiniti comuni, override per regione) possano essere composti e riutilizzati tra i modelli. (#2612)
• Clonazione dei gruppi di variabili – aggiunge un’azione di clonazione cosi che ambienti che differiscono solo per pochi valori possano essere configurati senza ricreare tutti i campi da zero. (#3295)
• Set di variabili survey riutilizzabili – separa le variabili survey dai modelli di attivita in oggetti assegnabili autonomi, evitando la duplicazione per modello. (#2212)
• Correzione della serializzazione JSON di extra-vars – serializza gli extra-vars complessi come JSON corretto invece che come stringhe di mappa Go, correggendo i fallimenti di jsondecode in Terraform/OpenTofu. (#3748, #1644, #2619)
• Correzione della precedenza delle variabili survey – risolve l’override silenzioso quando lo stesso nome di variabile esiste sia negli extra-vars dell’ambiente che nel survey; definisce una precedenza chiara o genera un errore. (#3108)
• Correzione della gestione delle variabili survey vuote/opzionali – assicura che le variabili survey opzionali vengano costantemente omesse o passate come stringhe vuote, non mescolate casualmente. (#2182)
• Valori predefiniti survey per le attivita pianificate – consente di specificare valori predefiniti per le variabili survey durante la pianificazione delle attivita, cosi che le esecuzioni automatizzate non falliscano sui prompt obbligatori. (#2244)
• Passaggio delle variabili survey come variabili di ambiente per attivita bash – espone le variabili survey come variabili di ambiente del sistema operativo invece che come argomenti CLI per le attivita di tipo shell. (#2433)
• Passaggio delle variabili survey durante l’init di Tofu/Terraform – inoltra le variabili survey alla fase init, non solo a plan/apply, per supportare configurazioni backend basate su variabili. (#2554)
• Riferimenti Jinja2 negli Extra CLI Arguments – consente di fare riferimento a variabili survey e di ambiente nel campo Extra CLI Arguments utilizzando la sintassi template (ad esempio, -l {{ hosts }}). (#1053)
• Variabili di ambiente nella preparazione dell’esecuzione – rende le variabili di ambiente disponibili durante la fase di preparazione (ad esempio, galaxy install, autenticazione ruoli Git) non solo durante l’esecuzione dell’attivita. (#3178)
• Caricamento extra-vars da file del repository – supporta il caricamento di extra-vars da un file JSON/YAML nel repository invece che inline nell’interfaccia, abilitando i flussi di lavoro GitOps. (#2343)
• Override dell’ambiente a runtime tramite API – consente di passare un gruppo di variabili diverso quando si avvia un’attivita tramite API. (#1367, #3291)

Pro #

• Tipi di variabili survey complesse – supporta variabili survey dinamiche di tipo lista-di-oggetti (ad esempio, configurazioni VLAN) passate come array JSON strutturati. (#3557)
• Override delle variabili per pianificazione – allega valori di variabili personalizzati ai job pianificati cosi che lo stesso modello possa essere eseguito con pianificazioni diverse e parametri diversi. (#2378)
• Valori dinamici delle variabili dal contesto utente – popola automaticamente le variabili con l’identita dell’utente connesso (ad esempio, {{ current_user }}). (#2524, #909)

Enterprise #

• Contrassegnare le variabili come private – aggiunge un flag “private” sulle variabili che impedisce la visualizzazione dei valori nei log di esecuzione, nella cronologia delle attivita e nelle risposte API. (#2887)
• Limitazione della visibilita delle variabili di ambiente – limita i contenuti dei gruppi di variabili ai soli ruoli di amministratore, prevenendo l’esposizione delle credenziali nei modelli di progetto condivisi. (#1126)
• Snapshot delle variabili a livello di build – salva un’istantanea dei valori delle variabili al momento dell’esecuzione dell’attivita cosi che le riesecuzioni utilizzino i valori originali, non quelli correnti. (#1097)

Segreti di proprieta dell’utente #

Il key store di Semaphore e attualmente condiviso tra tutti i membri del progetto. Qualsiasi utente con accesso al progetto puo utilizzare (e in alcuni casi visualizzare) tutte le credenziali archiviate. Questo crea problemi di sicurezza in ambienti multi-utente dove i membri del team dovrebbero avere accesso solo alle proprie credenziali. Inoltre, il key store presenta numerosi bug relativi alla crittografia, agli aggiornamenti dei segreti e all’integrita dei riferimenti, e manca di integrazione con sistemi esterni di gestione dei segreti.

Community #

• Key store personale – fornisce un key store per utente cosi che le credenziali personali (chiavi SSH, password sudo) siano isolate dagli altri membri del progetto e non condivise tramite il key store a livello di progetto. (#1483, #1373)
• Correzione del comportamento di aggiornamento dei segreti – risolve il problema per cui la modifica di una variabile di ambiente segreta sembra avere successo ma il valore non viene effettivamente salvato. (#2546)
• Nascondere i segreti dalla lista dei processi – impedisce il passaggio di extra-vars segreti tramite argomenti della riga di comando visibili nella lista dei processi del sistema operativo; utilizza un meccanismo sicuro (ad esempio, file temporanei, stdin). (#3219)
• Supporto certificati SSH nel key store – consente di archiviare certificati SSH insieme alle chiavi SSH per flussi di lavoro di autenticazione basata su certificati. (#3171)
• Visualizzazione della chiave pubblica SSH – mostra la parte della chiave pubblica delle chiavi SSH archiviate nell’interfaccia del key store per comodita. (#1643)
• Supporto per i segreti Docker – supporta il pattern env var _FILE (ad esempio, POSTGRES_PASSWORD_FILE) cosi che i segreti Docker/Kubernetes possano essere montati e letti invece di essere passati tramite variabili di ambiente. (#1268)
• Correzione della gestione della chiave di crittografia in Docker – assicura che la env var SEMAPHORE_ACCESS_KEY_ENCRYPTION sia rispettata e non venga sovrascritta con una chiave casuale al riavvio del container. (#2228, #3068, #3204)
• Correzione della rinomina del key store che rompe i riferimenti – risolve il problema per cui la rinomina di una voce del key store interrompe tutti gli inventari e i modelli collegati. (#3188)
• Correzione dell’API per le password Vault – consente di impostare e aggiornare le password Ansible Vault tramite API REST senza errori di vincolo di chiave duplicata. (#3413, #2773)

Pro #

• Integrazione con secret store esterni – recupera i segreti a runtime da HashiCorp Vault, Azure Key Vault, AWS KMS o Bitwarden invece di archiviarli nel database di Semaphore. (#2248, #658)

Enterprise #

• Chiavi di accesso globali – condivide le voci del key store tra progetti senza duplicazione, con gestione centralizzata e collegamento tra progetti. (#110)
• Audit trail per l’accesso ai segreti – registra tutti gli accessi e l’utilizzo delle voci del key store e delle variabili segrete per conformita e analisi forense.

Flussi di lavoro #

Semaphore attualmente tratta ogni modello di attivita come un’unita indipendente – non esiste un modo integrato per concatenare piu modelli in una pipeline di esecuzione multi-step. Questa funzionalita introduce i Flussi di lavoro – grafi aciclici diretti (DAG) di modelli di attivita che vengono eseguiti con ramificazione condizionale, passaggio di variabili tra i passaggi e porte di approvazione umana opzionali. Il design si ispira agli AWX Workflow Job Templates, ai flussi di lavoro di Rundeck e ai concetti di pipeline di Jenkins/GitLab CI.

Community #

• Modelli di flusso di lavoro – introduce una nuova entita di livello superiore che definisce un DAG di nodi di modelli di attivita collegati da archi diretti con condizioni (on_success, on_failure, always), consentendo pipeline di automazione multi-step all’interno di un progetto. (#3182, #2334, #1383, #836)
• Motore di esecuzione dei flussi di lavoro – esegue i nodi del flusso di lavoro in ordine topologico, rispettando le condizioni degli archi ed eseguendo rami indipendenti in parallelo, con convergenza ALL per i nodi con piu genitori. (#2281, #3088)
• Dashboard di esecuzione dei flussi di lavoro – fornisce una vista unificata dell’esecuzione del flusso di lavoro mostrando il grafo DAG con stato per nodo (in attesa, in esecuzione, riuscito, fallito, saltato), log dei nodi cliccabili e tempi complessivi.
• Passaggio di variabili tra nodi – consente ai modelli di attivita di emettere variabili di output (tramite un file noto o Ansible set_stats) che vengono automaticamente iniettate come variabili extra nei nodi a valle. (#3182)
• Pianificazione dei flussi di lavoro e trigger API – supporto per pianificazione cron, esecuzioni attivate via API e trigger webhook per i flussi di lavoro, con variabili survey opzionali a livello di flusso di lavoro. (#3088)

Pro #

• Editor visuale dei flussi di lavoro – editor grafico drag-and-drop per progettare flussi di lavoro nell’interfaccia, con validazione DAG in tempo reale, posizionamento dei nodi e selettori di condizioni sugli archi.
• Override per nodo – sovrascrive inventario, credenziali, gruppi di variabili o argomenti CLI di un modello a livello di nodo del flusso di lavoro, consentendo di riutilizzare lo stesso modello in ambienti diversi all’interno di un singolo flusso di lavoro.
• Porte di approvazione – mette in pausa l’esecuzione del flusso di lavoro in punti designati per attendere l’approvazione umana, con timeout configurabili, notifica agli approvatori e azioni di approvazione/rifiuto dall’interfaccia o API.

Enterprise #

• RBAC dei flussi di lavoro – permessi granulari per creare, modificare, eseguire e approvare flussi di lavoro, con assegnazione delle porte di approvazione basata sui ruoli e registrazione di audit.
• Flussi di lavoro tra progetti – referenzia modelli di attivita da altri progetti in un flusso di lavoro, consentendo pipeline di automazione a livello organizzativo che coprono progetti di infrastruttura, applicazione e monitoraggio.
• Versionamento dei flussi di lavoro e rollback – mantiene una cronologia delle versioni delle definizioni dei flussi di lavoro con diff, ripristina le versioni precedenti e registra quale versione e stata utilizzata per ogni esecuzione.