Roadmap

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.

Pro #

• 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)
• É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.

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 intégré de gestion des inventaires #

Aujourd’hui, Semaphore traite l’inventaire comme un bloc opaque — les utilisateurs collent du contenu INI/YAML brut dans une seule zone de texte ou pointent vers un fichier dans un dépôt. Il n’existe aucun moyen structuré d’ajouter un hôte, d’organiser les hôtes en groupes ou de définir des variables d’hôte et de groupe depuis l’interface. Cette fonctionnalité introduit un système intégré de gestion des inventaires : un éditeur d’inventaire structuré et géré par l’interface (similaire aux inventaires d’AWX) où les hôtes, les groupes et les variables sont des objets de première classe stockés dans Semaphore et modifiables directement dans l’interface web, tout en restant entièrement exportables vers un inventaire Ansible standard.

Community #

• Éditeur structuré d’hôtes et de groupes — gérer les hôtes, leurs adresses/alias et les groupes d’hôtes via l’interface au lieu de modifier à la main une zone de texte d’inventaire brute, avec des actions d’ajout/suppression/renommage pour les hôtes et les groupes. (#836)
• Variables d’hôte et de groupe dans l’interface — définir host_vars et group_vars sous forme de paires clé/valeur structurées par hôte et par groupe, afin que les paramètres de connexion et les variables personnalisées n’aient plus à être intégrés à la main dans le corps de l’inventaire.
• Éditeur d’inventaire en ligne amélioré — remplacer la petite zone de texte d’inventaire par un éditeur plus grand et redimensionnable, doté de la coloration syntaxique YAML/INI et de la validation, rendant le mode d’édition en ligne existant réellement utilisable. (#698, #1650)
• Importer un inventaire existant — initialiser un inventaire géré en important un fichier d’inventaire INI/YAML existant ou en collant son contenu, et en l’analysant en hôtes, groupes et variables structurés.
• Définitions d’inventaire déclaratives — définir les inventaires (hôtes, groupes, variables) de manière déclarative via un document YAML géré par Semaphore, permettant une configuration d’inventaire reproductible et versionnée aux côtés des projets et des modèles. (#3109)
• Export vers un inventaire Ansible standard — restituer l’inventaire géré sous forme de fichier d’inventaire Ansible standard au moment de l’exécution de la tâche, afin que les playbooks et ansible-inventory voient exactement la même structure, quelle que soit la manière dont elle a été créée.

Pro #

• Groupes d’hôtes réutilisables — définir des groupes d’hôtes une seule fois et les partager entre plusieurs inventaires et projets, de sorte qu’une modification de l’appartenance à un groupe ou des variables de groupe se propage partout où le groupe est utilisé.
• Historique des modifications d’inventaire — conserver un historique des révisions par inventaire avec les différences des modifications d’hôtes, de groupes et de variables, et permettre de restaurer une version précédente.

Enterprise #

• Rôle de gestion d’hôtes à portée limitée — introduire un rôle de type opérateur capable d’ajouter, de modifier et de supprimer des hôtes dans des inventaires désignés (et d’exécuter des modèles prédéfinis) sans accorder l’administration complète du projet. (#2989)
• Approbation des modifications d’inventaire — exiger une révision/approbation avant que les modifications des inventaires protégés ne prennent effet, avec une piste d’audit indiquant qui a modifié quel hôte, groupe ou variable et quand.

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.

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.

Identifiants pour requirements.yml Lire #

Les playbooks Ansible déclarent fréquemment des rôles et collections privés dans requirements.yml qui résident dans des dépôts Git privés. Semaphore n’a actuellement aucun moyen de premier ordre pour authentifier ansible-galaxy install contre ces dépôts — les utilisateurs recourent à l’intégration de tokens dans les URL, à l’incorporation de clés SSH dans les images de runner, ou au maintien de scripts de préparation personnalisés. Cette fonctionnalité permet aux utilisateurs d’attacher un ou plusieurs identifiants du magasin de clés à un modèle de tâche (ou à une exécution de playbook) et de les utiliser automatiquement pendant la phase de préparation lorsque les rôles et collections sont résolus.

Community #

• Attacher des identifiants à une exécution de playbook — permettre de sélectionner une ou plusieurs entrées du magasin de clés (clé SSH, token Git, nom d’utilisateur/mot de passe) sur un modèle de tâche qui sont appliquées pendant ansible-galaxy install afin que les rôles et collections privés listés dans requirements.yml puissent être tirés depuis des dépôts Git privés. (#3677, #3708, #897)
• Mappage d’identifiants par motif d’hôte — lorsque plusieurs identifiants sont attachés, les mapper à des motifs de nom d’hôte (par exemple, github.com, gitlab.internal) afin que chaque source privée utilise la bonne clé ou le bon token sans collisions. (#3677)
• Corriger la propagation des variables d’environnement à l’étape galaxy install — s’assurer que les variables d’environnement (y compris les secrètes) sont exportées pendant ansible-galaxy install, et pas seulement pendant l’exécution du playbook, afin que l’authentification basée sur les tokens fonctionne pour requirements.yml. (#2966, #3178)
• Fichier requirements par playbook — permettre de remplacer le chemin par défaut roles/requirements.yml / collections/requirements.yml au niveau du modèle pour les projets qui regroupent plusieurs playbooks avec différents ensembles de dépendances. (#1366)
• Arguments CLI ansible-galaxy personnalisés — exposer un champ pour des arguments supplémentaires transmis à ansible-galaxy install (par exemple, --ignore-certs, --force, serveur personnalisé), couvrant les configurations en environnement isolé et de miroir Galaxy interne. (#2348)

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).

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)