Roadmap

Workflows #

Semaphore behandelt derzeit jede Aufgabenvorlage als unabhängige Einheit — es gibt keine integrierte Möglichkeit, mehrere Vorlagen zu einer mehrstufigen Ausführungspipeline zu verketten. Diese Funktion führt Workflows ein — gerichtete azyklische Graphen (DAGs) von Aufgabenvorlagen, die mit bedingter Verzweigung, Variablenübergabe zwischen Schritten und optionalen manuellen Genehmigungstoren ausgeführt werden. Das Design orientiert sich an AWX Workflow Job Templates, Rundeck Job-Workflows und Jenkins/GitLab CI Pipeline-Konzepten.

Pro #

• Workflow-Vorlagen — Einführung einer neuen Top-Level-Entität, die einen DAG von Aufgabenvorlagen-Knoten definiert, verbunden durch gerichtete Kanten mit Bedingungen (on_success, on_failure, always), um mehrstufige Automatisierungspipelines innerhalb eines Projekts zu ermöglichen. (#3182, #2334, #1383, #836)
• Workflow-Ausführungsengine — Workflow-Knoten in topologischer Reihenfolge ausführen, Kantenbedingungen beachten und unabhängige Zweige parallel ausführen, mit ALL-Konvergenz für Knoten mit mehreren Elternknoten. (#2281, #3088)
• Workflow-Ausführungs-Dashboard — eine einheitliche Ansicht der Workflow-Ausführung bereitstellen, die den DAG-Graph mit pro-Knoten-Status (ausstehend, laufend, erfolgreich, fehlgeschlagen, übersprungen), anklickbaren Knoten-Logs und Gesamtzeit zeigt.
• Variablenübergabe zwischen Knoten — ermöglichen, dass Aufgabenvorlagen Ausgabevariablen erzeugen (über eine bekannte Datei oder Ansible set_stats), die automatisch als Extra-Variablen in nachfolgende Knoten injiziert werden. (#3182)
• Workflow-Zeitplanung und API-Trigger — Unterstützung für Cron-Zeitplanung, API-ausgelöste Ausführungen und Webhook-Trigger für Workflows, mit optionalen Survey-Variablen auf Workflow-Ebene. (#3088)
• Visueller Workflow-Editor — Drag-and-Drop-Grafik-Editor zum Entwerfen von Workflows in der Benutzeroberfläche, mit Echtzeit-DAG-Validierung, Knotenpositionierung und Bedingungsauswahl an Kanten.
• Überschreibungen pro Knoten — Inventar, Anmeldeinformationen, Variablengruppen oder CLI-Argumente einer Vorlage auf Workflow-Knoten-Ebene überschreiben, um dieselbe Vorlage in verschiedenen Umgebungen innerhalb eines einzelnen Workflows wiederzuverwenden.
• Genehmigungstore — Workflow-Ausführung an bestimmten Punkten anhalten, um auf menschliche Genehmigung zu warten, mit konfigurierbaren Zeitlimits, Benachrichtigung an Genehmiger und Genehmigungs-/Ablehnungsaktionen aus der Benutzeroberfläche oder API.

Enterprise #

• Workflow-RBAC — feingranulare Berechtigungen zum Erstellen, Bearbeiten, Ausführen und Genehmigen von Workflows, mit rollenbasierter Zuweisung von Genehmigungstoren und Audit-Protokollierung.
• Projektübergreifende Workflows — Aufgabenvorlagen aus anderen Projekten in einem Workflow referenzieren, um organisationsweite Automatisierungspipelines zu ermöglichen, die Infrastruktur-, Anwendungs- und Überwachungsprojekte umfassen.
• Workflow-Versionierung und Rollback — eine Versionshistorie der Workflow-Definitionen mit Diffs pflegen, vorherige Versionen wiederherstellen und aufzeichnen, welche Version für jeden Lauf verwendet wurde.

LDAP- und OpenID-Gruppenzuordnung #

Semaphore unterstützt LDAP und OpenID Connect (OIDC) für die Authentifizierung, aber die Integration endet bei der Anmeldung — es gibt keine automatische Rollen- oder Projektzuweisung basierend auf Gruppenmitgliedschaften des Identitätsanbieters. Jeder OIDC-/LDAP-Benutzer muss nach der ersten Anmeldung manuell Projekten und Rollen zugewiesen werden. Darüber hinaus gibt es mehrere Fehler bei der OIDC-Redirect-Behandlung, dem Claim-Parsing und der LDAP-Konfiguration, die die Authentifizierungserfahrung unzuverlässig machen.

Community #

• OIDC-Anmeldung nach Claim einschränken — erlauben Sie nur Benutzern mit bestimmten Claim-Werten (z. B. erforderliche Gruppenmitgliedschaft oder E-Mail-Domain) die Anmeldung. (#2626, #2938)
• SSO-Auto-Login — umgehen Sie den Anmeldebildschirm und leiten Sie direkt zum OIDC-/SSO-Anbieter weiter, mit einer Failsafe-URL zur Wiederherstellung, falls SSO nicht verfügbar ist. (#2548, #2899)
• OIDC PKCE-Unterstützung — fügen Sie Proof Key for Code Exchange zum OIDC-Authorization-Code-Flow hinzu, wie von RFC 9700 empfohlen. (#3072)
• OIDC-Konfiguration über Umgebungsvariablen — ermöglichen Sie die Konfiguration von OIDC-Anbietern über Umgebungsvariablen anstatt nur über die Konfigurationsdatei, um die Geheimnisverwaltung in Containern zu vereinfachen. (#2528, #3120)
• OIDC-Redirect mit web_host/web_root beheben — beheben Sie 404-Fehler nach der OIDC-Anmeldung, wenn web_host leer ist oder web_root auf einen Unterpfad gesetzt ist. (#2681, #1524, #2532, #3121)
• OIDC-Claim-Behandlung beheben — beheben Sie Probleme, bei denen username_claim ignoriert wird, der email-Claim nicht erkannt wird und client_secret_file fehlerhafte Anfragen erzeugt. (#1731, #2818, #3122)
• LDAP-Claim-Ausdrücke beheben — beheben Sie fehlerhafte Vorlagenausdrücke in der LDAP-Zuordnung (z. B. mail | {{ .username }}@domain.com wird zu <no value> aufgelöst). (#3127)
• LDAP-Benutzernamenzuweisung beheben — stellen Sie sicher, dass LDAP-Benutzer ihren tatsächlichen LDAP-Benutzernamen erhalten, anstatt eines zufällig generierten Strings. (#3688)
• LDAP-Fallback auf lokale Authentifizierung — ermöglichen Sie lokalen Admin-Konten weiterhin die Anmeldung, wenn LDAP aktiviert ist, um eine Sperrung zu verhindern, falls der LDAP-Server nicht erreichbar ist. (#1363)
• LDAP-Debug-Protokollierung — fügen Sie nützliche Protokollausgaben für LDAP-Authentifizierungsfehler hinzu, um die Fehlerbehebung zu ermöglichen. (#2932)
• OIDC-/LDAP-Benutzer-zu-Lokalkonto-Verknüpfung — ermöglichen Sie das Konvertieren oder Verknüpfen bestehender lokaler Konten mit externen Identitätsanbietern, ohne Duplikate zu erstellen. (#3339)
• OIDC-Anbieter-Abmeldung — beenden Sie die IdP-Sitzung (z. B. Keycloak) beim Abmelden von Semaphore, um einen ordnungsgemäßen Kontowechsel zu ermöglichen. (#1496)

Pro #

• LDAP-Anmeldeinformationen mit Zugriffsschlüsseln synchronisieren — aktualisieren Sie optional das Zugriffsschlüssel-Passwort automatisch, wenn sich das LDAP-Passwort bei der Anmeldung ändert, um Ansible-Anmeldeinformationen synchron zu halten. (#3696)

Enterprise #

• OIDC-Gruppen-zu-Rollen-Zuordnung — weisen Sie Semaphore-Rollen und Projektmitgliedschaften automatisch basierend auf OIDC-Claims (z. B. groups-Claim) zu, um die manuelle Benutzereinrichtung nach der ersten Anmeldung zu eliminieren. (#1499, #2483)
• LDAP-Gruppen-zu-Rollen-Zuordnung — ordnen Sie Active-Directory-/LDAP-Gruppen Semaphore-Rollen zu, einschließlich der Admin-Rollenzuweisung über Gruppenmitgliedschaft. (#3226, #1316)
• Vollständiges RBAC mit LDAP-/OIDC-Integration — implementieren Sie granulare rollenbasierte Zugriffskontrolle (globaler Admin, Projektadmin, Projektbenutzer, schreibgeschützt) mit automatischer Rollenzuweisung aus externen Identitätsanbietergruppen. (#891)
• Austauschbare Authentifizierungsarchitektur — abstrahieren Sie die Authentifizierung in eine Anbieterschnittstelle, um mehrere Authentifizierungs-Backends zu unterstützen und das Hinzufügen neuer Anbieter zu vereinfachen. (#465, #1820)
• Benutzerlöschung hinterlässt verwaiste Daten — beheben — stellen Sie sicher, dass das Löschen eines Benutzers project__user-Zuordnungen bereinigt, um Abstürze in der Team-Ansicht zu verhindern. (#3514)

Integriertes Inventarverwaltungssystem #

Heute behandelt Semaphore das Inventar als undurchsichtigen Blob — Benutzer fügen entweder rohes INI/YAML in ein einzelnes Textfeld ein oder verweisen auf eine Datei in einem Repository. Es gibt keine strukturierte Möglichkeit, einen Host hinzuzufügen, Hosts in Gruppen zu organisieren oder Host- und Gruppenvariablen über die Benutzeroberfläche festzulegen. Diese Funktion führt ein integriertes Inventarverwaltungssystem ein: einen strukturierten, über die Benutzeroberfläche verwalteten Inventar-Editor (ähnlich wie AWX-Inventare), bei dem Hosts, Gruppen und Variablen erstklassige Objekte sind, die in Semaphore gespeichert und direkt in der Weboberfläche bearbeitet werden können, während sie vollständig in ein standardmäßiges Ansible-Inventar exportierbar bleiben.

Community #

• Strukturierter Host- und Gruppeneditor — verwalten Sie Hosts, ihre Adressen/Aliase und Host-Gruppen über die Benutzeroberfläche, anstatt ein rohes Inventar-Textfeld von Hand zu bearbeiten, mit Aktionen zum Hinzufügen/Entfernen/Umbenennen von Hosts und Gruppen. (#836)
• Host- und Gruppenvariablen in der Benutzeroberfläche — definieren Sie host_vars und group_vars als strukturierte Schlüssel/Wert-Paare pro Host und pro Gruppe, sodass Verbindungseinstellungen und benutzerdefinierte Variablen nicht mehr von Hand in den Inventarkörper eingebettet werden müssen.
• Verbesserter Inline-Inventar-Editor — ersetzen Sie das kleine Inventar-Textfeld durch einen größeren, in der Größe veränderbaren Editor mit YAML-/INI-Syntaxhervorhebung und Validierung, wodurch der vorhandene Inline-Bearbeitungsmodus tatsächlich nutzbar wird. (#698, #1650)
• Vorhandenes Inventar importieren — starten Sie ein verwaltetes Inventar, indem Sie eine vorhandene INI-/YAML-Inventardatei importieren oder ihren Inhalt einfügen und in strukturierte Hosts, Gruppen und Variablen parsen.
• Deklarative Inventardefinitionen — definieren Sie Inventare (Hosts, Gruppen, Variablen) deklarativ über ein YAML-Dokument, das Semaphore verwaltet, um eine versionskontrollierte, reproduzierbare Inventareinrichtung neben Projekten und Vorlagen zu ermöglichen. (#3109)
• Export in standardmäßiges Ansible-Inventar — rendern Sie das verwaltete Inventar zur Aufgabenlaufzeit in eine standardmäßige Ansible-Inventardatei, sodass Playbooks und ansible-inventory genau dieselbe Struktur sehen, unabhängig davon, wie sie erstellt wurde.

Pro #

• Wiederverwendbare Host-Gruppen — definieren Sie Host-Gruppen einmal und teilen Sie sie über mehrere Inventare und Projekte hinweg, sodass eine Änderung der Gruppenmitgliedschaft oder der Gruppenvariablen überall dort propagiert wird, wo die Gruppe verwendet wird.
• Inventar-Änderungsverlauf — führen Sie einen Revisionsverlauf pro Inventar mit Diffs von Host-, Gruppen- und Variablenänderungen und ermöglichen Sie die Wiederherstellung einer vorherigen Version.

Enterprise #

• Gescopte Host-Verwaltungsrolle — führen Sie eine Operator-ähnliche Rolle ein, die Hosts in bestimmten Inventaren hinzufügen, bearbeiten und entfernen kann (und vordefinierte Vorlagen ausführen kann), ohne die volle Projektadministration zu gewähren. (#2989)
• Genehmigung von Inventaränderungen — erfordern Sie eine Überprüfung/Genehmigung, bevor Änderungen an geschützten Inventaren wirksam werden, mit einem Audit-Trail darüber, wer wann welchen Host, welche Gruppe oder welche Variable geändert hat.

Flexibles Benachrichtigungssystem #

Das aktuelle Benachrichtigungssystem in der Semaphore-Benutzeroberfläche wird ausschließlich über config.json konfiguriert, unterstützt eine begrenzte Anzahl von Kanälen (E-Mail, Telegram, Slack, MS Teams) und arbeitet auf globaler Ebene mit minimaler Anpassung pro Projekt. Diese Funktion gestaltet Benachrichtigungen von Grund auf neu, sodass sie über die Benutzeroberfläche verwaltet, erweiterbar und auf Projekt- und Vorlagengranularität konfigurierbar sind.

Community #

• Erweiterbare Kanalarchitektur — definieren Sie eine gemeinsame Schnittstelle für Benachrichtigungskanäle mit Implementierungen pro Kanal, wodurch das Hinzufügen neuer Kanäle ohne Änderung der Kernlogik vereinfacht wird. Erwägen Sie die Einführung einer universellen Benachrichtigungsbibliothek (z. B. nikoksr/notify) oder eines Gateways (z. B. Apprise), um viele Anbieter gleichzeitig abzudecken. (#2325, #1290)
• Von der Benutzeroberfläche verwaltete Benachrichtigungskonfiguration — verschieben Sie die Benachrichtigungseinrichtung von Konfigurationsdateien in die Web-Benutzeroberfläche mit Granularität pro Projekt und pro Vorlage und unterstützen Sie mehrere Instanzen desselben Kanaltyps. (#3387, #1821, #3588)
• Vorlagenbasierte Nachrichtenanpassung — unterstützen Sie benutzerdefinierte Nachrichtenvorlagen, die als Dateien auf der Festplatte statt in der Datenbank gespeichert werden.
• Kanalauswahl pro Projekt — ermöglichen Sie Benutzern, über die Projekteinstellungen zu konfigurieren, welche Benachrichtigungskanäle pro Projekt aktiv sind. (#3588)
• Ausgehende Webhook-Ereignisse — definieren Sie Ereignistypen (START, SUCCESS, FAILURE) und ermöglichen Sie die Erstellung von Webhook-Vorlagen pro Projekt mit konfigurierbarer URL, Headern und HMAC-Authentifizierung. (#1825, #2594, #3066)
• Neue Benachrichtigungskanäle — Unterstützung für Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) und Pushover (#2594) hinzufügen.
• „Behoben"-Benachrichtigungen — senden Sie eine Benachrichtigung beim ersten erfolgreichen Lauf nach einem Fehler, ähnlich den GitLab CI-Wiederherstellungswarnungen. (#3380)
• Alle Benachrichtigungen pro Vorlage deaktivieren — fügen Sie neben dem vorhandenen Kontrollkästchen „Erfolgreiche Benachrichtigungen deaktivieren" die Option „Alle Benachrichtigungen deaktivieren" hinzu. (#3724)
• E-Mail bei Erfolg — E-Mail in den Erfolgsbenachrichtigungspfad aufnehmen (derzeit werden nur Telegram/Slack/MS Teams bei Erfolg ausgelöst). (#3503)
• Aufgaben-URL in Benachrichtigungen korrigieren — stellen Sie sicher, dass alle Kanäle (E-Mail, Slack, MS Teams) eine vollständig qualifizierte Aufgaben-URL mit Schema und Host erhalten, nicht einen relativen Pfad. (#2097, #2311, #3292)
• Probleme bei der E-Mail-Zustellung beheben — beheben Sie die Unterstützung für SMTP-Port 465 (implizites TLS), die Reihenfolge der Authentifizierung vor TLS und die Formatierung des Date-Headers. (#2201, #2971, #3542, #3209)
• Telegram-Thread-/Themenunterstützung — ermöglichen Sie das Senden von Benachrichtigungen an bestimmte Telegram-Gruppen-Threads über message_thread_id, konfigurierbar pro Projekt und pro Vorlage. (#3493, #1456)
• Verbesserungen der Slack-Vorlage — stellen Sie Felder der obersten Ebene (title, text, color) für die Kompatibilität mit Slack Workflow Builder bereit. (#2607)
• Alert-Proxy-Unterstützung — ermöglichen Sie die Konfiguration eines HTTP-Proxys für ausgehende Benachrichtigungsanfragen, ohne dass ein systemweiter Proxy erforderlich ist. (#1484)

Pro #

• Nur-Pro-Benachrichtigungskanäle — unterstützen Sie bestimmte Benachrichtigungskanäle ausschließlich im Pro-Plan.
• Benachrichtigungen bei lang laufenden Aufgaben — lösen Sie eine Benachrichtigung aus, wenn eine Aufgabe einen konfigurierbaren Dauerschwellenwert überschreitet. (#1393)

Enterprise #

• Überwachungsprotokoll für Benachrichtigungen — führen Sie ein durchsuchbares Protokoll aller gesendeten Benachrichtigungen mit Zustellungsstatus, Zeitstempeln und Empfängerdetails. Verbessern Sie die Fehlerprotokollierung, um den Empfängerkontext bei Fehlern einzubeziehen. (#3410)
• Integration mit Incident-Management-Plattformen — native Integrationen mit PagerDuty, Opsgenie und ServiceNow für die automatische Erstellung von Incidents und Lebenszyklusverfolgung.
• Rollenbasierte Benachrichtigungszugriffskontrolle — schränken Sie ein, wer Benachrichtigungsregeln und -kanäle basierend auf organisatorischen Rollen und Berechtigungen konfigurieren kann.

Benutzereigene Geheimnisse #

Der Schlüsselspeicher von Semaphore wird derzeit von allen Projektmitgliedern gemeinsam genutzt. Jeder Benutzer mit Projektzugriff kann alle gespeicherten Anmeldeinformationen verwenden (und in einigen Fällen einsehen). Dies schafft Sicherheitsbedenken in Mehrbenutzerumgebungen, in denen Teammitglieder nur Zugriff auf ihre eigenen Anmeldeinformationen haben sollten. Darüber hinaus hat der Schlüsselspeicher mehrere Fehler bei der Verschlüsselung, Aktualisierung von Geheimnissen und referenzieller Integrität und es fehlt die Integration mit externen Geheimnisverwaltungssystemen.

Community #

• Persönlicher Schlüsselspeicher — stellen Sie einen Schlüsselspeicher pro Benutzer bereit, sodass persönliche Anmeldeinformationen (SSH-Schlüssel, Sudo-Passwörter) von anderen Projektmitgliedern isoliert und nicht über den Schlüsselspeicher auf Projektebene geteilt werden. (#1483, #1373)
• Verhalten bei Geheimnisaktualisierung beheben — beheben Sie das Problem, bei dem das Bearbeiten einer geheimen Umgebungsvariablen erfolgreich erscheint, der Wert aber nicht tatsächlich gespeichert wird. (#2546)
• Geheimnisse aus der Prozessliste ausblenden — übergeben Sie keine geheimen Extra-vars über Befehlszeilenargumente, die in der OS-Prozessliste sichtbar sind; verwenden Sie einen sicheren Mechanismus (z. B. temporäre Dateien, stdin). (#3219)
• SSH-Zertifikatsunterstützung im Schlüsselspeicher — ermöglichen Sie das Speichern von SSH-Zertifikaten neben SSH-Schlüsseln für zertifikatsbasierte Authentifizierungsabläufe. (#3171)
• Öffentlichen SSH-Schlüssel anzeigen — zeigen Sie den öffentlichen Schlüsselteil gespeicherter SSH-Schlüssel in der Schlüsselspeicher-Benutzeroberfläche zur Bequemlichkeit an. (#1643)
• Docker-Geheimnisse-Unterstützung — unterstützen Sie das _FILE-Umgebungsvariablenmuster (z. B. POSTGRES_PASSWORD_FILE), sodass Docker-/Kubernetes-Geheimnisse gemountet und gelesen werden können, anstatt sie über Umgebungsvariablen zu übergeben. (#1268)
• Verschlüsselungsschlüssel-Behandlung in Docker beheben — stellen Sie sicher, dass die Umgebungsvariable SEMAPHORE_ACCESS_KEY_ENCRYPTION berücksichtigt wird und nicht bei einem Container-Neustart mit einem zufälligen Schlüssel überschrieben wird. (#2228, #3068, #3204)
• Schlüsselspeicher-Umbenennung bricht Referenzen — beheben — beheben Sie das Problem, bei dem das Umbenennen eines Schlüsselspeichereintrags alle verknüpften Inventare und Vorlagen unterbricht. (#3188)
• Vault-Passwort-API beheben — ermöglichen Sie das Setzen und Aktualisieren von Ansible-Vault-Passwörtern über die REST-API ohne Fehler durch doppelte Schlüssel-Einschränkungen. (#3413, #2773)

Pro #

• Externe Geheimnisspeicher-Integration — rufen Sie Geheimnisse zur Laufzeit von HashiCorp Vault, Azure Key Vault, AWS KMS oder Bitwarden ab, anstatt sie in der Semaphore-Datenbank zu speichern. (#2248, #658)

Enterprise #

• Globale Zugriffsschlüssel — teilen Sie Schlüsselspeichereinträge projektübergreifend ohne Duplizierung, mit zentraler Verwaltung und projektübergreifender Verknüpfung. (#110)
• Audit-Trail für Geheimniszugriff — protokollieren Sie alle Zugriffe und Verwendungen von Schlüsselspeichereinträgen und geheimen Variablen für Compliance und Forensik.

Anmeldeinformationen für requirements.yml Mehr erfahren #

Ansible-Playbooks deklarieren häufig private Rollen und Sammlungen in requirements.yml, die in privaten Git-Repositories liegen. Semaphore hat derzeit keine erstklassige Möglichkeit, ansible-galaxy install gegen diese Repositories zu authentifizieren — Benutzer behelfen sich damit, Tokens in URLs einzubetten, SSH-Schlüssel in Runner-Images zu integrieren oder benutzerdefinierte Vorbereitungsskripte zu pflegen. Diese Funktion ermöglicht es Benutzern, eine oder mehrere Schlüsselspeicher-Anmeldeinformationen an eine Aufgabenvorlage (oder einen Playbook-Lauf) anzuhängen und sie automatisch während der Vorbereitungsphase verwenden zu lassen, wenn Rollen und Sammlungen aufgelöst werden.

Community #

• Anmeldeinformationen an einen Playbook-Lauf anhängen — ermöglichen Sie die Auswahl eines oder mehrerer Schlüsselspeichereinträge (SSH-Schlüssel, Git-Token, Benutzername/Passwort) in einer Aufgabenvorlage, die während ansible-galaxy install angewendet werden, sodass in requirements.yml aufgeführte private Rollen und Sammlungen aus privaten Git-Repositories abgerufen werden können. (#3677, #3708, #897)
• Anmeldeinformationszuordnung pro Host-Muster — wenn mehrere Anmeldeinformationen angehängt sind, ordnen Sie sie Hostnamen-Mustern zu (z. B. github.com, gitlab.internal), sodass jede private Quelle den korrekten Schlüssel oder Token ohne Kollisionen verwendet. (#3677)
• Weitergabe von Umgebungsvariablen an die Galaxy-Install-Phase beheben — stellen Sie sicher, dass Umgebungsvariablen (einschließlich geheimer) während ansible-galaxy install exportiert werden, nicht nur während der Playbook-Ausführung, sodass tokenbasierte Authentifizierung für requirements.yml funktioniert. (#2966, #3178)
• Requirements-Datei pro Playbook — ermöglichen Sie das Überschreiben des Standardpfads roles/requirements.yml / collections/requirements.yml auf Vorlagenebene für Projekte, die mehrere Playbooks mit unterschiedlichen Abhängigkeitssätzen gruppieren. (#1366)
• Benutzerdefinierte ansible-galaxy-CLI-Argumente — stellen Sie ein Feld für zusätzliche Argumente bereit, die an ansible-galaxy install übergeben werden (z. B. --ignore-certs, --force, benutzerdefinierter Server), um Air-Gapped- und interne Galaxy-Mirror-Setups abzudecken. (#2348)

Persistenter Repository-Cache #

Derzeit klont (oder pullt) Semaphore das Repository für jede Aufgabenvorlage in ein separates Verzeichnis, was bei großen Repositories langsam sein kann und Festplatten-I/O verschwendet. Diese Funktion fügt ein Flag pro Repository hinzu, das auf einen gemeinsam genutzten, persistenten Klon umschaltet, der regelmäßig im Hintergrund aktualisiert wird — ähnlich wie AWX Projektaktualisierungen handhabt. Wenn aktiviert, teilen sich alle Vorlagen, die das Repository referenzieren, eine einzelne Arbeitskopie (dasselbe Modell, das bereits für lokale Repositories in Semaphore verwendet wird), und einzelne Aufgabenausführungen lösen keinen Klon- oder Pull-Vorgang mehr aus.

Community #

• „Cache Repository"-Flag in den Repository-Einstellungen — fügen Sie jedem Repository einen Schalter hinzu, der bei Aktivierung einen einzelnen persistenten Klon beibehält, anstatt pro Aufgabenausführung zu klonen. Der Klon wird von allen Vorlagen gemeinsam genutzt, die das Repository verwenden, und entspricht dem Verhalten, das lokale Repositories bereits haben. (#1212)
• Periodische Hintergrundsynchronisation — wenn das Cache-Flag aktiviert ist, werden Updates in einem konfigurierbaren Intervall (z. B. alle 5 Minuten) in einem Hintergrund-Worker abgerufen, anstatt beim Start der Aufgabe, sodass Aufgaben immer sofort gegen einen aktuellen Checkout gestartet werden.
• Manuelle Synchronisationsaktion — stellen Sie eine „Jetzt synchronisieren"-Schaltfläche in der Repository-Benutzeroberfläche und einen entsprechenden API-Endpunkt bereit, um einen sofortigen Pull außerhalb des periodischen Zeitplans auszulösen.
• Resilienz gegenüber Force-Push / History-Rewrite — behandeln Sie Upstream-Force-Pushes elegant (z. B. git fetch --all && git reset --hard origin/<branch>), anstatt bei einem normalen Pull fehlzuschlagen. (#800)
• Wiederherstellung eines verschmutzten Arbeitsverzeichnisses — erkennen und bereinigen Sie automatisch ein verschmutztes Arbeitsverzeichnis (z. B. übrig gebliebene .retry-Dateien) vor dem Pull, um Fehler durch „lokale Änderungen" zu verhindern. (#308)
• Bereinigung veralteter Klone — entfernen Sie gecachte Klone für Repositories, die gelöscht wurden oder deren URL sich geändert hat, um Speicherplatz freizugeben. (#1497, #2679)
• Sichtbarkeit des Synchronisationsstatus — zeigen Sie den Zeitstempel und Status (Erfolg/Fehler) der letzten Synchronisation auf der Repository-Detailseite an, damit Benutzer wissen, wie aktuell die Arbeitskopie ist.
• Synchronisationszeitplan pro Repository — ermöglichen Sie das Überschreiben des globalen Synchronisationsintervalls für einzelne Repositories (z. B. Repositories mit hoher Änderungsrate jede Minute, stabile Repositories jede Stunde).

Mehrere Inventare pro Vorlage #

Ansible CLI unterstützt nativ die Übergabe mehrerer -i-Argumente zum Zusammenstellen von Inventaren (z. B. ansible-playbook -i common_vars.yml -i staging_hosts.yml). Semaphore beschränkt derzeit jede Aufgabenvorlage auf ein einzelnes Inventar und zwingt Benutzer zu Workarounds wie Inventarskripten, zusammengeführten Dateien oder zusätzlichen Umgebungsvariablen. Diese Funktion hebt diese Einschränkung auf und schließt die umfassenderen Lücken in der Inventarverwaltung.

Community #

• Unterstützung mehrerer Inventare — ermöglichen Sie das Anhängen mehrerer Inventare an eine einzelne Aufgabenvorlage, die als sequentielle -i-Argumente an Ansible übergeben werden (z. B. ansible-playbook -i common_vars.yml -i staging_hosts.yml). Behebt die Beschränkung auf ein Inventar pro Vorlage. (#2093)
• Optionales Inventarfeld — machen Sie das Inventarfeld in Vorlagen optional für Fälle, in denen ansible.cfg bereits die Inventarquelle angibt. (#1574)
• URL-/HTTP-Inventarquelle — unterstützen Sie das Abrufen von Inventar von einer Remote-URL oder einem API-Endpunkt, wichtig für gehostete/SaaS-Umgebungen ohne Dateisystemzugriff. (#1924)
• Inventarauswahl zur Laufzeit — ermöglichen Sie Benutzern die Auswahl eines Inventars beim Start der Aufgabe über ein Dropdown-Menü und ersetzen Sie damit den aktuellen Freitext-Workaround. (#1354)
• Persistenz des Inventars geplanter Aufgaben beheben — stellen Sie sicher, dass das in einem Zeitplandialog ausgewählte Inventar gespeichert und zum Ausführungszeitpunkt verwendet wird, anstatt auf den Vorlagenstandard zurückzufallen. (#3566, #3293)
• Verlust der Inventar-Repository-Verknüpfung beim Projektexport/-wiederherstellung beheben — Inventar-zu-Repository-Zuordnungen werden während des Projektexports gelöscht und beim Import nicht wiederhergestellt. (#3369, #3177)
• Umgebungsvariablen an dynamisches Inventar übergeben — stellen Sie sicher, dass Container-/Host-Umgebungsvariablen für dynamische Inventarskripte und Plugins (z. B. Python-Skripte, microsoft.ad.ldap) verfügbar sind. (#2724, #2783)
• Git-basierte Inventarauthentifizierung beheben — verwenden Sie Repository-Anmeldeinformationen beim Abrufen von Remote-Branches für das Inventar und beheben Sie nicht authentifizierte Zugriffsversuche. (#3539)
• Anmeldeinformationsüberschreibungen pro Host — verhindern Sie das Überschreiben von pro Host definierten ansible_user- und Verbindungsvariablen im Inventar durch globale --extra-vars. Ermöglichen Sie Mehrbenutzer-Inventarmuster. (#1464, #1621)
• Inventarinhalt in der Benutzeroberfläche anzeigen — zeigen Sie dateibasierte und dynamische Inventarinhalte in der Benutzeroberfläche zur Inspektion und Fehlerbehebung an, mit einem Link zur Quelldatei im externen Repository. (#3169, #1555, #3543)
• Inventarname im Aufgabenkontext bereitstellen — machen Sie den Inventarnamen in semaphore_vars oder als Umgebungsvariable verfügbar, damit Playbooks referenzieren können, welches Inventar aktiv ist. (#1580)

Pro #

• Inventar-zu-Runner-Affinität — verknüpfen Sie Inventar-Hosts mit Runner-Tags, sodass Aufgaben nur an Runner gesendet werden, die Netzwerkzugriff auf die Zielhosts haben, um Fehler in Mehrnetzwerkumgebungen zu vermeiden. (#3322)
• Mehrere SSH-Schlüssel pro Inventar — ermöglichen Sie die Zuweisung mehrerer Schlüsselspeicher-Einträge zu einem einzelnen Inventar für Flotten, in denen jeder Host einen eindeutigen SSH-Schlüssel verwendet. (#3336)
• Hypervisor-Inventarintegration — native Integration mit Hypervisor-APIs (VMware, Proxmox) zum automatischen Generieren und Aktualisieren dynamischer Inventare. (#2709)
• Host-Gruppenverwaltungs-API — stellen Sie eine API bereit, um Hosts zu Inventargruppen hinzuzufügen oder daraus zu entfernen, ohne die gesamte Inventar-Payload neu zu schreiben. (#1560)

Enterprise #

• Zulässige Inventare pro Vorlage einschränken — wenn bei einer Vorlage „Nach Inventar fragen" aktiviert ist, beschränken Sie die auswählbaren Inventare auf eine vom Administrator definierte Zulassungsliste, um das versehentliche Ansprechen falscher Umgebungen zu verhindern. (#3587)
• Zentrales Host-Register — stellen Sie eine gemeinsame Host-Verwaltungsschicht bereit, sodass Host-Änderungen (z. B. Hostname- oder IP-Aktualisierungen) an alle Inventare weitergegeben werden, die diesen Host referenzieren, ohne manuelle Bearbeitungen. (#564)
• Host-Fakten-Speicherung und Visualisierung — speichern Sie Ansible-Fakten pro Host und zeigen Sie den Zustand vor/nach Aufgabenausführungen mit Diff- und Verlaufsfunktionen an. (#930)