Roadmap

Intégration Cloud Secret Manager Lire #

Les organisations utilisant des plateformes cloud ont besoin d’un moyen de récupérer les secrets directement depuis le service de gestion de secrets de leur fournisseur cloud à l’exécution, évitant la duplication des identifiants et exploitant les politiques de rotation existantes. Cette fonctionnalité ajoute des intégrations natives avec AWS Secrets Manager et Azure Key Vault en tant que capacités exclusives Enterprise.

Enterprise #

• Intégration AWS Secrets Manager — récupérer les secrets à l’exécution depuis AWS Secrets Manager en utilisant des rôles IAM, des clés d’accès ou des rôles assumés. Prend en charge les secrets structurés en JSON avec extraction de champs et rotation automatique. (#2248)
• Intégration Azure Key Vault — récupérer les secrets à l’exécution depuis Azure Key Vault en utilisant l’identité managée ou l’authentification par principal de service. Prend en charge les secrets, clés et certificats avec rotation automatique. (#2248, #3170)
• Mise en cache des secrets — réduire les appels API aux fournisseurs cloud en mettant en cache les secrets résolus en mémoire.

Cache de dépôt persistant #

Actuellement, Semaphore clone (ou tire) le dépôt dans un répertoire séparé pour chaque modèle de tâche, ce qui peut être lent pour les grands dépôts et gaspille les E/S disque. Cette fonctionnalité ajoute un indicateur par dépôt qui bascule vers un clone partagé et persistant, mis à jour périodiquement en arrière-plan — similaire à la façon dont AWX gère les mises à jour de projets. Lorsqu’il est activé, tous les modèles qui font référence au dépôt partagent une seule copie de travail (le même modèle déjà utilisé pour les dépôts locaux dans Semaphore), et les exécutions de tâches individuelles ne déclenchent plus de clone ou de pull.

Community #

• Indicateur “Cache Repository” dans les paramètres du dépôt — ajouter un bouton bascule à chaque dépôt qui, lorsqu’il est activé, conserve un seul clone persistant au lieu de cloner par exécution de tâche. Le clone est partagé entre tous les modèles qui utilisent le dépôt, correspondant au comportement que les dépôts locaux ont déjà. (#1212)
• Synchronisation périodique en arrière-plan — lorsque l’indicateur de cache est activé, tirer les mises à jour à un intervalle configurable (par exemple, toutes les 5 minutes) dans un worker en arrière-plan plutôt qu’au démarrage de la tâche, afin que les tâches se lancent toujours instantanément sur un checkout récent.
• Action de synchronisation manuelle — fournir un bouton “Sync Now” dans l’interface du dépôt et un point de terminaison API correspondant pour déclencher un pull immédiat en dehors du calendrier périodique.
• Résilience aux force-push / réécriture d’historique — gérer les force-pushes en amont de manière élégante (par exemple, git fetch --all && git reset --hard origin/<branch>) au lieu d’échouer sur un pull normal. (#800)
• Récupération d’arbre de travail sale — détecter et nettoyer automatiquement un arbre de travail sale (par exemple, fichiers .retry restants) avant le pull, empêchant les erreurs de “modifications locales”. (#308)
• Nettoyage des clones obsolètes — récupérer les clones mis en cache pour les dépôts qui ont été supprimés ou dont l’URL a changé, libérant de l’espace disque. (#1497, #2679)
• Visibilité du statut de synchronisation — afficher l’horodatage de la dernière synchronisation et le statut (succès/échec) sur la page de détail du dépôt afin que les utilisateurs sachent à quel point la copie de travail est récente.
• Calendrier de synchronisation par dépôt — permettre de remplacer l’intervalle de synchronisation global sur des dépôts individuels (par exemple, les dépôts à forte activité toutes les minutes, les dépôts stables toutes les heures).

Mappage de groupes LDAP et OpenID #

Semaphore prend en charge LDAP et OpenID Connect (OIDC) pour l’authentification, mais l’intégration s’arrête à la connexion — il n’y a pas d’attribution automatique de rôle ou de projet basée sur l’appartenance aux groupes du fournisseur d’identité. Chaque utilisateur OIDC/LDAP doit être manuellement attribué à des projets et rôles après la première connexion. De plus, il existe plusieurs bugs dans la gestion des redirections OIDC, l’analyse des claims et la configuration LDAP qui rendent l’expérience d’authentification peu fiable.

Community #

• Restreindre la connexion OIDC par claim — n’autoriser que les utilisateurs ayant des valeurs de claim spécifiques (par exemple, appartenance à un groupe requis ou domaine email) à se connecter. (#2626, #2938)
• Connexion automatique SSO — contourner l’écran de connexion et rediriger directement vers le fournisseur OIDC/SSO, avec une URL de secours pour la récupération si le SSO est indisponible. (#2548, #2899)
• Prise en charge OIDC PKCE — ajouter Proof Key for Code Exchange au flux de code d’autorisation OIDC tel que recommandé par la RFC 9700. (#3072)
• Configuration OIDC par variables d’environnement — permettre la configuration des fournisseurs OIDC via des variables d’environnement au lieu du seul fichier de configuration, simplifiant la gestion des secrets dans les conteneurs. (#2528, #3120)
• Corriger la redirection OIDC avec web_host/web_root — résoudre les erreurs 404 après la connexion OIDC lorsque web_host est vide ou web_root est défini sur un sous-chemin. (#2681, #1524, #2532, #3121)
• Corriger la gestion des claims OIDC — résoudre les problèmes où username_claim est ignoré, le claim email n’est pas reconnu et client_secret_file produit des requêtes malformées. (#1731, #2818, #3122)
• Corriger les expressions de claim LDAP — résoudre les expressions de modèle cassées dans le mappage LDAP (par exemple, mail | {{ .username }}@domain.com se résolvant en <no value>). (#3127)
• Corriger l’attribution du nom d’utilisateur LDAP — s’assurer que les utilisateurs LDAP obtiennent leur véritable nom d’utilisateur LDAP au lieu d’une chaîne générée aléatoirement. (#3688)
• Repli sur l’authentification locale LDAP — permettre aux comptes administrateur locaux de toujours se connecter lorsque LDAP est activé, empêchant le verrouillage si le serveur LDAP est indisponible. (#1363)
• Journalisation de débogage LDAP — ajouter une sortie de journal utile pour les échecs d’authentification LDAP afin de rendre le dépannage possible. (#2932)
• Liaison utilisateur OIDC/LDAP vers compte local — permettre de convertir ou lier des comptes locaux existants à des fournisseurs d’identité externes sans créer de doublons. (#3339)
• Déconnexion du fournisseur OIDC — terminer la session IdP (par exemple, Keycloak) lors de la déconnexion de Semaphore, permettant un changement de compte correct. (#1496)

Pro #

• Synchroniser les identifiants LDAP avec les clés d’accès — mettre à jour automatiquement (optionnel) le mot de passe de la clé d’accès lorsque le mot de passe LDAP change à la connexion, maintenant les identifiants Ansible synchronisés. (#3696)

Enterprise #

• Mappage groupe-vers-rôle OIDC — attribuer automatiquement des rôles Semaphore et des appartenances à des projets en fonction des claims OIDC (par exemple, le claim groups), éliminant la configuration manuelle de l’utilisateur après la première connexion. (#1499, #2483)
• Mappage groupe-vers-rôle LDAP — mapper les groupes Active Directory / LDAP aux rôles Semaphore, y compris l’attribution du rôle administrateur via l’appartenance à un groupe. (#3226, #1316)
• RBAC complet avec intégration LDAP/OIDC — implémenter un contrôle d’accès granulaire basé sur les rôles (administrateur global, administrateur de projet, utilisateur de projet, lecture seule) avec attribution automatique des rôles depuis les groupes de fournisseurs d’identité externes. (#891)
• Architecture d’authentification modulaire — abstraire l’authentification dans une interface de fournisseur pour prendre en charge plusieurs backends d’authentification et simplifier l’ajout de nouveaux fournisseurs. (#465, #1820)
• Corriger la suppression d’utilisateur laissant des données orphelines — s’assurer que la suppression d’un utilisateur nettoie les mappages project__user pour éviter les plantages de la vue Team. (#3514)

Système de notification flexible #

Le système de notification actuel dans Semaphore UI est configuré exclusivement via config.json, prend en charge un ensemble limité de canaux (Email, Telegram, Slack, MS Teams) et fonctionne au niveau global avec une personnalisation minimale par projet. Cette fonctionnalité repense les notifications de fond en comble pour qu’elles soient gérées par l’interface utilisateur, extensibles et configurables au niveau du projet et du modèle.

Community #

• Architecture de canaux extensible — définir une interface commune pour les canaux de notification avec des implémentations par canal, facilitant l’ajout de nouveaux canaux sans modifier la logique principale. Envisager l’adoption d’une bibliothèque de notification universelle (par exemple, nikoksr/notify) ou d’une passerelle (par exemple, Apprise) pour couvrir de nombreux fournisseurs à la fois. (#2325, #1290)
• Configuration des notifications gérée par l’interface utilisateur — déplacer la configuration des notifications des fichiers de configuration vers l’interface Web avec une granularité par projet et par modèle, prenant en charge plusieurs instances du même type de canal. (#3387, #1821, #3588)
• Personnalisation des messages basée sur des modèles — prendre en charge les modèles de messages définis par l’utilisateur stockés sous forme de fichiers sur le disque plutôt que dans la base de données.
• Sélection de canaux par projet — permettre aux utilisateurs de configurer quels canaux de notification sont actifs par projet via les paramètres du projet. (#3588)
• Événements de webhook sortants — définir les types d’événements (START, SUCCESS, FAILURE) et permettre la création de modèles de webhook par projet avec URL, en-têtes et authentification HMAC configurables. (#1825, #2594, #3066)
• Nouveaux canaux de notification — ajouter la prise en charge de Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) et Pushover (#2594).
• Notifications “Fixed” — envoyer une notification lors de la première exécution réussie après un échec, similaire aux alertes de récupération de GitLab CI. (#3380)
• Désactiver toutes les notifications par modèle — ajouter une option “Disable All Notifications” à côté de la case à cocher existante “Disable Successful Notifications”. (#3724)
• Email en cas de succès — inclure l’email dans le chemin de notification de succès (actuellement seuls Telegram/Slack/MS Teams se déclenchent en cas de succès). (#3503)
• Corriger l’URL de la tâche dans les notifications — s’assurer que tous les canaux (email, Slack, MS Teams) reçoivent une URL de tâche complètement qualifiée avec schéma et hôte, et non un chemin relatif. (#2097, #2311, #3292)
• Corriger les problèmes de livraison d’email — résoudre la prise en charge du port SMTP 465 (TLS implicite), l’ordre auth-avant-TLS et le formatage de l’en-tête Date. (#2201, #2971, #3542, #3209)
• Prise en charge des fils/sujets Telegram — permettre l’envoi de notifications vers des fils de discussion de groupe Telegram spécifiques via message_thread_id, configurable par projet et par modèle. (#3493, #1456)
• Améliorations du modèle Slack — exposer les champs de niveau supérieur (title, text, color) pour la compatibilité avec Slack Workflow Builder. (#2607)
• Prise en charge du proxy pour les alertes — permettre la configuration d’un proxy HTTP pour les requêtes de notification sortantes sans nécessiter un proxy à l’échelle du système. (#1484)

Pro #

• Canaux de notification réservés au plan Pro — prendre en charge des canaux de notification spécifiques exclusivement dans le plan Pro.
• Alertes de tâches de longue durée — déclencher une notification lorsqu’une tâche dépasse un seuil de durée configurable. (#1393)

Enterprise #

• Journal d’audit pour les notifications — maintenir un journal consultable de toutes les notifications envoyées avec le statut de livraison, les horodatages et les détails du destinataire. Améliorer la journalisation des erreurs pour inclure le contexte du destinataire en cas d’échec. (#3410)
• Intégration avec les plateformes de gestion d’incidents — intégrations natives avec PagerDuty, Opsgenie et ServiceNow pour la création automatique d’incidents et le suivi du cycle de vie.
• Contrôle d’accès aux notifications basé sur les rôles — restreindre qui peut configurer les règles et canaux de notification en fonction des rôles et permissions organisationnels.

Inventaires multiples par modèle #

L’interface CLI d’Ansible prend nativement en charge le passage de plusieurs arguments -i pour composer des inventaires (par exemple, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Semaphore restreint actuellement chaque modèle de tâche à un seul inventaire, obligeant les utilisateurs à recourir à des solutions de contournement telles que des scripts d’inventaire, des fichiers fusionnés ou des variables d’environnement supplémentaires. Cette fonctionnalité lève cette restriction et comble l’ensemble plus large des lacunes de gestion des inventaires.

Community #

• Prise en charge multi-inventaires — permettre d’attacher plusieurs inventaires à un seul modèle de tâche, transmis comme arguments -i séquentiels à Ansible (par exemple, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Résout la limitation d’un inventaire par modèle. (#2093)
• Champ d’inventaire facultatif — rendre le champ d’inventaire facultatif sur les modèles pour les cas où ansible.cfg spécifie déjà la source d’inventaire. (#1574)
• Source d’inventaire URL/HTTP — prendre en charge la récupération d’inventaire depuis une URL distante ou un point de terminaison API, essentiel pour les environnements hébergés/SaaS sans accès au système de fichiers. (#1924)
• Sélection de l’inventaire à l’exécution — permettre aux utilisateurs de sélectionner un inventaire au moment du lancement de la tâche via une liste déroulante, remplaçant la solution de contournement actuelle en texte libre. (#1354)
• Corriger la persistance de l’inventaire des tâches planifiées — s’assurer que l’inventaire sélectionné dans la boîte de dialogue de planification est enregistré et utilisé au moment de l’exécution au lieu de revenir à la valeur par défaut du modèle. (#3566, #3293)
• Corriger la perte du lien dépôt-inventaire lors de l’export/restauration de projet — les associations inventaire-dépôt sont supprimées lors de l’exportation du projet et ne sont pas restaurées lors de l’importation. (#3369, #3177)
• Transmettre les variables d’environnement à l’inventaire dynamique — s’assurer que les variables d’environnement du conteneur/hôte sont disponibles pour les scripts et plugins d’inventaire dynamique (par exemple, scripts Python, microsoft.ad.ldap). (#2724, #2783)
• Corriger l’authentification de l’inventaire basé sur git — utiliser les identifiants du dépôt lors de la récupération des branches distantes pour l’inventaire, corrigeant les tentatives d’accès non authentifiées. (#3539)
• Surcharges d’identifiants par hôte — arrêter de remplacer ansible_user par hôte et les variables de connexion définies dans l’inventaire par des --extra-vars globaux. Permettre les modèles d’inventaire multi-utilisateurs. (#1464, #1621)
• Afficher le contenu de l’inventaire dans l’interface — afficher le contenu des inventaires basés sur fichier et dynamiques dans l’interface pour l’inspection et le débogage, avec un lien vers le fichier source dans le dépôt externe. (#3169, #1555, #3543)
• Exposer le nom de l’inventaire dans le contexte de la tâche — rendre le nom de l’inventaire disponible dans semaphore_vars ou en tant que variable d’environnement afin que les playbooks puissent référencer quel inventaire est actif. (#1580)

Pro #

• Affinité inventaire-runner — associer les hôtes d’inventaire à des tags de runner afin que les tâches ne soient distribuées qu’aux runners ayant un accès réseau aux hôtes cibles, évitant les échecs dans les environnements multi-réseaux. (#3322)
• Plusieurs clés SSH par inventaire — permettre d’attribuer plusieurs entrées du magasin de clés à un seul inventaire pour les parcs où chaque hôte utilise une clé SSH unique. (#3336)
• Intégration d’inventaire hyperviseur — intégration native avec les API d’hyperviseurs (VMware, Proxmox) pour générer et actualiser automatiquement les inventaires dynamiques. (#2709)
• API de gestion des groupes d’hôtes — fournir une API pour ajouter/supprimer des hôtes des groupes d’inventaire sans réécrire l’intégralité de la charge utile de l’inventaire. (#1560)

Enterprise #

• Restreindre les inventaires autorisés par modèle — lorsqu’un modèle a l’option “ask for inventory” activée, limiter les inventaires sélectionnables à une liste autorisée définie par l’administrateur, empêchant le ciblage accidentel de mauvais environnements. (#3587)
• Registre central d’hôtes — fournir une couche de gestion d’hôtes partagée afin que les modifications d’hôtes (par exemple, mises à jour de nom d’hôte ou d’IP) se propagent à tous les inventaires faisant référence à cet hôte sans modifications manuelles. (#564)
• Stockage et visualisation des facts hôte — stocker les facts Ansible par hôte et afficher l’état avant/après les exécutions de tâches avec des capacités de diff et d’historique. (#930)

Groupes de variables multiples par modèle #

Semaphore permet actuellement d’attacher un seul groupe de variables (environnement) à chaque modèle de tâche. Cela oblige les utilisateurs à dupliquer les variables entre les groupes lorsque plusieurs modèles partagent des paramètres communs, ou à créer des groupes de variables monolithiques contenant tout. Cette fonctionnalité permet de composer plusieurs groupes de variables par modèle et corrige les nombreux bugs de gestion des variables — sérialisation, priorité, propagation et cycle de vie des variables de sondage.

Community #

• Composition multi-environnements — permettre d’attacher plusieurs groupes de variables à un seul modèle de tâche afin que les ensembles de variables partagés (par exemple, valeurs par défaut communes, surcharges par région) puissent être composés et réutilisés entre les modèles. (#2612)
• Cloner les groupes de variables — ajouter une action de clonage afin que les environnements qui ne diffèrent que de quelques valeurs puissent être configurés sans recréer tous les champs de zéro. (#3295)
• Ensembles de variables de sondage réutilisables — découpler les variables de sondage des modèles de tâches en objets assignables autonomes, évitant la duplication par modèle. (#2212)
• Corriger la sérialisation JSON des extra-vars — sérialiser les extra-vars complexes en JSON correct au lieu de chaînes de map Go, corrigeant les échecs de jsondecode dans Terraform/OpenTofu. (#3748, #1644, #2619)
• Corriger la priorité des variables de sondage — résoudre la surcharge silencieuse lorsque le même nom de variable existe à la fois dans les extra-vars d’environnement et dans le sondage ; définir une priorité claire ou lever une erreur. (#3108)
• Corriger la gestion des variables de sondage vides/optionnelles — s’assurer que les variables de sondage optionnelles sont systématiquement omises ou transmises comme chaînes vides, et non mélangées aléatoirement. (#2182)
• Valeurs par défaut des sondages pour les tâches planifiées — permettre de spécifier des valeurs par défaut pour les variables de sondage lors de la planification des tâches, afin que les exécutions automatisées n’échouent pas sur les invites obligatoires. (#2244)
• Transmettre les variables de sondage comme variables d’environnement pour les tâches bash — exposer les variables de sondage comme variables d’environnement du système d’exploitation au lieu d’arguments CLI pour les tâches de type shell. (#2433)
• Transmettre les variables de sondage pendant l’initialisation Tofu/Terraform — transmettre les variables de sondage à la phase init, pas seulement plan/apply, pour prendre en charge les configurations backend pilotées par des variables. (#2554)
• Références Jinja2 dans les arguments CLI supplémentaires — permettre de référencer les variables de sondage et d’environnement dans le champ Extra CLI Arguments en utilisant la syntaxe de modèle (par exemple, -l {{ hosts }}). (#1053)
• Variables d’environnement dans la préparation de l’exécution — rendre les variables d’environnement disponibles pendant la phase de préparation (par exemple, galaxy install, authentification de rôle Git) et pas seulement pendant l’exécution de la tâche. (#3178)
• Charger les extra-vars depuis un fichier du dépôt — prendre en charge le chargement des extra-vars depuis un fichier JSON/YAML dans le dépôt au lieu de les intégrer dans l’interface, permettant les workflows GitOps. (#2343)
• Surcharger l’environnement à l’exécution via l’API — permettre de transmettre un groupe de variables différent lors du lancement d’une tâche via l’API. (#1367, #3291)

Pro #

• Types de variables de sondage complexes — prendre en charge les variables de sondage dynamiques de type liste d’objets (par exemple, configurations VLAN) transmises sous forme de tableaux JSON structurés. (#3557)
• Surcharges de variables par planification — attacher des valeurs de variables personnalisées aux tâches planifiées afin que le même modèle puisse s’exécuter selon différentes planifications avec différents paramètres. (#2378)
• Valeurs de variables dynamiques depuis le contexte utilisateur — remplir automatiquement les variables avec l’identité de l’utilisateur connecté (par exemple, {{ current_user }}). (#2524, #909)

Enterprise #

• Marquer les variables comme privées — ajouter un indicateur “private” sur les variables qui empêche les valeurs d’apparaître dans les journaux d’exécution, l’historique des tâches et les réponses de l’API. (#2887)
• Restreindre la visibilité des variables d’environnement — limiter le contenu des groupes de variables aux rôles d’administrateur uniquement, empêchant l’exposition des identifiants dans les modèles de projet partagés. (#1126)
• Instantanés de variables au niveau de la build — capturer les valeurs des variables au moment de l’exécution de la tâche afin que les réexécutions utilisent les valeurs d’origine, pas les valeurs actuelles. (#1097)

Secrets appartenant à l’utilisateur #

Le magasin de clés de Semaphore est actuellement partagé entre tous les membres du projet. Tout utilisateur ayant accès au projet peut utiliser (et dans certains cas consulter) tous les identifiants stockés. Cela crée des problèmes de sécurité dans les environnements multi-utilisateurs où les membres de l’équipe ne devraient avoir accès qu’à leurs propres identifiants. De plus, le magasin de clés présente de multiples bugs liés au chiffrement, aux mises à jour de secrets et à l’intégrité des références, et manque d’intégration avec les systèmes externes de gestion de secrets.

Community #

• Magasin de clés personnel — fournir un magasin de clés par utilisateur afin que les identifiants personnels (clés SSH, mots de passe sudo) soient isolés des autres membres du projet et non partagés via le magasin de clés au niveau du projet. (#1483, #1373)
• Corriger le comportement de mise à jour des secrets — résoudre le problème où la modification d’une variable d’environnement secrète semble réussir mais la valeur n’est pas réellement persistée. (#2546)
• Masquer les secrets de la liste des processus — arrêter de transmettre les extra-vars secrets via des arguments de ligne de commande visibles dans la liste des processus du système d’exploitation ; utiliser un mécanisme sécurisé (par exemple, fichiers temporaires, stdin). (#3219)
• Prise en charge des certificats SSH dans le magasin de clés — permettre de stocker les certificats SSH aux côtés des clés SSH pour les workflows d’authentification par certificat. (#3171)
• Afficher la clé publique SSH — afficher la partie clé publique des clés SSH stockées dans l’interface du magasin de clés pour plus de commodité. (#1643)
• Prise en charge des secrets Docker — prendre en charge le modèle de variable d’environnement _FILE (par exemple, POSTGRES_PASSWORD_FILE) afin que les secrets Docker/Kubernetes puissent être montés et lus au lieu d’être transmis via des variables d’environnement. (#1268)
• Corriger la gestion de la clé de chiffrement dans Docker — s’assurer que la variable d’environnement SEMAPHORE_ACCESS_KEY_ENCRYPTION est respectée et n’est pas écrasée par une clé aléatoire au redémarrage du conteneur. (#2228, #3068, #3204)
• Corriger le renommage du magasin de clés cassant les références — résoudre le problème où le renommage d’une entrée du magasin de clés casse tous les inventaires et modèles liés. (#3188)
• Corriger l’API de mot de passe Vault — permettre de définir et mettre à jour les mots de passe Ansible Vault via l’API REST sans erreurs de contrainte de clé dupliquée. (#3413, #2773)

Pro #

• Intégration de magasin de secrets externe — récupérer les secrets à l’exécution depuis HashiCorp Vault, Azure Key Vault, AWS KMS ou Bitwarden au lieu de les stocker dans la base de données de Semaphore. (#2248, #658)

Enterprise #

• Clés d’accès globales — partager les entrées du magasin de clés entre les projets sans duplication, avec une gestion centralisée et des liens inter-projets. (#110)
• Piste d’audit d’accès aux secrets — journaliser tous les accès et utilisations des entrées du magasin de clés et des variables secrètes à des fins de conformité et d’investigation.

Flux de Travail #

Semaphore traite actuellement chaque modèle de tâche comme une unité indépendante — il n’existe aucun moyen intégré d’enchaîner plusieurs modèles dans un pipeline d’exécution multi-étapes. Cette fonctionnalité introduit les Flux de Travail — des graphes acycliques dirigés (DAGs) de modèles de tâches qui s’exécutent avec des branchements conditionnels, le passage de variables entre les étapes et des portes d’approbation humaine optionnelles. La conception s’inspire des AWX Workflow Job Templates, des flux de travail Rundeck et des concepts de pipelines Jenkins/GitLab CI.

Community #

• Modèles de flux de travail — introduire une nouvelle entité de niveau supérieur qui définit un DAG de nœuds de modèles de tâches connectés par des arêtes dirigées avec des conditions (on_success, on_failure, always), permettant des pipelines d’automatisation multi-étapes au sein d’un projet. (#3182, #2334, #1383, #836)
• Moteur d’exécution des flux de travail — exécuter les nœuds du flux de travail dans l’ordre topologique, en respectant les conditions des arêtes et en exécutant les branches indépendantes en parallèle, avec convergence ALL pour les nœuds ayant plusieurs parents. (#2281, #3088)
• Tableau de bord d’exécution des flux de travail — fournir une vue unifiée de l’exécution du flux de travail montrant le graphe DAG avec l’état par nœud (en attente, en cours, réussi, échoué, ignoré), des logs de nœuds cliquables et les temps globaux.
• Passage de variables entre nœuds — permettre aux modèles de tâches d’émettre des variables de sortie (via un fichier connu ou Ansible set_stats) qui sont automatiquement injectées comme variables supplémentaires dans les nœuds en aval. (#3182)
• Planification des flux de travail et déclencheurs API — support de la planification cron, des exécutions déclenchées par API et des déclencheurs webhook pour les flux de travail, avec des variables de sondage optionnelles au niveau du flux de travail. (#3088)

Pro #

• Éditeur visuel de flux de travail — éditeur graphique par glisser-déposer pour concevoir des flux de travail dans l’interface, avec validation DAG en temps réel, positionnement des nœuds et sélecteurs de conditions sur les arêtes.
• Surcharges par nœud — surcharger l’inventaire, les identifiants, les groupes de variables ou les arguments CLI d’un modèle au niveau du nœud du flux de travail, permettant de réutiliser le même modèle dans différents environnements au sein d’un seul flux de travail.
• Portes d’approbation — mettre en pause l’exécution du flux de travail à des points désignés pour attendre l’approbation humaine, avec des délais configurables, notification aux approbateurs et actions d’approbation/rejet depuis l’interface ou l’API.

Enterprise #

• RBAC des flux de travail — permissions granulaires pour créer, modifier, exécuter et approuver des flux de travail, avec attribution des portes d’approbation basée sur les rôles et journalisation d’audit.
• Flux de travail inter-projets — référencer des modèles de tâches d’autres projets dans un flux de travail, permettant des pipelines d’automatisation à l’échelle de l’organisation couvrant des projets d’infrastructure, d’application et de surveillance.
• Versionnement des flux de travail et rollback — maintenir un historique des versions des définitions de flux de travail avec des diffs, restaurer les versions précédentes et enregistrer quelle version a été utilisée pour chaque exécution.