4nk/ia_dev
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ia_dev/.cursor/agents/deploy-by-script.md
Nicolas Cantu 2363c6e4b7 full exec
2026-03-17 14:37:53 +01:00

7.3 KiB
Raw Blame History

name description model is_background
deploy-by-script Lance le déploiement scripts_v2 sur l'environnement courant (branche locale) avec import-v1 et skipSetupHost, après vérification du suivi des branches, sortie vers un log daté. inherit false

Déploiement par script (deploy-by-script)

Règle d'exécution intégrale (obligatoire, non négociable)

  • Tout dérouler : exécuter toutes les étapes décrites dans cet agent dans l'ordre, sans en omettre aucune. Tout doit se dérouler effectivement.
  • Sans priorisation : aucune étape n'est optionnelle ou "secondaire" ; chacune est obligatoire.
  • Sans jugement d'intérêt : ne jamais juger de la pertinence d'une étape pour la sauter ; tout appliquer tel que décrit, sans exception.
  • Vérification en fin d'agent : avant clôture, cocher explicitement chaque étape (réalisée / non réalisée).

Contexte projet : La configuration et la documentation du projet sont dans projects/<id>/. L'identifiant <id> est résolu par paramètre (optionnel en premier argument des scripts), MAIL_TO ou AI_AGENT_TOKEN. Voir projects/README.md. Rappeler ce chemin en début d'exécution.

Documentation : La doc des projets gérés est dans projects/<id>/docs ; la doc ia_dev est dans projects/ia_dev/docs.

Cet agent lance le déploiement pour l'environnement courant (nom de la branche locale) via le script scripts_v2. Rôle de l'agent : vérifier le contexte (branche = env cible), lancer le script, contrôler la sortie et le code de retour, synthèse et clôture. Rôle du script : exécution et orchestration sûre (suivi branches, sync, log, déploiement).

Focus qualité et résolution de problèmes :

  • Qualité : Vérifier que la branche courante correspond à l'environnement cible avant de lancer le script. Ne pas déployer depuis un état non poussé ou non aligné sans l'avoir vérifié.

  • Résolution de problèmes : Si le script sort en erreur, analyser la sortie (et le fichier log dans logs/ si présent) pour identifier la cause (git, SSH, déploiement, migrations, build, lint, TypeScript) ; appliquer la correction puis relancer le script (boucle corriger → pousser → relancer). Ne s'arrêter que si la correction n'est pas possible sans instruction utilisateur.

  • Boucle corriger-et-retenter (obligatoire) : En cas de code de sortie non nul, 1) identifier la cause dans la sortie et/ou logs/deploy_*.log ; 2) appliquer la correction dans le code du projet cible ; 3) committer et pousser via push-by-script si des fichiers ont été modifiés ; 4) relancer le script de déploiement. Répéter jusqu'à succès ou blocage nécessitant instruction utilisateur. Ne pas se contenter de rapporter l'échec sans corriger et retenter.

  • Logs et corrections : Toujours consulter la sortie du script et le fichier logs/deploy_*.log après exécution. En cas d'échec, utiliser ces logs pour identifier la cause, appliquer les corrections (code, config, doc, scripts), committer et pousser les changements via push-by-script si des fichiers ont été modifiés, puis relancer le script de déploiement jusqu'à succès ou blocage nécessitant instruction utilisateur.

Horodatage et contexte : appliquer intégralement le bloc défini dans .cursor/rules/cloture-evolution.mdc (début et fin d'exécution, lancement et retour des sub-agents).

Avant d'exécuter un script du projet :

  1. Lire le fichier du script avec l'outil de lecture (ex. deploy/scripts_v2/deploy.sh).
  2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
  3. Lancer le script uniquement après cette présentation.

Contexte (standalone) : Le déploiement est exécuté depuis ia_dev. Les chemins du projet cible (scripts, secrets) viennent de projects/<id>/conf.json (absolus). Pour déployer la prod, le projet cible doit être sur la branche prod à jour avec origin/prod (ex. après un branch-align depuis test).

1. Commande à exécuter

Le script applique par défaut une exécution standardisée : sync avec origin (--sync-origin) et log dans logs/ (--log-to-dir logs). Options --no-sync-origin et --no-log pour désactiver.

Exécuter depuis la racine de ia_dev. Le script deploy utilise les chemins absolus de projects/<id>/conf.json (deploy.deploy_script_path, deploy.secrets_path). Pour cibler un projet explicitement : passer l’id en premier argument, ex. ./deploy/deploy-by-script-to.sh lecoffreio prod (ou utiliser MAIL_TO / AI_AGENT_TOKEN). L’agent peut invoker le script de déploiement du projet concerné via ces chemins.

Le script fait alors automatiquement : suivi des branches origin, sync de la branche courante avec origin, tee vers logs/deploy_YYYYMMDD_HHMMSS.log, puis déploiement.

Pas de timeout : Ne pas lancer la commande de déploiement avec un timeout court (ex. 5 min). Le déploiement (build, migrations, import-v1, services, vérifications) peut durer 10 à 30 min ; utiliser un timeout long ou aucun timeout pour laisser le script aller au bout.

2. Contrôle et résolution de problèmes

  • Vérifier que le script a bien été invoqué (branche courante = environnement cible). En cas de code de sortie non nul, consulter la sortie et le log (logs/deploy_*.log), identifier la cause, appliquer les corrections nécessaires, committer et pousser via push-by-script si des fichiers ont été modifiés, puis relancer immédiatement le script. Répéter jusqu'à succès. Ne pas relancer sans avoir corrigé uniquement si la correction n'est pas possible sans instruction utilisateur.

3. Après l'exécution

  • Si le script sort avec 0 : rapporter le succès.
  • Si le script sort avec un code non nul : consulter les logs (sortie + logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si nécessaire, puis relancer. Rapporter la cause identifiée et la résolution ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite.

Clôture complète obligatoire (tous les cas, sans exception)

En fin d'exécution de cet agent, toujours appliquer intégralement .cursor/rules/cloture-evolution.mdc : points 1 à 19. Toutes les étapes (agent + clôture) doivent être réellement passées, sans jugement de pertinence ; tout doit se dérouler. (horodatage, 5 sub-agents par projet, questions 3-13, docupdate, reste à faire, push-by-script si pas déjà fait, affichage du texte du commit). Aucune exception : même si le script a échoué ou si l'agent n'a pas modifié de code, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.

Exhaustivité obligatoire de la clôture : Traiter tous les points 1 à 16 (ou 19) sans en omettre. Point 1 : horodatage début/fin et par sub-agent. Point 2 : un sub-agent ou une passée de checklist par périmètre (global/commun, frontend, backend, ressources partagées, scripts shell) avec réponses aux points 3-11. Points 3-11 : indiquer « Réalisées » et « Non réalisées encore » pour chaque point. Points 12-14 : reste à faire, réaliser non réalisé, réaliser reste à faire. Point 15 : /push-by-script si pas déjà fait. Point 16 : afficher le texte du commit. Si un point est non applicable, le mentionner explicitement.