Auton 1.2.0

Exécutez des commandes via HTTP avec un client et un daemon légers, en conservant des preuves claires lorsqu’une opération multi-cibles réussit, échoue ou perd son observation.

Changements

  • Réconcilier les rapports JSON exportés sans soumettre à nouveau de tâches ; observer chaque origine de basculement explicitement sélectionnée avec des détails liés à leur source.

  • Guider les arguments Web/TUI à partir de schémas optionnels des points d’entrée, validés côté serveur.

  • Demander l’annulation d’un sous-processus, autorisée par son propriétaire, depuis la CLI ou la console Web ; arrêter l’observation reste une action distincte.

  • Laisser des workers Unix explicitement détachés terminer les scénarios après fermeture de la CLI, avec des rapports privés durables et sans rejeu automatique après plantage du worker ou de l’hôte.

  • Poursuivre un scénario après un échec confirmé uniquement avec continue_on_error.

  • Persister facultativement l’historique dans Redis via l’adaptateur existant de DWho, avec propriété de l’espace et écritures protégées. L’authentification SQLite reste séparée.

  • Ajouter le TLS mutuel optionnel et le SSO OIDC/PKCE du navigateur, associés à des comptes locaux existants.

  • Prendre en charge Python 3.10 à 3.13, faire expirer périodiquement les résultats pendant l’inactivité et vérifier des wheels reproductibles dans le même environnement de construction.

Installation et migration

python -m pip install --upgrade auton==1.2.0
python -m pip install --upgrade 'autond[auth]==1.2.0'

Extensions optionnelles du daemon : autond[auth,oidc,redis]==1.2.0. L’image decryptus/auton:1.2.0 les inclut. Les fonctions restent à activer explicitement. Les commandes CLI existantes restent non interactives sauf avec --tui.

Les jetons existants n’obtiennent pas le droit d’annulation : accordez explicitement cancel. Les schémas de paramètres restreignent volontairement les arguments acceptés. Redis n’importe pas automatiquement l’historique SQLite. Conservez des sauvegardes et choisissez un espace explicite lors d’un changement de stockage.

OIDC utilise des clés publiques RSA gérées par l’opérateur et des correspondances explicites des sujets. Les sessions restent en mémoire et se terminent au redémarrage ; aucune création automatique de compte, aucun renouvellement par refresh token ni SSO CLI n’est prévu. La rotation des certificats/clés exige un redémarrage.

Les workers détachés dépendent toujours de leur hôte de contrôle. Le verrouillage Redis protège les écritures d’historique, pas la durée de vie des processus externes. Les tests couvrent les parcours normaux et les échecs ; ils n’établissent ni capacité de saturation ni absence de fuite.

Consultez la documentation et le compte rendu de validation.