Introduction

Partie 11

De la séquence au flux de travail : laisser `.lil` prendre des décisions

Un script linéaire suffit tant que la réponse reste « faire A, puis B, puis C ». Dès qu’il faut vérifier un répertoire, réutiliser un chemin, conserver un résultat ou s’arrêter avec une raison claire, vous construisez un flux de travail plutôt qu’une simple liste.

Utiliser le plus petit langage d’automatisation adapté à la tâche

Un fichier commençant par #lil appartient au exécution linéaire du Core : les commandes ordinaires s’exécutent dans l’ordre, et cette simplicité est un avantage. Il convient très bien aux listes d’installation, diagnostics répétables et procédures courtes.

run est la couche suivante. Il ajoute variables, conditions, résultat capturé, scripts imbriqués et politique d’échec explicite. Ne transformez pas chaque recette de trois lignes en programme ; passez à run quand le flux de travail a réellement besoin d’état ou de décisions.

install run
help run

Les variables transforment des chemins copiés en intentions nommées

set root lil-playground donne un rôle à un chemin. Ensuite $root, $source et $archive disent ce que les valeurs signifient au lieu de forcer à modifier le même littéral à cinq endroits.

De bons noms rendent un script portable. Gardez les valeurs spécifiques à l’environnement en haut, les secrets à l’extérieur, et préférez quelques variables claires à une construction de chaînes ingénieuse.

Commencez le fichier ainsi
set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip

Une condition doit protéger une hypothèse

if dir "$source" n’est pas décoratif : le test empêche l’étape d’archivage de travailler silencieusement sur la mauvaise cible. Les conditions sont surtout utiles autour d’hypothèses dont l’échec deviendrait destructeur ou déroutant.

run comprend exists, file, dir, empty, eq, ne, ok, fail et command, avec not pour inverser. Gardez les branches assez courtes pour qu’un lecteur comprenne toujours pourquoi chaque chemin existe.

Commencez le fichier ainsi
if dir "$source"
    stat "$source"
else
    stop "Project directory is missing"
end

Capturez la sortie lorsque la décision suivante en dépend

capture name <command> exécute une commande lil ordinaire et stocke son résultat texte dans une variable. Les built-ins $last, $status, $cwd et $line exposent l’état courant utile.

Ne capturez pas tout simplement parce que c’est possible. Le texte terminal est utile s’il est petit et stable ; des fichiers structurés ou commandes de format dédiées sont préférables lorsque les données doivent survivre entre outils ou dans le temps.

Commencez le fichier ainsi
capture current pwd -s
if empty "$current"
    stop "Current directory is unavailable"
end

Décider ce qu’un échec signifie avant d’automatiser

Par défaut, run s’arrête au premier échec : une commande en erreur arrête le flux de travail. -k continue après les erreurs et ne convient qu’aux tâches dont les étapes indépendantes peuvent réellement se poursuivre sans risque. stop permet de terminer avec une raison compréhensible.

Exécutez les flux de travail inconnus avec -n d’abord. Le exécution à blanc valide et développe les commandes sans les exécuter ; -v montre ensuite l’résultat complet d’un vrai lancement. La prelecture n’est pas de la bureaucratie : elle garde l’automatisation lisible.

run workflow.lil -n
run workflow.lil -v

Découper les gros flux de travail par responsabilité, pas par nombre de lignes

Un flux de travail peut appeler run child.lil dans le même contexte de variables ; les routines de sauvegarde, validation ou déploiement peuvent donc rester séparées et réutilisables. Gardez l’imbrication peu profonde et donnez une responsabilité à chaque fichier.

run -p crée une représentation compressée protégée par checksum pour le transport. Un .lil packed n’est pas du chiffrement : il protège format et intégrité contre les modifications accidentelles, pas la confidentialité ni l’auteur.

run -p workflow.lil workflow.packed.lil
run workflow.packed.lil

L’automatisation a volontairement moins de privilèges qu’un humain interactif

Les commandes UI interactives sont bloquées dans les flux de travail ordinaires et les commandes non interactives privilégiées comme php et ses exigent explicitement -x. L’auto-install interactif via @command est également refusé dans les scripts run.

Cette friction est intentionnelle. Un flux de travail reproductible doit déclarer ses dépendances de modules avant l’exécution et ne doit pas installer du code, demander un secret ou détruire le terminal de manière inattendue au milieu du run.

Conservez ceci comme script

Enregistrez ceci sous workflow.lil, créez lil-playground/project si vous voulez tester la branche de succès et lancez d’abord run workflow.lil -n. Le changement essentiel est visible : le script vérifie ses hypothèses avant de créer l’archive.

set root lil-playground
set source lil-playground/project
set archive lil-playground/project.zip

if not dir "$root"
    stop "lil-playground is missing"
end

if dir "$source"
    capture current pwd -s
    zip "$source" "$archive" -f
    stat "$archive"
else
    stop "Project directory is missing"
end

Référence des commandes