Présentation de Loopt

Loopt est un utilitaire en ligne de commande qui transforme du code source écrit en TypeScript, Python, Go ou Rust en fichiers YAML compatibles avec le répertoire .github/workflows de GitHub. Les quatre langages cités sont fournis en tant que « first‑party », tandis que d’autres langages peuvent être intégrés via un protocole de plugin déclaré par l’utilisateur. Le projet propose également une fonction d’importation qui convertit un workflow YAML existant en code source éditable, conservant ainsi la trace bidirectionnelle entre le code et le fichier généré.

Architecture et flux de génération

Le processus repose sur trois commandes principales : loopt init, loopt import et loopt gen. loopt init crée un squelette de workflow dans le répertoire .loopt/workflows en fonction du langage choisi (par défaut TypeScript) et génère immédiatement le fichier .github/workflows/ci.yml. Le script d’installation, exécuté via curl -fsSL https://raw.githubusercontent.com/preloopdev/loopt/main/install.sh | sh, télécharge des binaires pré‑compilés pour macOS arm64 et Linux x86_64, vérifie le checksum de la version publiée et place l’exécutable dans ~/.local/bin. Les variables d’environnement LOOPT_INSTALL_DIR et LOOPT_VERSION permettent de rediriger le répertoire d’installation ou de figer une version précise.

Lors de la génération, Loopt exige que le langage d’auteur soit présent sur la machine : Node.js ≥ 26 pour TypeScript, Python 3, Go ou Cargo/Rust. La commande loopt gen lit les fichiers source, applique les règles de synchronisation YAML↔code et écrit les fichiers .yml. Si le YAML généré diffère du fichier déjà versionné, l’option --check provoque un échec, garantissant la cohérence du dépôt. En l’absence du drapeau --force, loopt gen refuse d’écraser un workflow modifié hors de Loopt, préservant les changements manuels.

# Generated by loopt. Edit the source under .loopt/workflows and run loopt gen.

Sécurité et vérifications intégrées

Loopt inclut une commande loopt lint qui exécute des contrôles de conformité et de sécurité sur les workflows produits. Les vérifications natives portent sur la structure du YAML, la présence de jetons en lecture seule et la suppression des exécutions supersédées. Un flag supplémentaire --shellcheck active l’analyse statique des scripts shell déclarés dans les étapes run. Le même moteur de lint est invoqué automatiquement par loopt gen, assurant que chaque génération passe par le même processus de revue.

Les actions composites, définies par des fichiers action.yml ou action.yaml hors du répertoire .github/workflows, sont importées de la même façon que les workflows standards, ce qui maintient une politique de vérification homogène pour les métadonnées d’action.

Limites et perspectives

Le modèle actuel repose sur la disponibilité locale des interprètes ou compilateurs des langages supportés. Aucun mécanisme de cache de dépendances n’est décrit, ce qui peut allonger le temps de génération sur des environnements CI dépourvus de ces outils. De plus, la prise en charge de langages personnalisés dépend d’une implémentation de plugin externe, sans indication de standardisation ou de compatibilité ascendante. Enfin, la documentation mentionne un corpus de tests externes activable via PRELOOP_FIXTURES, mais ne précise pas la couverture fonctionnelle, laissant une marge d’incertitude quant à la robustesse du système face à des workflows complexes.