Mettre à jour un script

Trouver ce qui est obsolèteCopy Anchor Link

L’avertissement de la console ne couvre que les scripts démarrés et non ignorés, donc vérifiez chaque dossier :

cd "resources/[ai]"
for n in ai-*; do
  repo=$(sed -n 's#.*"repository": *"\(github:\|https://github.com/\)\([^"]*\)".*#\2#p' "$n/package.json" | sed 's#\.git$##')
  cur=$(sed -n 's#^  "version": *"\([^"]*\)".*#\1#p' "$n/package.json")
  latest=$(gh release view --repo "$repo" --json tagName --jq .tagName 2>/dev/null | sed 's#^v##')
  echo "$n $cur ${latest:-no-release}"
done

• Comparez les versions comme ai-core : retirez un v initial, comparez les nombres séparés par des points, ignorez les suffixes de pré-version. Pas de release veut dire rien à mettre à jour.
• Sans gh : curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (60 requêtes par heure et par IP, partagées avec la vérification d’ai-core).
• Un script dans updates.ignore n’est mis à jour que si le propriétaire le nomme.
• Un dossier dont la version dépasse la dernière release, ou un clone avec des commits après le dernier tag, n’est pas obsolète : passez-le, ne faites jamais reculer un dossier.
• packages/ n’a pas de ligne repository : comparez la version de chaque package.json avec npm. Mettez d’abord les packages à jour quand une nouvelle release de script demande une version que les copies locales n’ont pas.

Lire les notes de version et obtenir l’accordCopy Anchor Link

Lisez les notes de chaque version entre l’actuelle et la dernière (gh release view <tag> --repo <repo> --json body,assets,url) : changements incompatibles, versions de packages requises, migrations, nouvelles lignes cfg (ensure, add_convar_permission, ACE), nouveaux noms provide, étapes manuelles.

Montrez la liste au propriétaire et attendez son accord. Mettez à jour dans l’ordre des dépendances : packages, ai-mysql, ai-core, ai-lib, puis le reste.

Télécharger l’ancien et le nouvel upstreamCopy Anchor Link

Pour chaque script, deux nouveaux dossiers vides hors du serveur (par exemple update/<name>/old et update/<name>/new) :

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # source du tag
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # un asset de release, s'il y en a un
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Préférez un asset de release quand la release en a un ; sinon la source du tag (elle contient le dist/ et le fxmanifest.lua committés). Le dossier racine du zip source est <owner>-<name>-<sha>/.
• L’ancien upstream est le tag de la version que le serveur utilise (le style des tags se voit avec gh release list --repo <owner>/<name>). Il est toujours téléchargeable, donc la comparaison à trois voies a toujours sa base.
• Rien dans ces dossiers n’est lancé, installé ou buildé.

SauvegarderCopy Anchor Link

• Copiez tout le dossier du script sauf node_modules dans update/<name>/ours (sous Windows robocopy "<src>" "<dst>" /E /XD node_modules ; les codes de sortie de robocopy inférieurs à 8 signifient la réussite). C’est « le nôtre » pour la fusion et le chemin du retour.
• Les fichiers ignorés par git n’existent que dans cette copie : data/secrets.json, data/*.json.bak. Dans un clone git, git ls-files --others --ignored --exclude-standard les liste.
• Les modifications non committées d’un clone (git status --porcelain) sont aussi des modifications du serveur. Prévenez le propriétaire ; ne les committez que s’il le demande.

Fusionner, fichier par fichierCopy Anchor Link

Appliquez le modèle à trois voies à l’ancien, au nôtre et au nouveau, et écrivez le résultat dans le dossier du script :

Le contenu du panneau (data/*.json) est le contenu vivant du serveur, modifié dans le panneau ; la release ne livre que des valeurs par défaut.

• Même schéma (le nouveau schema.ts ou loader lit les mêmes champs) : gardez le nôtre tel quel. Un fichier que la nouvelle version ajoute : prenez celui livré.
• Schéma modifié : cherchez la migration propre au script, lancée au démarrage (notes de version, une migration appelée au démarrage). S’il y en a une, laissez le nôtre en place ; elle le convertit au démarrage. Sinon, convertissez à la main en suivant le nouveau loader et le schéma : mêmes noms de champs, types et format d’id que le fichier livré, chaque valeur gardée, nouveaux champs à la valeur livrée par défaut, champs supprimés retirés et signalés. Vérifiez que chaque fichier se parse.

Base de données. Chaque script crée ses tables depuis sql/main.sql au démarrage : il crée les tables manquantes et ajoute les colonnes manquantes, et ne supprime, ne renomme, ne modifie jamais une colonne et n’ajoute jamais de clé. Comparez l’ancien et le nouveau sql/main.sql :

• Nouvelles tables et colonnes : le redémarrage les applique.
• Un type de colonne modifié, un nouvel index ou une nouvelle clé, une colonne renommée ou supprimée : la release doit apporter sa propre migration (notes de version, code serveur), qui tourne au démarrage ; vérifiez le log. Sinon, écrivez le SQL, montrez-le au propriétaire, sauvegardez les tables concernées et ne le lancez qu’avec son accord.

Fichiers cfg hors du dossier.

• server.cfg : un nouveau script reçoit sa ligne ensure dans l’ordre des dépendances ; un script retiré la perd (demandez d’abord).
• env.cfg et env.example.cfg : un script qui commence à utiliser la base de données a besoin de add_convar_permission <resource> read mysql_connection_string.
• permission.cfg : les lignes ACE que demandent les notes de version.
• security.cfg : jamais assoupli.

Builder, redémarrer, vérifierCopy Anchor Link

1. bun install à la racine du serveur quand un package.json a changé.

2. Dans chaque script mis à jour : bun run typecheck, bun run lint, bun run build (ou bun tools/run.ts build ai-x ai-y depuis la racine du serveur). Buildez toujours : dist/ doit venir de la source fusionnée. Corrigez les erreurs dans les modifications reportées du serveur ; une erreur dans du code upstream non touché est signalée, pas corrigée.

3. Comparez le résultat avec le nouvel upstream : diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Chaque différence restante doit être une modification du serveur.

4. Refresh et redémarrage :

   Copy Text

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # un seul script
   bun tools/restart.ts                       # après une mise à jour d'ai-core, ai-lib, ai-mysql ou des packages

   bun tools/restart.ts redémarre ai-core, lance ensure pour chaque ai-* qui suit et vérifie que chacun a démarré. Les scripts tiers qui dépendent d’ai-mysql s’arrêtent avec lui : relancez-les par leur nom avec ensure. Une nouvelle ligne provide demande un démarrage complet du serveur : bun tools/rcon.ts "quit \"<reason>\"".

5. Lisez le log de la console pour SCRIPT ERROR, Failed to load script, [client error], les erreurs de chargement ou de validation du panneau et les erreurs de base de données, pas seulement Started resource. L’avertissement is outdated doit avoir disparu après la vérification suivante du script.

Associer la livraison à ce qui est installéCopy Anchor Link

• Chaque dossier de premier niveau avec un fxmanifest.lua (ou __resource.lua) est une ressource ; un dossier [category] en contient plusieurs. Décompressez les zips dans un dossier neuf et vide et n’y lancez rien.
• Trouvez la copie installée par nom de dossier dans resources/ (par exemple find resources -maxdepth 3 -type d -name <name>). Gardez l’emplacement installé, pas la catégorie de la livraison. Aucune correspondance ou plusieurs : demandez au propriétaire. Un script pas encore installé n’est installé que si le propriétaire le dit.
• Un dossier ai-* dans la livraison ne suit pas cette procédure : les scripts ai-* se mettent à jour depuis GitHub (plus haut). Demandez au propriétaire ce qu’est ce dossier.
• Lisez les deux manifestes : version, files, scripts, dependencies, provide, escrow_ignore, ai_replaces. Une version qui baisse, ou une livraison à laquelle il manque des fichiers de la copie installée, peut être un build plus ancien : comparez et signalez au lieu d’installer.
• Nouvelles dépendances : oxmysql est servi par ai-mysql (n’installez jamais oxmysql à côté) ; ox_lib et les autres bibliothèques sont à installer par le propriétaire ; une dépendance à ce qu’ai-core remplace (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...) est déjà satisfaite.
• Montrez la liste associée (nom, chemin, version actuelle -> nouvelle) et attendez l’accord.

SauvegarderCopy Anchor Link

• Copiez tout le dossier installé dans un dossier de sauvegarde hors du serveur (robocopy "<src>" "<dst>" /E). Pour un dossier qu’aucun dépôt git ne suit, cette sauvegarde est la seule copie de la version du serveur.
• Si git suit le dossier : git status --porcelain -- <path> montre les modifications non committées (elles comptent comme le nôtre ; prévenez le propriétaire) et git ls-files --others --ignored --exclude-standard -- <path> montre les fichiers d’exécution ignorés par git (JSON enregistré, caches), qui sont dans la sauvegarde.

Trouver les modifications du serveurCopy Anchor Link

Obtenez l’ancien upstream, dans cet ordre :

1. Le propriétaire a encore l’ancien zip ou dossier de l’éditeur.
2. Un script open source sur GitHub : la release ou le tag de la version installée.
3. L’historique git, quand le dossier est suivi : le commit qui a posé la version installée (git log -S"version '<old>'" -- <path>/fxmanifest.lua). Si ce commit a aussi réappliqué des personnalisations antérieures, ses fichiers de config comptent comme le nôtre et la version d’origine pure se trouve un commit plus tôt.
4. Rien de tout cela : comparez le nôtre directement avec la nouvelle version, et dites-le dans le rapport.

Lisez ensuite chaque différence ancien -> nôtre (les modifications du serveur : configs, locales/* ou languages/*, fichiers editable, data/*.json, fxmanifest.lua, SQL, images, sons, fichiers streamés, correctifs de code) et ancien -> nouveau (les changements de l’éditeur : fichiers ajoutés et supprimés, clés renommées, sections déplacées, fonctions editable modifiées). Dans un script sous escrow (.fxap présent), seuls les fichiers de escrow_ignore se lisent et se modifient ; une modification dans un fichier que la nouvelle version met sous escrow ne peut pas être reportée et est signalée.

Installer la nouvelle versionCopy Anchor Link

Supprimez entièrement le dossier installé, puis copiez le nouveau dossier au même chemin, fichiers cachés (.fxap) compris. Les anciens restes sont des bugs ; l’ancienne version reste dans la sauvegarde. Ne restaurez les fichiers d’exécution sauvegardés que si la nouvelle version les utilise encore dans le même format ; sinon convertissez-les ou abandonnez-les, et signalez-le.

Réappliquer les modifications du serveurCopy Anchor Link

Pour chaque modification, trouvez où ce réglage se trouve dans la nouvelle version et écrivez-y la valeur, au nouveau format :

• Même clé, même fichier : mettez la valeur dans le nouveau fichier ; gardez ses commentaires et sa mise en page.
• Clé renommée ou déplacée : trouvez la nouvelle clé en lisant le code qui l’utilise (cherchez l’ancien nom, son commentaire, sa valeur par défaut, sa clé de texte) et convertissez la valeur à la nouvelle forme.
• Config déplacée vers un fichier de données (JSON modifié par le panneau propre au script) : lisez le nouveau loader et le fichier livré, écrivez les anciennes valeurs dans exactement ce schéma (noms de champs, types, format d’id, indentation) et vérifiez qu’il se parse. Ne comptez pas sur un convertisseur que le script lancerait peut-être.
• Les fichiers de données existants du serveur : reportez-les, convertissez champ par champ si le schéma a changé, ne les remplacez jamais par l’exemple de l’éditeur.
• Option supprimée : plus aucun code ne la lit (une recherche le confirme) : retirez-la et signalez-la avec l’ancienne valeur.
• Fichiers editable (client/editable.lua, server/editable.lua...) : partez du nouveau fichier et réappliquez chaque corps de fonction modifié, adapté à une signature ou une valeur de retour qui a changé ; les nouvelles fonctions gardent leur version par défaut.
• Langues : gardez la formulation du serveur pour chaque clé qui existe encore ; ajoutez les nouvelles clés à chaque fichier de langue que le serveur utilise, traduites sur le ton des textes existants ; retirez les clés supprimées ; suivez les placeholders modifiés.
• fxmanifest : le nouveau, plus seulement les ajouts propres au serveur qui ont encore du sens. Ne changez jamais version.
• SQL (*.sql, dossiers d’installation) : comparez l’ancien et le nouveau ; les nouvelles tables, colonnes et index vont dans le rapport comme SQL que le propriétaire lance. Rien ne tourne sans son accord.
• Identifiants (tokens de bot, clés d’API, URL de webhooks dans les configs) : ne les affichez jamais. Reportez-les depuis la sauvegarde ; si ce n’est pas possible, laissez la nouvelle valeur par défaut et listez le fichier et la clé pour le propriétaire.
• Assets (stream/, images, sons) : ceux de l’éditeur, plus les fichiers ajoutés par le serveur qui servent encore.
• Coordonnées, items, prix, textes et comportement sont reportés à l’identique ; rien ne change en dehors des modifications propres au serveur.

Vérifier la compatibilité avec ai-coreCopy Anchor Link

Le script peut faire partie de ceux avec lesquels ai-core communique. Trouvez chaque endroit qui le nomme :

grep -rln "<name>" "resources/[ai]/ai-core/resource" "resources/[ai]/ai-core/bridge" docs/compat

• Pour chaque export, event et callback qu’un adapter utilise, vérifiez la nouvelle version : toujours là, mêmes arguments, même forme de retour, même timing. Dans du code sous escrow, vérifiez les fichiers lisibles et la documentation de l’éditeur, et listez ce qui ne peut pas être vérifié.
• Une incompatibilité se corrige uniquement dans le fichier de l’adapter (une traduction fine), avec sa version testée relevée ; puis typecheck, lint et build d’ai-core et redémarrage (bun tools/restart.ts).
• Une nouvelle ligne ai_replaces ou provide peut amener ai-core à refuser les connexions tant qu’un remplaçant ai-* tourne encore (voir Remplacer un script ai-*) : nommez le dossier que le propriétaire doit retirer.
• Mettez à jour docs/compat/<script>.md (version testée, statut, config ou correctif exact, limites connues) ; un script pris en charge sans note en reçoit une.

Vérifier et redémarrerCopy Anchor Link

• Comparez le résultat installé avec la nouvelle version : chaque différence est une modification du serveur, et aucun ancien fichier que la nouvelle version ne livre pas ne reste (fichiers d’exécution restaurés à part).
• Le Lua modifié se parse, le JSON se parse, chaque clé de config réglée existe dans le nouveau code.
• Sauf si du SQL attend le propriétaire : bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", puis la même chose avec "ensure <name>", et lisez le log pour SCRIPT ERROR, Failed to load script et les erreurs propres au script. Les scripts qui en dépendent et qui se sont arrêtés sont relancés.