Livraison

Cet écran, intitulé Planification de la livraison, livre une nouvelle version : celle d'un module (conseillé), ou celle du projet entier. Vous choisissez ce qui se livre, le plan se calcule tout de suite, puis vous l'exécutez après un récapitulatif.

Ce que vous voyez

• Que livrer ? En premier, sous Modules — conseillé, les modules du projet avec leur version. En dessous, Projet entier. Le premier module est choisi d'office.
• Type d'incrément : Patch, Mineur ou Majeur.
• Le plan de la cible choisie :
  • la version courante et la version cible, par exemple 1.4.0 → 1.4.1 ;
  • le Tag qui sera posé, le Dernier tag, le Dépôt (dépôt propre du module, ou dépôt du projet), le Dépôt de release, la Branche et les Fichiers de version ;
  • À savoir : ce qu'il faut savoir avant d'exécuter, par exemple une version cible en retard sur le dernier tag ;
  • les Étapes du plan, chacune avec sa case à cocher.
• Configuration de livraison (plus bas) : la commande de build et les artefacts de chaque module.

Ce que vous pouvez faire

Choisir ce qui se livre

Cliquez sur un module, ou sur Projet entier. Le plan se recalcule aussitôt, sans rien écrire.

Ce qui change selon la cible :

Cible	Version lue dans	Tag posé	Git agit dans
Module à dépôt propre	ses fichiers (package.json, Cargo.toml…)	v1.4.1	son dépôt
Module dans le dépôt du projet	ses fichiers	site-v1.4.1	le dépôt du projet, borné au chemin du module
Projet entier	effortless.json et les fichiers de version déclarés	v0.2.0	le dépôt du projet

Les fichiers de version d'un module sont détectés. Pour en imposer d'autres, déclarez-les dans stacks[].release.version_files de effortless.json.

Choisir les étapes

Cochez les étapes à jouer : Incrémenter la version, Commit et push, Tag et release GitHub, Mettre à jour la documentation, Build et envoi des artefacts. Une étape qui ne s'applique pas à la cible est grisée. Vos coches sont mémorisées pour ce projet ; sans aucune coche, l'écran demande « Cochez au moins une étape. »

Exécuter

1. Cliquez sur Exécuter…. Un panneau récapitule la cible, la version, le tag, le dépôt et les étapes.
2. Lisez-le : ces actions sont réelles (écriture des fichiers de version, commit, push, tag, release GitHub, build) et ne s'annulent pas d'un clic.
3. Cliquez sur Confirmer et exécuter.

Le résultat s'affiche étape par étape : fait, à faire à la main (le moteur n'a pas pu agir et dit pourquoi, par exemple sans gh), échec, ou non jouée (une étape précédente a échoué : la chaîne s'arrête).

En mode de travail semi-auto, l'exécution est refusée et le panneau le dit.

Un tag n'est jamais posé sur des fichiers non commités : sans Commit et push, la nouvelle version ne serait pas dans le commit tagué. L'étape échoue alors et le dit.

Livrer en interne ou en public

Sous la cible, choisissez le Canal :

• Interne : la livraison décrite plus haut. La release et ses artefacts vont au Dépôt de release interne (par défaut, le dépôt d'origine du code).
• Public : on publie une version déjà livrée en interne, telle quelle — même tag, mêmes artefacts, sans nouveau bump. L'écran ne propose que les versions livrées en interne et pas encore publiques. Si aucun dépôt public n'est déclaré pour la cible, il le dit et renvoie à la configuration plus bas.

Pour publier :

1. Cliquez sur Publier… à côté de la version.
2. Le panneau rappelle le tag, le dépôt d'où elle vient et celui où elle va. La publication est publique et irréversible.
3. Tapez le tag dans le champ Tapez … pour confirmer : le bouton Publier ne s'active qu'à ce moment.

Le moteur refuse, en le disant, si la release n'existe pas sur le canal interne, si elle est déjà publique, ou en mode semi-auto.

Configurer la livraison

1. Cliquez sur un module dans Stacks configurés pour préremplir le formulaire, ou renseignez son nom dans Stack.
2. Indiquez la Commande de build, par exemple pnpm build. Pour un module, elle se joue dans son répertoire.
3. Listez les Artefacts, par exemple dist/*.zip. Laisser ce champ vide conserve ceux déjà enregistrés.
4. Cliquez sur Enregistrer la livraison.

Plus bas, Canaux de livraison règle les deux dépôts de release de la cible : Dépôt de release interne (owner/nom ; vide = le dépôt d'origine) et Dépôt de release public (owner/nom ; vide = pas de livraison publique). Cliquez sur Enregistrer les canaux.

Relire l'historique

Historique des livraisons, en bas de l'écran, liste chaque livraison exécutée, avec ses colonnes Date, Canal (interne ou public), Cible, Tag (lien vers la release quand il existe), Dépôt et Issue (livrée ou arrêtée). Il vit dans .effortless/deliveries.json, versionné avec le projet.

Avec un agent IA

Un agent fait la même chose par effortless_release_plan (le plan) et effortless_release_apply (l'exécution, après votre accord). Les deux prennent stack pour viser un module. Il configure la livraison par effortless_release_delivery_set et les canaux par effortless_release_channels_set. Il publie par effortless_release_promote, qui exige de redonner le tag dans confirm — après votre accord explicite. Il lit l'historique par effortless_deliveries.