Roadmap

Cloud Secret Manager Integration Mehr erfahren #

Organisationen, die Cloud-Plattformen nutzen, benötigen eine Möglichkeit, Geheimnisse zur Laufzeit direkt vom Geheimnisverwaltungsdienst ihres Cloud-Anbieters abzurufen, um die Duplizierung von Anmeldeinformationen zu vermeiden und bestehende Rotationsrichtlinien zu nutzen. Diese Funktion fügt native Integrationen mit AWS Secrets Manager und Azure Key Vault als ausschließliche Enterprise-Funktionen hinzu.

Enterprise #

• AWS Secrets Manager-Integration — Geheimnisse zur Laufzeit aus AWS Secrets Manager abrufen, unter Verwendung von IAM-Rollen, Zugriffsschlüsseln oder übernommenen Rollen. Unterstützt JSON-strukturierte Geheimnisse mit Feldextraktion und automatischer Rotation. (#2248)
• Azure Key Vault-Integration — Geheimnisse zur Laufzeit aus Azure Key Vault abrufen, unter Verwendung von Managed Identity oder Service-Principal-Authentifizierung. Unterstützt Geheimnisse, Schlüssel und Zertifikate mit automatischer Rotation. (#2248, #3170)
• Geheimnis-Caching — reduzieren Sie API-Aufrufe an Cloud-Anbieter, indem Sie aufgelöste Geheimnisse im Arbeitsspeicher zwischenspeichern.

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

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)

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.

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)

Mehrere Variablengruppen pro Vorlage #

Semaphore erlaubt derzeit das Anhängen einer einzelnen Variablengruppe (Umgebung) an jede Aufgabenvorlage. Dies zwingt Benutzer dazu, Variablen über Gruppen hinweg zu duplizieren, wenn mehrere Vorlagen gemeinsame Einstellungen teilen, oder monolithische Variablengruppen zu erstellen, die alles enthalten. Diese Funktion ermöglicht das Zusammenstellen mehrerer Variablengruppen pro Vorlage und behebt die zahlreichen Fehler bei der Variablenbehandlung — Serialisierung, Priorität, Weitergabe und Lebenszyklus von Survey-Variablen.

Community #

• Multi-Umgebungskomposition — ermöglichen Sie das Anhängen mehrerer Variablengruppen an eine einzelne Aufgabenvorlage, sodass gemeinsame Variablensätze (z. B. gemeinsame Standardwerte, regionale Überschreibungen) zusammengestellt und über Vorlagen hinweg wiederverwendet werden können. (#2612)
• Variablengruppen klonen — fügen Sie eine Klonaktion hinzu, damit Umgebungen, die sich nur in wenigen Werten unterscheiden, eingerichtet werden können, ohne alle Felder von Grund auf neu zu erstellen. (#3295)
• Wiederverwendbare Survey-Variablensätze — entkoppeln Sie Survey-Variablen von Aufgabenvorlagen in eigenständige zuweisbare Objekte, um Duplizierung pro Vorlage zu vermeiden. (#2212)
• Extra-vars-JSON-Serialisierung beheben — serialisieren Sie komplexe Extra-vars als korrektes JSON anstelle von Go-Map-Strings, um jsondecode-Fehler in Terraform/OpenTofu zu beheben. (#3748, #1644, #2619)
• Survey-Variablen-Priorität beheben — beheben Sie die stille Überschreibung, wenn derselbe Variablenname sowohl in Umgebungs-Extra-vars als auch in Surveys existiert; definieren Sie eine klare Priorität oder geben Sie einen Fehler aus. (#3108)
• Leere/optionale Survey-Variablenbehandlung beheben — stellen Sie sicher, dass optionale Survey-Variablen konsistent weggelassen oder als leere Strings übergeben werden, nicht zufällig gemischt. (#2182)
• Survey-Standardwerte für geplante Aufgaben — ermöglichen Sie die Angabe von Standardwerten für Survey-Variablen bei der Aufgabenplanung, damit automatisierte Ausführungen nicht bei erforderlichen Eingabeaufforderungen fehlschlagen. (#2244)
• Survey-Variablen als Umgebungsvariablen für Bash-Aufgaben übergeben — stellen Sie Survey-Variablen als OS-Umgebungsvariablen anstelle von CLI-Argumenten für Shell-Aufgaben bereit. (#2433)
• Survey-Variablen während Tofu/Terraform init übergeben — leiten Sie Survey-Variablen an die init-Phase weiter, nicht nur an plan/apply, um variablengesteuerte Backend-Konfigurationen zu unterstützen. (#2554)
• Jinja2-Referenzen in zusätzlichen CLI-Argumenten — ermöglichen Sie die Referenzierung von Survey- und Umgebungsvariablen im Feld für zusätzliche CLI-Argumente mithilfe von Vorlagensyntax (z. B. -l {{ hosts }}). (#1053)
• Umgebungsvariablen in der Laufvorbereitung — machen Sie Umgebungsvariablen während der Vorbereitungsphase verfügbar (z. B. galaxy install, Git-Rollen-Authentifizierung), nicht nur während der Aufgabenausführung. (#3178)
• Extra-vars aus Repository-Datei laden — unterstützen Sie das Laden von Extra-vars aus einer JSON-/YAML-Datei im Repository anstelle von Inline in der Benutzeroberfläche, um GitOps-Workflows zu ermöglichen. (#2343)
• Umgebung zur Laufzeit per API überschreiben — ermöglichen Sie die Übergabe einer anderen Variablengruppe beim Starten einer Aufgabe über die API. (#1367, #3291)

Pro #

• Komplexe Survey-Variablentypen — unterstützen Sie dynamische Liste-von-Objekten-Survey-Variablen (z. B. VLAN-Konfigurationen), die als strukturierte JSON-Arrays übergeben werden. (#3557)
• Variablenüberschreibungen pro Zeitplan — hängen Sie benutzerdefinierte Variablenwerte an geplante Aufgaben an, damit dieselbe Vorlage mit verschiedenen Zeitplänen und verschiedenen Parametern ausgeführt werden kann. (#2378)
• Dynamische Variablenwerte aus dem Benutzerkontext — füllen Sie Variablen automatisch mit der Identität des angemeldeten Benutzers (z. B. {{ current_user }}). (#2524, #909)

Enterprise #

• Variablen als privat markieren — fügen Sie ein „Privat"-Flag für Variablen hinzu, das verhindert, dass Werte in Ausführungsprotokollen, Aufgabenverlauf und API-Antworten erscheinen. (#2887)
• Sichtbarkeit von Umgebungsvariablen einschränken — beschränken Sie den Inhalt von Variablengruppen auf Administratorrollen, um die Offenlegung von Anmeldeinformationen in gemeinsam genutzten Projektvorlagen zu verhindern. (#1126)
• Variablen-Snapshots auf Build-Ebene — erstellen Sie Snapshots der Variablenwerte zum Zeitpunkt der Aufgabenausführung, sodass erneute Ausführungen die ursprünglichen Werte verwenden, nicht die aktuellen. (#1097)

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.

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.

Community #

• 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 mit DAG-Graph und pro-Knoten-Status (ausstehend, laufend, erfolgreich, fehlgeschlagen, übersprungen), anklickbaren Knoten-Logs und Gesamtzeit.
• Variablenübergabe zwischen Knoten — Aufgabenvorlagen können 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 Umfragevariablen auf Workflow-Ebene. (#3088)

Pro #

• 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, Zugangsdaten, 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 und auf menschliche Genehmigung 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 — Versionshistorie der Workflow-Definitionen mit Diffs pflegen, vorherige Versionen wiederherstellen und aufzeichnen, welche Version für jeden Lauf verwendet wurde.