Roadmap

Integración con Cloud Secret Manager Leer #

Las organizaciones que utilizan plataformas en la nube necesitan una forma de obtener secretos directamente del servicio de gestión de secretos de su proveedor de nube en tiempo de ejecución, evitando la duplicación de credenciales y aprovechando las políticas de rotación existentes. Esta funcionalidad añade integraciones nativas con AWS Secrets Manager y Azure Key Vault como capacidades exclusivas de Enterprise.

Enterprise #

• Integración con AWS Secrets Manager — obtener secretos en tiempo de ejecución desde AWS Secrets Manager utilizando roles IAM, claves de acceso o roles asumidos. Soporta secretos estructurados en JSON con extracción de campos y rotación automática. (#2248)
• Integración con Azure Key Vault — obtener secretos en tiempo de ejecución desde Azure Key Vault utilizando identidad administrada o autenticación de entidad de servicio. Soporta secretos, claves y certificados con rotación automática. (#2248, #3170)
• Caché de secretos — reducir las llamadas de API a los proveedores de nube almacenando en caché en memoria los secretos resueltos.

Caché persistente de repositorio #

Actualmente, Semaphore clona (o hace pull de) el repositorio en un directorio separado para cada plantilla de tarea, lo que puede ser lento para repositorios grandes y desperdicia E/S de disco. Esta funcionalidad agrega una opción por repositorio que cambia a un clon compartido y persistente que se actualiza periódicamente en segundo plano, similar a cómo AWX gestiona las actualizaciones de proyectos. Cuando se habilita, todas las plantillas que hacen referencia al repositorio comparten una única copia de trabajo (el mismo modelo que ya se usa para repositorios locales en Semaphore), y las ejecuciones individuales de tareas ya no activan un clone o pull.

Community #

• Opción “Cache Repository” en la configuración del repositorio — agrega un interruptor a cada repositorio que, cuando se habilita, mantiene un único clon persistente en lugar de clonar por cada ejecución de tarea. El clon se comparte entre todas las plantillas que usan el repositorio, igualando el comportamiento que ya tienen los repositorios locales. (#1212)
• Sincronización periódica en segundo plano — cuando la opción de caché está habilitada, realiza pull de las actualizaciones en un intervalo configurable (por ejemplo, cada 5 minutos) en un worker en segundo plano en lugar de al inicio de la tarea, para que las tareas siempre se lancen instantáneamente contra un checkout reciente.
• Acción de sincronización manual — proporciona un botón “Sync Now” en la interfaz del repositorio y un endpoint de API correspondiente para activar un pull inmediato fuera del calendario periódico.
• Resiliencia ante force-push / reescritura de historial — gestiona los force-push del origen de forma elegante (por ejemplo, git fetch --all && git reset --hard origin/<branch>) en lugar de fallar en un pull normal. (#800)
• Recuperación de árbol de trabajo sucio — detecta y limpia automáticamente un árbol de trabajo sucio (por ejemplo, archivos .retry sobrantes) antes de hacer pull, evitando errores de “cambios locales”. (#308)
• Limpieza de clones obsoletos — recolecta los clones en caché para repositorios que han sido eliminados o cuya URL ha cambiado, recuperando espacio en disco. (#1497, #2679)
• Visibilidad del estado de sincronización — muestra la marca de tiempo y el estado de la última sincronización (éxito/fallo) en la página de detalle del repositorio para que los usuarios sepan qué tan reciente es la copia de trabajo.
• Calendario de sincronización por repositorio — permite anular el intervalo de sincronización global en repositorios individuales (por ejemplo, repos con muchos cambios cada minuto, repos estables cada hora).

Mapeo de grupos LDAP y OpenID #

Semaphore soporta LDAP y OpenID Connect (OIDC) para autenticación, pero la integración se detiene en el inicio de sesión — no hay asignación automática de roles o proyectos basada en membresías de grupo del proveedor de identidad. Cada usuario OIDC/LDAP debe ser asignado manualmente a proyectos y roles después del primer inicio de sesión. Además, hay múltiples errores en el manejo de redirecciones OIDC, el análisis de claims y la configuración LDAP que hacen que la experiencia de autenticación sea poco confiable.

Community #

• Restringir inicio de sesión OIDC por claim — permitir solo a usuarios con valores de claim específicos (por ejemplo, membresía de grupo requerida o dominio de email) iniciar sesión. (#2626, #2938)
• Auto-inicio de sesión SSO — omitir la pantalla de inicio de sesión y redirigir directamente al proveedor OIDC/SSO, con una URL de respaldo para recuperación si el SSO no funciona. (#2548, #2899)
• Soporte OIDC PKCE — agregar Proof Key for Code Exchange al flujo de código de autorización OIDC como lo recomienda RFC 9700. (#3072)
• Configuración OIDC mediante variables de entorno — permitir configurar proveedores OIDC mediante variables de entorno en lugar de solo archivo de configuración, simplificando la gestión de secretos en contenedores. (#2528, #3120)
• Corregir redirección OIDC con web_host/web_root — resolver errores 404 después del inicio de sesión OIDC cuando web_host está vacío o web_root está configurado en una subruta. (#2681, #1524, #2532, #3121)
• Corregir manejo de claims OIDC — resolver problemas con username_claim siendo ignorado, claim email no siendo reconocido y client_secret_file produciendo solicitudes malformadas. (#1731, #2818, #3122)
• Corregir expresiones de claims LDAP — resolver expresiones de plantilla rotas en el mapeo LDAP (por ejemplo, mail | {{ .username }}@domain.com resolviendo a <no value>). (#3127)
• Corregir asignación de nombre de usuario LDAP — asegurar que los usuarios LDAP obtengan su nombre de usuario LDAP real en lugar de una cadena generada aleatoriamente. (#3688)
• Respaldo de autenticación local LDAP — permitir que las cuentas de administrador local sigan iniciando sesión cuando LDAP está habilitado, evitando el bloqueo si el servidor LDAP no funciona. (#1363)
• Registro de depuración LDAP — agregar salida de log útil para fallos de autenticación LDAP para hacer posible la resolución de problemas. (#2932)
• Vinculación de usuario OIDC/LDAP a cuenta local — permitir convertir o vincular cuentas locales existentes a proveedores de identidad externos sin crear duplicados. (#3339)
• Cierre de sesión del proveedor OIDC — finalizar la sesión del IdP (por ejemplo, Keycloak) al cerrar sesión en Semaphore, habilitando el cambio correcto de cuentas. (#1496)

Pro #

• Sincronizar credenciales LDAP con claves de acceso — opcionalmente auto-actualizar la contraseña de la clave de acceso cuando la contraseña LDAP cambia al iniciar sesión, manteniendo las credenciales de Ansible sincronizadas. (#3696)

Enterprise #

• Mapeo de grupo a rol OIDC — asignar automáticamente roles de Semaphore y membresías de proyecto basándose en claims OIDC (por ejemplo, claim groups), eliminando la configuración manual de usuario después del primer inicio de sesión. (#1499, #2483)
• Mapeo de grupo a rol LDAP — mapear grupos de Active Directory / LDAP a roles de Semaphore, incluyendo la asignación de rol de administrador mediante membresía de grupo. (#3226, #1316)
• RBAC completo con integración LDAP/OIDC — implementar control de acceso granular basado en roles (administrador global, administrador de proyecto, usuario de proyecto, solo lectura) con asignación automática de roles desde grupos de proveedores de identidad externos. (#891)
• Arquitectura de autenticación extensible — abstraer la autenticación en una interfaz de proveedor para soportar múltiples backends de autenticación y simplificar la adición de nuevos proveedores. (#465, #1820)
• Corregir eliminación de usuario dejando datos huérfanos — asegurar que eliminar un usuario limpie los mapeos project__user para evitar fallos en la vista de Equipo. (#3514)

Sistema de notificaciones flexible #

El sistema de notificaciones actual en Semaphore UI se configura exclusivamente a través de config.json, admite un conjunto limitado de canales (Email, Telegram, Slack, MS Teams) y opera a nivel global con mínima personalización por proyecto. Esta funcionalidad rediseña las notificaciones desde cero para que sean gestionadas desde la interfaz, extensibles y configurables a nivel de proyecto y plantilla.

Community #

• Arquitectura de canales extensible — define una interfaz común para canales de notificación con implementaciones por canal, facilitando la adición de nuevos canales sin modificar la lógica central. Considerar la adopción de una biblioteca universal de notificaciones (por ejemplo, nikoksr/notify) o una pasarela (por ejemplo, Apprise) para cubrir muchos proveedores a la vez. (#2325, #1290)
• Configuración de notificaciones gestionada desde la interfaz — mover la configuración de notificaciones de los archivos de configuración a la interfaz web con granularidad por proyecto y por plantilla, soportando múltiples instancias del mismo tipo de canal. (#3387, #1821, #3588)
• Personalización de mensajes basada en plantillas — soportar plantillas de mensajes definidas por el usuario almacenadas como archivos en disco en lugar de en la base de datos.
• Selección de canal por proyecto — permitir a los usuarios configurar qué canales de notificación están activos por proyecto a través de la configuración del proyecto. (#3588)
• Eventos de webhook salientes — definir tipos de eventos (START, SUCCESS, FAILURE) y permitir crear plantillas de webhook por proyecto con URL, encabezados y autenticación HMAC configurables. (#1825, #2594, #3066)
• Nuevos canales de notificación — agregar soporte para Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) y Pushover (#2594).
• Notificaciones de “recuperación” — enviar una notificación en la primera ejecución exitosa después de un fallo, similar a las alertas de recuperación de GitLab CI. (#3380)
• Deshabilitar todas las notificaciones por plantilla — agregar una opción “Deshabilitar todas las notificaciones” junto a la casilla existente “Deshabilitar notificaciones exitosas”. (#3724)
• Email en caso de éxito — incluir el email en la ruta de notificación de éxito (actualmente solo Telegram/Slack/MS Teams se activan en caso de éxito). (#3503)
• Corregir URL de tarea en notificaciones — asegurar que todos los canales (email, Slack, MS Teams) reciban una URL de tarea completa con esquema y host, no una ruta relativa. (#2097, #2311, #3292)
• Corregir problemas de entrega de email — resolver el soporte del puerto SMTP 465 (TLS implícito), el orden de autenticación antes de TLS y el formato del encabezado Date. (#2201, #2971, #3542, #3209)
• Soporte de hilos/temas de Telegram — permitir enviar notificaciones a hilos específicos de grupos de Telegram mediante message_thread_id, configurable por proyecto y por plantilla. (#3493, #1456)
• Mejoras en la plantilla de Slack — exponer campos de nivel superior (title, text, color) para compatibilidad con Slack Workflow Builder. (#2607)
• Soporte de proxy para alertas — permitir configurar un proxy HTTP para solicitudes de notificación salientes sin requerir un proxy a nivel de sistema. (#1484)

Pro #

• Canales de notificación exclusivos de Pro — soportar canales de notificación específicos exclusivamente en el plan Pro.
• Alertas de tareas de larga duración — activar una notificación cuando una tarea excede un umbral de duración configurable. (#1393)

Enterprise #

• Registro de auditoría para notificaciones — mantener un registro consultable de todas las notificaciones enviadas con estado de entrega, marcas de tiempo y detalles del destinatario. Mejorar el registro de errores para incluir contexto del destinatario en caso de fallos. (#3410)
• Integración con plataformas de gestión de incidentes — integraciones nativas con PagerDuty, Opsgenie y ServiceNow para creación automática de incidentes y seguimiento del ciclo de vida.
• Control de acceso a notificaciones basado en roles — restringir quién puede configurar reglas y canales de notificación según roles y permisos organizacionales.

Múltiples inventarios por plantilla #

Ansible CLI soporta nativamente el paso de múltiples argumentos -i para componer inventarios (por ejemplo, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Actualmente Semaphore restringe cada plantilla de tarea a un único inventario, obligando a los usuarios a recurrir a soluciones alternativas como scripts de inventario, archivos combinados o variables de entorno adicionales. Esta funcionalidad elimina esa restricción y aborda el conjunto más amplio de carencias en la gestión de inventarios.

Community #

• Soporte de múltiples inventarios — permitir adjuntar múltiples inventarios a una única plantilla de tarea, pasados como argumentos -i secuenciales a Ansible (por ejemplo, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Resuelve la limitación de un inventario por plantilla. (#2093)
• Campo de inventario opcional — hacer que el campo de inventario en las plantillas sea opcional para casos donde ansible.cfg ya especifica la fuente del inventario. (#1574)
• Fuente de inventario URL/HTTP — soportar la obtención de inventario desde una URL remota o endpoint de API, esencial para entornos alojados/SaaS sin acceso al sistema de archivos. (#1924)
• Selección de inventario en tiempo de ejecución — permitir a los usuarios seleccionar un inventario al momento de lanzar la tarea mediante un menú desplegable, reemplazando la solución alternativa actual de texto libre. (#1354)
• Corregir persistencia de inventario en tareas programadas — asegurar que el inventario seleccionado en el diálogo de programación se guarde y se use en el momento de ejecución en lugar de recurrir al valor predeterminado de la plantilla. (#3566, #3293)
• Corregir pérdida del enlace de repositorio de inventario en exportación/restauración de proyecto — las asociaciones de inventario a repositorio se eliminan durante la exportación del proyecto y no se restauran en la importación. (#3369, #3177)
• Pasar variables de entorno al inventario dinámico — asegurar que las variables de entorno del contenedor/host estén disponibles para los scripts y plugins de inventario dinámico (por ejemplo, scripts Python, microsoft.ad.ldap). (#2724, #2783)
• Corregir autenticación de inventario basado en git — usar las credenciales del repositorio al obtener ramas remotas para el inventario, corrigiendo intentos de acceso no autenticado. (#3539)
• Sobrescritura de credenciales por host — dejar de sobrescribir ansible_user por host y las variables de conexión definidas en el inventario con --extra-vars globales. Permitir patrones de inventario multiusuario. (#1464, #1621)
• Ver contenido del inventario en la interfaz — mostrar el contenido de inventarios basados en archivos y dinámicos en la interfaz para inspección y depuración, con un enlace al archivo fuente en el repositorio externo. (#3169, #1555, #3543)
• Exponer el nombre del inventario en el contexto de la tarea — hacer que el nombre del inventario esté disponible en semaphore_vars o como variable de entorno para que los playbooks puedan referenciar qué inventario está activo. (#1580)

Pro #

• Afinidad de inventario a runner — asociar hosts de inventario con etiquetas de runner para que las tareas se despachen solo a los runners que tengan acceso de red a los hosts de destino, evitando fallos en entornos multi-red. (#3322)
• Múltiples claves SSH por inventario — permitir asignar múltiples entradas del almacén de claves a un único inventario para flotas donde cada host usa una clave SSH distinta. (#3336)
• Integración de inventario con hipervisores — integración nativa con APIs de hipervisores (VMware, Proxmox) para generar y actualizar automáticamente inventarios dinámicos. (#2709)
• API de gestión de grupos de hosts — proporcionar una API para agregar/eliminar hosts de grupos de inventario sin reescribir toda la carga útil del inventario. (#1560)

Enterprise #

• Restringir inventarios permitidos por plantilla — cuando una plantilla tiene habilitado “solicitar inventario”, limitar los inventarios seleccionables a una lista de permitidos definida por el administrador, evitando la selección accidental de entornos incorrectos. (#3587)
• Registro central de hosts — proporcionar una capa de gestión de hosts compartida para que los cambios de host (por ejemplo, actualizaciones de nombre de host o IP) se propaguen a todos los inventarios que referencian ese host sin ediciones manuales. (#564)
• Almacenamiento y visualización de datos de hosts — almacenar datos (facts) de Ansible por host y mostrar el estado antes/después de las ejecuciones de tareas con capacidades de diff e historial. (#930)

Múltiples grupos de variables por plantilla #

Actualmente Semaphore permite adjuntar un único grupo de variables (entorno) a cada plantilla de tarea. Esto obliga a los usuarios a duplicar variables entre grupos cuando múltiples plantillas comparten configuraciones comunes, o a crear grupos de variables monolíticos que lo contienen todo. Esta funcionalidad permite componer múltiples grupos de variables por plantilla y corrige los numerosos errores en el manejo de variables: serialización, precedencia, propagación y ciclo de vida de variables de encuesta.

Community #

• Composición multi-entorno — permitir adjuntar múltiples grupos de variables a una única plantilla de tarea para que los conjuntos de variables compartidas (por ejemplo, valores predeterminados comunes, sobrescrituras por región) puedan componerse y reutilizarse entre plantillas. (#2612)
• Clonar grupos de variables — agregar una acción de clonación para que los entornos que difieren solo en unos pocos valores puedan configurarse sin recrear todos los campos desde cero. (#3295)
• Conjuntos de variables de encuesta reutilizables — desacoplar las variables de encuesta de las plantillas de tarea en objetos asignables independientes, evitando la duplicación por plantilla. (#2212)
• Corregir serialización JSON de extra-vars — serializar extra-vars complejas como JSON correcto en lugar de cadenas de mapas de Go, corrigiendo fallos de jsondecode en Terraform/OpenTofu. (#3748, #1644, #2619)
• Corregir precedencia de variables de encuesta — resolver la sobrescritura silenciosa cuando el mismo nombre de variable existe tanto en extra-vars del entorno como en la encuesta; definir una precedencia clara o generar un error. (#3108)
• Corregir manejo de variables de encuesta vacías/opcionales — asegurar que las variables de encuesta opcionales se omitan consistentemente o se pasen como cadenas vacías, no mezcladas aleatoriamente. (#2182)
• Valores predeterminados de encuesta para tareas programadas — permitir especificar valores predeterminados para variables de encuesta al programar tareas, para que las ejecuciones automatizadas no fallen en los prompts requeridos. (#2244)
• Pasar variables de encuesta como variables de entorno para tareas bash — exponer las variables de encuesta como variables de entorno del SO en lugar de argumentos CLI para tareas de tipo shell. (#2433)
• Pasar variables de encuesta durante init de Tofu/Terraform — enviar las variables de encuesta a la fase init, no solo a plan/apply, para soportar configuraciones de backend basadas en variables. (#2554)
• Referencias Jinja2 en argumentos CLI adicionales — permitir referenciar variables de encuesta y entorno en el campo de argumentos CLI adicionales usando sintaxis de plantilla (por ejemplo, -l {{ hosts }}). (#1053)
• Variables de entorno en la preparación de ejecución — hacer que las variables de entorno estén disponibles durante la fase de preparación (por ejemplo, galaxy install, autenticación de roles Git) no solo durante la ejecución de la tarea. (#3178)
• Cargar extra-vars desde archivo del repositorio — soportar la carga de extra-vars desde un archivo JSON/YAML en el repositorio en lugar de en línea en la interfaz, habilitando flujos de trabajo GitOps. (#2343)
• Sobrescribir entorno en tiempo de ejecución vía API — permitir pasar un grupo de variables diferente al lanzar una tarea vía API. (#1367, #3291)

Pro #

• Tipos de variables de encuesta complejas — soportar variables de encuesta dinámicas de lista de objetos (por ejemplo, configuraciones de VLAN) pasadas como arrays JSON estructurados. (#3557)
• Sobrescrituras de variables por programación — adjuntar valores de variables personalizados a trabajos programados para que la misma plantilla pueda ejecutarse en diferentes programaciones con diferentes parámetros. (#2378)
• Valores de variables dinámicos desde contexto de usuario — auto-poblar variables con la identidad del usuario conectado (por ejemplo, {{ current_user }}). (#2524, #909)

Enterprise #

• Marcar variables como privadas — agregar una marca “privada” en las variables que evita que los valores aparezcan en logs de ejecución, historial de tareas y respuestas de API. (#2887)
• Restringir visibilidad de variables de entorno — limitar el contenido de los grupos de variables solo a roles de administrador, evitando la exposición de credenciales en plantillas de proyectos compartidos. (#1126)
• Instantáneas de variables a nivel de ejecución — capturar los valores de las variables en el momento de ejecución de la tarea para que las re-ejecuciones usen los valores originales, no los actuales. (#1097)

Secretos propiedad del usuario #

El almacén de claves de Semaphore actualmente se comparte entre todos los miembros del proyecto. Cualquier usuario con acceso al proyecto puede usar (y en algunos casos ver) todas las credenciales almacenadas. Esto genera preocupaciones de seguridad en entornos multiusuario donde los miembros del equipo deberían tener acceso solo a sus propias credenciales. Además, el almacén de claves tiene múltiples errores relacionados con el cifrado, la actualización de secretos y la integridad referencial, y carece de integración con sistemas externos de gestión de secretos.

Community #

• Almacén de claves personal — proporcionar un almacén de claves por usuario para que las credenciales personales (claves SSH, contraseñas sudo) estén aisladas de otros miembros del proyecto y no se compartan a través del almacén de claves a nivel de proyecto. (#1483, #1373)
• Corregir comportamiento de actualización de secretos — resolver el problema donde editar una variable de entorno secreta parece tener éxito pero el valor en realidad no se persiste. (#2546)
• Ocultar secretos de la lista de procesos — dejar de pasar extra-vars secretas mediante argumentos de línea de comandos visibles en la lista de procesos del SO; usar un mecanismo seguro (por ejemplo, archivos temporales, stdin). (#3219)
• Soporte de certificados SSH en el almacén de claves — permitir almacenar certificados SSH junto con claves SSH para flujos de trabajo de autenticación basados en certificados. (#3171)
• Mostrar clave pública SSH — mostrar la porción de clave pública de las claves SSH almacenadas en la interfaz del almacén de claves por conveniencia. (#1643)
• Soporte de secretos Docker — soportar el patrón de variable de entorno _FILE (por ejemplo, POSTGRES_PASSWORD_FILE) para que los secretos de Docker/Kubernetes puedan montarse y leerse en lugar de pasarse mediante variables de entorno. (#1268)
• Corregir manejo de clave de cifrado en Docker — asegurar que la variable de entorno SEMAPHORE_ACCESS_KEY_ENCRYPTION se respete y no se sobrescriba con una clave aleatoria al reiniciar el contenedor. (#2228, #3068, #3204)
• Corregir que renombrar entradas del almacén de claves rompe referencias — resolver el problema donde renombrar una entrada del almacén de claves rompe todos los inventarios y plantillas vinculados. (#3188)
• Corregir API de contraseña de Vault — permitir establecer y actualizar contraseñas de Ansible Vault vía API REST sin errores de restricción de clave duplicada. (#3413, #2773)

Pro #

• Integración con almacén de secretos externo — obtener secretos en tiempo de ejecución desde HashiCorp Vault, Azure Key Vault, AWS KMS o Bitwarden en lugar de almacenarlos en la base de datos de Semaphore. (#2248, #658)

Enterprise #

• Claves de acceso globales — compartir entradas del almacén de claves entre proyectos sin duplicación, con gestión centralizada y vinculación entre proyectos. (#110)
• Registro de auditoría de acceso a secretos — registrar todo acceso y uso de las entradas del almacén de claves y variables secretas para cumplimiento y análisis forense.

Flujos de Trabajo #

Semaphore actualmente trata cada plantilla de tarea como una unidad independiente — no existe una forma integrada de encadenar múltiples plantillas en un pipeline de ejecución de varios pasos. Esta función introduce los Flujos de Trabajo — grafos acíclicos dirigidos (DAGs) de plantillas de tareas que se ejecutan con ramificación condicional, paso de variables entre pasos y puertas de aprobación humana opcionales. El diseño se inspira en los AWX Workflow Job Templates, los flujos de trabajo de Rundeck y los conceptos de pipelines de Jenkins/GitLab CI.

Community #

• Plantillas de flujo de trabajo — introducir una nueva entidad de nivel superior que define un DAG de nodos de plantillas de tareas conectados por aristas dirigidas con condiciones (on_success, on_failure, always), permitiendo pipelines de automatización de varios pasos dentro de un proyecto. (#3182, #2334, #1383, #836)
• Motor de ejecución de flujos de trabajo — ejecutar nodos del flujo de trabajo en orden topológico, respetando las condiciones de las aristas y ejecutando ramas independientes en paralelo, con convergencia ALL para nodos que tienen múltiples padres. (#2281, #3088)
• Panel de ejecución de flujos de trabajo — proporcionar una vista unificada de la ejecución del flujo de trabajo mostrando el grafo DAG con estado por nodo (pendiente, en ejecución, exitoso, fallido, omitido), logs de nodos clicables y tiempos generales.
• Paso de variables entre nodos — permitir que las plantillas de tareas emitan variables de salida (a través de un archivo conocido o Ansible set_stats) que se inyectan automáticamente como variables extra en los nodos posteriores. (#3182)
• Programación de flujos de trabajo y disparadores API — soporte para programación cron, ejecuciones activadas por API y disparadores webhook para flujos de trabajo, con variables de encuesta opcionales a nivel de flujo de trabajo. (#3088)

Pro #

• Editor visual de flujos de trabajo — editor gráfico de arrastrar y soltar para diseñar flujos de trabajo en la interfaz, con validación DAG en tiempo real, posicionamiento de nodos y selectores de condiciones en las aristas.
• Sobrescrituras por nodo — sobrescribir el inventario, credenciales, grupos de variables o argumentos CLI de una plantilla a nivel de nodo del flujo de trabajo, permitiendo reutilizar la misma plantilla en diferentes entornos dentro de un solo flujo de trabajo.
• Puertas de aprobación — pausar la ejecución del flujo de trabajo en puntos designados para esperar la aprobación humana, con tiempos límite configurables, notificación a los aprobadores y acciones de aprobar/rechazar desde la interfaz o API.

Enterprise #

• RBAC de flujos de trabajo — permisos granulares para crear, editar, ejecutar y aprobar flujos de trabajo, con asignación de puertas de aprobación basada en roles y registro de auditoría.
• Flujos de trabajo entre proyectos — referenciar plantillas de tareas de otros proyectos en un flujo de trabajo, permitiendo pipelines de automatización a nivel organizacional que abarquen proyectos de infraestructura, aplicación y monitoreo.
• Versionado de flujos de trabajo y rollback — mantener un historial de versiones de las definiciones de flujos de trabajo con diffs, restaurar versiones anteriores y registrar qué versión se usó para cada ejecución.