VEAF Tools — Guide utilisateur et administrateur¶

Vue d'ensemble¶

Le cycle de vie des releases des VEAF Mission Creation Tools repose sur deux programmes en ligne de commande distincts :

veaf-tools-updater.exe — Pour les utilisateurs finaux : un outil de mise à jour uniquement qui télécharge et installe la dernière version depuis GitHub. Il n'a aucune sous-commande — il se lance directement.
veaf-build — Pour les administrateurs : l'outillage de build et de publication (livré sous forme de veaf-build.exe / poetry run veaf-build) qui compile les outils et publie les nouvelles versions sur GitHub via sa sous-commande publish.

Fichier de configuration (optionnel mais recommandé)¶

Vous pouvez stocker votre token GitHub et d'autres paramètres dans un fichier de configuration au lieu de les passer en arguments de ligne de commande.

Installation¶

Copier l'exemple de configuration :

copy veaf-tools-config.example.yaml veaf-tools-config.yaml

Éditer veaf-tools-config.yaml :

github:
  token: "ghp_votre_token_ici"
  owner: "VEAF"
  repo: "VEAF-Mission-Creation-Tools"

Garder le fichier sécurisé :
⚠️ Ne jamais commiter veaf-tools-config.yaml dans git
Il est déjà dans .gitignore (par défaut)
Le token est votre mot de passe — gardez-le secret !

Avantages¶

✅ Plus besoin de taper --token à chaque fois
✅ Lignes de commande plus propres
✅ Gestion centralisée des paramètres
✅ Moins de risque d'exposition du token dans l'historique du shell

Une fois configuré, tous les outils utiliseront automatiquement ces paramètres.

Interroger la documentation (assistant IA)¶

veaf-tools ask répond à vos questions sur la documentation VEAF via un assistant IA, en s'appuyant sur la documentation elle-même (RAG). C'est le même assistant que le chatbot du site de documentation.

Aucune configuration, aucune clé API. La commande envoie votre question au service de documentation VEAF, qui génère la réponse — pas besoin de clé Google/Gemini. (Des limites d'usage raisonnable s'appliquent par utilisateur.) Une connexion Internet est requise.

Utilisation¶

# Question unique
veaf-tools ask "Comment activer CTLD dans ma mission ?"

# Session interactive (tapez « quit » ou Ctrl-D pour quitter)
veaf-tools ask

# Réponse en anglais (par défaut suit --lang)
veaf-tools --lang en ask "How are radio presets injected?"

Disponible aussi depuis le TUI interactif via « Interroger la documentation ».

Pour les utilisateurs : Mise à jour¶

Mise à jour simple (recommandée)¶

Pour mettre à jour vos VEAF Tools à la dernière version :

.\veaf-tools-updater.exe

Cela va : 1. ✅ Vérifier quelle version est actuellement installée 2. ✅ Récupérer la dernière version depuis GitHub (tag published-latest) 3. ✅ Comparer les versions (ne met à jour que si la version est plus récente) 4. ✅ Télécharger published.zip depuis la Release GitHub 5. ✅ Vérifier le checksum SHA256 (garantit l'intégrité du fichier) 6. ✅ Extraire et installer dans votre dossier de mission 7. ✅ Déplacer les deux exécutables (veaf-tools.exe, veaf-tools-updater.exe) dans le répertoire courant

Résultat : Vos outils sont à jour avec vérification d'intégrité

Mise à jour vers une version spécifique¶

Si vous avez besoin d'une version précédente ou voulez être explicite :

.\veaf-tools-updater.exe --tag published-v6.0.0

Les tags de version disponibles apparaissent sur GitHub : - published-v6.0.1 — Version 6.0.1 - published-v6.0.0 — Version 6.0.0 - published-latest — Toujours la version courante (par défaut)

Forcer la mise à jour (ignorer la vérification de version)¶

Pour réinstaller la même version ou forcer la mise à jour :

.\veaf-tools-updater.exe --force

Cela ignore la vérification « est-ce plus récent ? » et installe quand même. Utile pour : - Réparer une installation corrompue - Réinstaller après des modifications manuelles - Tester des versions spécifiques

Mise à jour avec token GitHub (meilleures limites de débit)¶

Si vous atteignez les limites de débit de l'API GitHub (rare), vous pouvez fournir un Personal Access Token :

Option 1 : Utiliser le fichier de configuration (recommandé)

# Dans veaf-tools-config.yaml
github:
  token: "ghp_xxxxxxxxxxxx"

Puis exécuter :

.\veaf-tools-updater.exe

Option 2 : Ligne de commande (sans fichier de config)

.\veaf-tools-updater.exe --token ghp_xxxxxxxxxxxx

Avantages : - Augmente la limite de débit API : 60 → 5000 requêtes/heure - Recommandé pour les scripts automatisés - Optionnel mais utile dans certains scénarios

Obtenir un token : 1. Aller sur https://github.com/settings/tokens 2. Cliquer sur "Generate new token (classic)" 3. Sélectionner le scope : repo (contrôle total) 4. Copier le token (vous ne le reverrez plus !)

Ignorer la vérification de checksum (non recommandé)¶

.\veaf-tools-updater.exe --no-verify-checksum

⚠️ Non recommandé — Les checksums protègent contre : - La corruption réseau - La falsification de fichiers - Les téléchargements incomplets

À n'utiliser qu'en dernier recours.

Langue de l'interface¶

La langue des messages est détectée automatiquement — aucune configuration requise :

Option CLI --lang (priorité maximale)
Variable d'environnement VEAF_LANG
~/veafmct.yaml → clé lang:
Locale du système (registre Windows / locale système sur Linux et macOS)
en (repli intégré)

Pour forcer la langue sur une seule exécution :

.\veaf-tools-updater.exe --lang fr

Pour définir une préférence persistante :

.\veaf-tools.exe user-config --set lang=fr

Valeurs supportées : en, fr. Voir Configuration de la langue pour les détails complets.

Sortie verbeuse (débogage)¶

Pour un dépannage détaillé :

.\veaf-tools-updater.exe --verbose

Affiche : - Les étapes détaillées de l'opération - Les réponses de l'API - Les informations de débogage - Le contexte complet des erreurs

Toutes les options combinées¶

.\veaf-tools-updater.exe `
  --tag published-v6.0.1 `
  --token ghp_xxxxxxxxxxxx `
  --verbose `
  --force

Obtenir de l'aide¶

.\veaf-tools-updater.exe --help

Affiche toutes les options disponibles et leurs descriptions.

Pour les administrateurs : Publication¶

La publication se fait avec veaf-build (la CLI de build et de release), et non avec l'updater. Le flux habituel est veaf-build build (compiler et empaqueter) puis veaf-build publish (pousser le paquet sur GitHub), ou veaf-build build-and-publish pour enchaîner les deux en une seule commande.

Prérequis¶

Avant de publier, vous avez besoin de :

Un token GitHub pour que veaf-build publish puisse créer la release. Il est résolu dans cet ordre : l'option --token, puis github.token dans veaf-tools-config.yaml, puis la variable d'environnement GITHUB_TOKEN.

En utilisant le fichier de configuration (recommandé) :

copy veaf-tools-config.example.yaml veaf-tools-config.yaml

Éditez veaf-tools-config.yaml et ajoutez votre token :

github:
  token: "ghp_votre_token_ici"
  owner: "VEAF"
  repo: "VEAF-Mission-Creation-Tools"

Obtenir un token : - Aller sur https://github.com/settings/tokens - Cliquer sur "Generate new token (classic)" - Sélectionner le scope : repo (contrôle total des dépôts publics/privés) - Copier le token en sécurité (ne jamais le commiter dans git !) - ⚠️ Ne jamais commiter veaf-tools-config.yaml dans git !

Un published.zip compilé dans le répertoire courant. Il est produit par veaf-build build — vous ne l'assemblez pas à la main.

Compiler le paquet¶

Compilez les outils et produisez published.zip :

veaf-build build --version 6.0.1

Si vous omettez --version, la version est lue depuis package.json. Options utiles :

--skip-lua / --skip-python — sauter une moitié du build
--dev — build en mode développement
--output <dir> — répertoire de sortie du paquet (par défaut : répertoire courant)
--verbose — sortie détaillée
--pause — attendre une touche à la fin

Publication simple¶

Après le build (et l'édition de RELEASE_NOTES.md), publiez le published.zip déjà compilé :

Avec fichier de configuration (recommandé) :

veaf-build publish --version 6.0.1

Sans fichier de configuration :

veaf-build publish --version 6.0.1 --token ghp_xxxxxxxxxxxx

Remarques :

--version est une option, pas un argument positionnel. Si elle est omise, la version est lue depuis package.json.
Le token est résolu dans cet ordre : l'option --token, puis github.token dans veaf-tools-config.yaml, puis la variable d'environnement GITHUB_TOKEN.
published.zip doit déjà exister dans le répertoire courant (lancez veaf-build build d'abord).

Ce qui se passe : 1. ✅ Prépare les notes de version (pause interactive pour éditer RELEASE_NOTES.md) 2. ✅ Génère le checksum SHA256 de published.zip 3. ✅ Crée la Release GitHub taguée published-v6.0.1 4. ✅ Upload published.zip comme asset 5. ✅ Upload les métadonnées de checksum (published-metadata.json) 6. ✅ Déplace le tag published-latest pour pointer ici

Résultat : Les utilisateurs peuvent maintenant se mettre à jour avec veaf-tools-updater.exe

Forcer la republication¶

Si la release existe déjà et que vous voulez l'écraser :

veaf-build publish --version 6.0.1 --force

--force écrase la release existante (publication avec --clobber).

Pré-release (test sans impacter les utilisateurs)¶

veaf-build publish --version 6.0.1-rc1 --prerelease

--prerelease exige une version semver de pré-release (avec un suffixe -, ex. 6.0.1-rc1) : le workflow de release se base sur ce - pour laisser le tag published-latest en place. Un --prerelease sur une version nue (6.0.1) est refusé par la commande. Avec un suffixe valide, les utilisateurs en production ne sont pas mis à jour automatiquement ; testez explicitement avec :

.\veaf-tools-updater.exe --tag published-v6.0.1-rc1

Mode CI¶

veaf-build publish --version 6.0.1 --ci

--ci s'exécute de façon non interactive : il saute toutes les invites et utilise RELEASE_NOTES.md tel quel. À utiliser dans les pipelines automatisés.

Build et publication en une étape¶

veaf-build build-and-publish --version 6.0.1

Cela compile tout, fait une pause pour éditer RELEASE_NOTES.md, puis publie sur GitHub. La commande accepte les options de build (--skip-lua, --skip-python, --dev, --output), --token, --ci et --verbose.

Publication locale (test, sans GitHub)¶

Pour tester un build dans un vrai dossier de mission sans passer par GitHub + l'updater, déployez la sortie du build en local. Après veaf-build build :

veaf-build publish-local "D:/chemin/vers/ma-mission"

Cela reproduit l'état final d'une publication GitHub suivie d'un updater lancé dans ce dossier de mission : extrait published.zip dans <cible>/published/ et déplace veaf-tools.exe / veaf-tools-updater.exe à la racine du dossier de mission. Utilisez --published-zip <chemin> si votre published.zip est ailleurs. Aucun token GitHub requis.

Obtenir de l'aide¶

veaf-build --help
veaf-build publish --help

Affiche toutes les sous-commandes et options disponibles.

Pas à pas : Publier une release¶

1. Configurer (première fois uniquement)¶

Créez et configurez veaf-tools-config.yaml :

copy veaf-tools-config.example.yaml veaf-tools-config.yaml

Éditez-le avec votre token GitHub :

github:
  token: "ghp_votre_token_ici"
  owner: "VEAF"
  repo: "VEAF-Mission-Creation-Tools"

⚠️ Important : Ne jamais commiter veaf-tools-config.yaml dans git !

2. Compiler le paquet¶

veaf-build build --version 6.0.1

Cela compile les scripts Lua et les exécutables Python et produit published.zip dans le répertoire de sortie (le répertoire courant par défaut). Si vous omettez --version, elle est lue depuis package.json.

3. Éditer les notes de version¶

veaf-build publish ouvre une pause interactive pour vous permettre d'éditer RELEASE_NOTES.md avant la diffusion de la release. Décrivez ce qui a changé pour cette version.

4. Publier sur GitHub¶

veaf-build publish --version 6.0.1

Les étapes 2 à 4 peuvent être enchaînées avec veaf-build build-and-publish --version 6.0.1.

5. Vérifier sur GitHub¶

Visitez : https://github.com/VEAF/VEAF-Mission-Creation-Tools/releases

Vérifiez : - ✅ La release apparaît pour la version 6.0.1 - ✅ Assets uploadés : published.zip, published-metadata.json - ✅ Tag Git créé : published-v6.0.1 - ✅ Tag latest déplacé : published-latest

6. Annoncer aux utilisateurs¶

Informez les utilisateurs qu'ils peuvent se mettre à jour :

.\veaf-tools-updater.exe

Architecture du système¶

Système de versionnement¶

Le système utilise des tags Git pour gérer les versions :

Dépôt Git
├── published-v6.0.1   ──► Release GitHub avec assets
├── published-v6.0.0   ──► Release GitHub avec assets
├── published-v5.9.9   ──► Release GitHub avec assets
└── published-latest   ──► Pointe vers la version courante (mobile)

Avantages :

✅ Historique de versions clair dans Git
✅ Facile de revenir à n'importe quelle version précédente
✅ published-latest toujours disponible pour les utilisateurs
✅ Snapshots de versions immuables

Vérification d'intégrité¶

Chaque release inclut une vérification de checksum :

L'utilisateur télécharge :
  published.zip              (outils compilés)
  published-metadata.json    (contient le SHA256)

Processus de mise à jour :
  1. Calculer SHA256(published.zip)
  2. Comparer avec published-metadata.json
  3. Si correspondance ✓ → Installer
  4. Si différence ✗ → Erreur (abandon, réessayer)

Protection contre :

La corruption réseau
Les téléchargements incomplets
La falsification de fichiers

Comparaison de versions¶

Le système compare correctement les versions sémantiques :

Installée : 6.0.0
Disponible : 6.0.1
Résultat :    6.0.1 > 6.0.0 → Mise à jour disponible ✓

(Les anciens systèmes faisaient une comparaison de chaînes et échouaient)

Structure des fichiers¶

Ce que les utilisateurs ont¶

Après mise à jour, les utilisateurs ont :

Répertoire courant (dossier mission) :
├── veaf-tools.exe                    (exécutable principal, déplacé depuis published/)
└── veaf-tools-updater.exe            (l'updater lui-même ; une copie en cours d'exécution est renommée `*.old`, puis supprimée)

└── published/                        (le reste du paquet extrait)
    ├── README.md                     (reste ici volontairement — la doc en ligne fait foi)
    ├── package.json                  (info version)
    └── ... autres fichiers du paquet ...

Seuls les deux exécutables sont déplacés dans le répertoire courant ; tout le reste demeure sous published/.

Ce que GitHub affiche¶

Après publication :

Release : published-v6.0.1
├── Asset : published.zip              (outils compilés)
├── Asset : published-metadata.json    (checksums)
└── Notes de version

Tags Git :
├── published-v6.0.1 ──► commit abc123def...
├── published-latest ──► commit abc123def... (identique)
└── published-v6.0.0 ──► commit xyz789uvw...

Dépannage¶

Problème : « Tag not found on GitHub »¶

Cause : le tag Git a été créé localement mais n'a pas été poussé sur GitHub.

Solution :

# Check if tag exists locally
git tag -l published-v6.0.1

# If it exists, push it
git push origin refs/tags/published-v6.0.1

# If it doesn't exist, create it
git tag -a published-v6.0.1 -m "Release 6.0.1"
git push origin refs/tags/published-v6.0.1

Problème : « Checksum mismatch » lors de la mise à jour¶

Cause : corruption du fichier pendant le téléchargement (rare) ou problème réseau.

Solution :

# Try again (usually fixes it)
.\veaf-tools-updater.exe

# If persists, check GitHub release:
# https://github.com/VEAF/VEAF-Mission-Creation-Tools/releases

Problème : « GitHub rate limit exceeded »¶

Cause : trop d'appels à l'API en peu de temps.

Solution :

# Option 1: Wait 1 hour (rate limit resets)

# Option 2: Use Personal Access Token (better limits)
.\veaf-tools-updater.exe --token ghp_xxxxxxxxxxxx

# Get token from: https://github.com/settings/tokens
# Scope: repo (full control)

Problème : « Permission denied » lors de l'installation¶

Cause : écriture impossible dans le dossier mission ou le répertoire courant.

Solution :

# Run as Administrator (Windows)
# Or specify a different directory as a positional argument:
.\veaf-tools-updater.exe "C:\alternative\path"

Problème : « Release package not found » lors de la publication¶

Cause : published.zip n'existe pas dans le répertoire courant.

Solution :

# Verify file exists
dir published.zip

# If missing, build it first
veaf-build build --version 6.0.1

# Then publish
veaf-build publish --version 6.0.1

Problème : « Failed to create GitHub release »¶

Cause : généralement un problème de token ou de réseau.

Solution :

# Check token:
# 1. Verify veaf-tools-config.yaml exists and has correct token
# 2. Go to https://github.com/settings/tokens
# 3. Verify scope includes "repo"
# 4. Create new token if old one expired
# 5. Token must have write permissions

# Update your config file and try again
veaf-build publish --version 6.0.1 --verbose

Problème : la release existe déjà¶

Cause : une release avec ce tag a déjà été publiée.

Solution :

# Overwrite the existing release
veaf-build publish --version 6.0.1 --force

Obtenir plus d'aide¶

Pour des informations de débogage détaillées :

# Update tool: verbose output
.\veaf-tools-updater.exe --verbose

# Build/publish tool: verbose output
veaf-build publish --version 6.0.1 --verbose

Consultez le fichier veaf-tools.log pour les journaux détaillés. Il est écrit dans %USERPROFILE%\.veaf\veaf-tools.log (ou dans $VEAF_HOME si vous avez défini cette variable), pas dans le répertoire courant. .\veaf-tools.exe doctor vous en affiche le chemin exact et les dernières erreurs.

Référence des commandes¶

Commande de mise à jour (`veaf-tools-updater.exe`)¶

L'updater est une commande unique de mise à jour, sans sous-commande.

.\veaf-tools-updater.exe [MISSION_FOLDER] [OPTIONS]

Arguments:
  MISSION_FOLDER                 Mission folder path (overrides config file; default: current directory)

Options:
  --tag TEXT                     Tag name to fetch (default: published-latest)
  --token TEXT                   GitHub Personal Access Token (overrides config file)
  --force                        Ignore version check and install anyway
  --no-verify-checksum           Skip checksum verification (not recommended)
  --zip-file TEXT                Path to a local published.zip file (for testing, skips GitHub)
  --stage                        Leave the new veaf-tools beside the installed one (the AI server's own update)
  --lang TEXT                    Force interface language (en, fr); overrides OS locale and ~/veafmct.yaml
  --verbose                      Show detailed debug output
  --pause                        Wait for user input before exiting
  --help                         Show help message

Note : --stage est ce que lance la mise à jour automatique du serveur de l'IA : il laisse le nouveau veaf-tools.exe à côté de celui installé, sous le nom veaf-tools.exe.staged, pour que le prochain démarrage d'un serveur de l'IA le mette en place quand plus aucun autre veaf-tools.exe ne tourne. Un lancement à la main met en place une version en attente, et prévient quand un veaf-tools.exe tourne : le remplacer casse un serveur d'IA en marche.

Note : les réglages de veaf-tools-config.yaml sont utilisés automatiquement. Les options en ligne de commande priment sur les valeurs du fichier de configuration.

Exemples :

.\veaf-tools-updater.exe
.\veaf-tools-updater.exe --tag published-v6.0.0
.\veaf-tools-updater.exe --token ghp_xxx --verbose
.\veaf-tools-updater.exe --force
.\veaf-tools-updater.exe --zip-file ./published.zip

Commande de publication (`veaf-build publish`)¶

La publication est une sous-commande de veaf-build (et non de l'updater).

veaf-build publish [OPTIONS]

Options:
  --version TEXT                 Semantic version for the release (e.g. 6.0.1). If omitted, read from package.json
  --token TEXT                   GitHub Personal Access Token with 'repo' scope (or GITHUB_TOKEN env var)
  --force                        Force publish even if the release already exists (overwrites with --clobber)
  --prerelease                   Mark as pre-release; does NOT update published-latest
  --ci                           Non-interactive CI mode: skip all prompts and use RELEASE_NOTES.md as-is
  --verbose                      Show detailed debug output
  --pause                        Wait for user input before exiting
  --help                         Show help message

Note : published.zip doit déjà exister (lancez veaf-build build d'abord). Le token est résolu depuis --token, puis veaf-tools-config.yaml, puis la variable d'environnement GITHUB_TOKEN.

Autres sous-commandes veaf-build :

build [--version --skip-lua --skip-python --dev --output --verbose --pause] — compile les outils et produit published.zip
build-and-publish [--version --token --skip-lua --skip-python --dev --output --ci --verbose] — build puis publication en une étape
publish-local <target> [--published-zip --verbose --pause] — déploie un build dans un dossier de mission local (sans GitHub)
update-dcs-data [--countries --units --radio --airdromes --airfield-freqs --cockpit-controls --aircraft --dcs-path --inject-bridge --capture --serve-url --api-key --bridge-lua --all] — régénère les données de référence DCS commitées ; les six premiers drapeaux choisissent la table, --dcs-path vise une install DCS pour les tables qui en dépendent, et --inject-bridge / --capture / --serve-url / --api-key / --bridge-lua pilotent la capture depuis un DCS en cours (voir générateurs de données DCS)
build-standalone [--version --output --with-updater --verbose --pause] — compile les binaires pour la plateforme courante sans passer par la chaîne de release (utilisé par les runners Linux/macOS)
build-kit [--version --exe --bridge-zip --bridge-lua --output --verbose] — assemble le kit de capture distribué à l'opérateur d'une carte (exécutable + mission-pont)
terrain-data [<dossier> --output --publish --verbose] — vérifie les grilles d'altitude relevées et, avec --publish, les publie comme release terrain-data (voir publier les données de terrain)
about — informations sur le système de build

Exemples :

# With config file (recommended)
veaf-build build --version 6.0.1
veaf-build publish --version 6.0.1

# Without config file (token required)
veaf-build publish --version 6.0.1 --token ghp_xxx

# Pre-release / force / CI
veaf-build publish --version 6.0.1-rc1 --prerelease
veaf-build publish --version 6.0.1 --force
veaf-build publish --version 6.0.1 --ci

Bonnes pratiques¶

Pour les utilisateurs¶

✅ À faire : - Lancez .\veaf-tools-updater.exe régulièrement pour rester à jour - Laissez les checksums vérifier l'intégrité (n'utilisez pas --no-verify-checksum) - Utilisez --help en cas de doute sur une option

❌ À éviter : - Ignorer la vérification de checksum - Modifier manuellement veaf-tools-updater.exe ou les scripts de build - Utiliser d'anciennes versions sans raison valable - Partager vos Personal Access Tokens (un token = un mot de passe)

Pour les administrateurs¶

✅ À faire : - Stockez votre token dans veaf-tools-config.yaml (jamais dans git !) - Publiez toujours avec veaf-build publish pour rester cohérent - Tenez les notes de version à jour - Testez avant de publier en production - Utilisez des tokens différents pour des machines différentes - Régénérez les tokens régulièrement - Conservez veaf-tools-config.yaml dans .gitignore

❌ À éviter : - Committer veaf-tools-config.yaml dans git - Committer des Personal Access Tokens où que ce soit - Partager vos tokens avec d'autres personnes - Publier des versions non testées - Réutiliser un même token sur plusieurs machines - Sauter le processus de vérification

Sécurité¶

Sûreté du token¶

Votre Personal Access Token GitHub est comme un mot de passe : - ❌ Ne le commitez jamais dans git (même dans des fichiers de configuration) - ❌ Ne le partagez jamais par e-mail ou message - ❌ Ne le collez jamais sur des forums publics - ❌ Ne poussez jamais veaf-tools-config.yaml dans git - ✅ Stockez-le dans veaf-tools-config.yaml (local uniquement) - ✅ Assurez-vous que veaf-tools-config.yaml figure dans .gitignore - ✅ Régénérez-le régulièrement (chaque mois) - ✅ Utilisez-le pour une tâche, puis révoquez-le (lorsque c'est possible)

Vérification par checksum¶

Les checksums protègent les téléchargements : - ✅ Détectent la corruption réseau - ✅ Vérifient que les fichiers n'ont pas été modifiés - ✅ Préviennent les attaques de l'homme du milieu (man-in-the-middle) - ✅ Activés par défaut (gardez-les ainsi !)

HTTPS¶

Toutes les communications avec GitHub utilisent le chiffrement TLS/SSL : - ✅ Les données en transit sont protégées - ✅ L'API GitHub impose HTTPS - ✅ Votre token est chiffré sur le réseau

FAQ¶

Q : Puis-je revenir à une ancienne version ? R : Oui ! .\veaf-tools-updater.exe --tag published-v6.0.0

Q : Que faire si la publication échoue ? R : Consultez la section Dépannage ci-dessus. La plupart des problèmes sont liés au réseau ou au token.

Q : Ai-je besoin du token pour mettre à jour ? R : Non, le token ne sert qu'à publier. La mise à jour fonctionne sans lui (avec des limites de débit).

Q : À quelle fréquence dois-je publier de nouvelles versions ? R : Aussi souvent que vous avez des changements. Les utilisateurs ne les verront que si vous le leur annoncez.

Q : Puis-je supprimer ou annuler une version publiée ? R : Sur GitHub, oui. Mais les utilisateurs l'ont peut-être déjà téléchargée.

Q : Comment publier une beta sans impacter les utilisateurs ? R : Utilisez veaf-build publish --version <x.y.z>-rc1 --prerelease — la version doit porter un suffixe semver de pré-release (-rc1, -beta…), sinon la commande refuse. Le tag published-latest reste alors intact, donc les utilisateurs en production ne sont pas mis à jour ; testez avec .\veaf-tools-updater.exe --tag published-v<x.y.z>-rc1.

Q : Comment republier par-dessus une release existante ? R : Utilisez veaf-build publish --version <x.y.z> --force.

Q : Combien de temps les tokens durent-ils ? R : Tant que vous ne les révoquez pas. Ils n'expirent pas automatiquement.

Q : Le checksum est-il obligatoire ? R : Non (on peut l'ignorer avec --no-verify-checksum), mais il est fortement recommandé.

Obtenir de l'aide¶

Si vous rencontrez des problèmes :

Consultez la section Dépannage ci-dessus
Lancez avec --verbose pour voir la sortie détaillée
Vérifiez veaf-tools.log dans %USERPROFILE%\.veaf\ (ou $VEAF_HOME) — voir Obtenir de l'aide
Visitez la page des releases GitHub pour confirmer que la release existe
Vérifiez votre connexion Internet (la plupart des problèmes sont réseau)
Vérifiez les permissions du token sur https://github.com/settings/tokens

Historique des versions¶

Actuelle (6.0.1+)¶

✅ Outils dédiés : veaf-tools-updater.exe (mise à jour) et veaf-build (build/publication)
✅ Versionnement basé sur les tags Git
✅ Vérification par checksum SHA256
✅ Comparaison sémantique des versions
✅ Publication entièrement automatisée

Précédente¶

Script de mise à jour basique
Versionnement basé sur les releases
Publication manuelle
Documentation limitée

Bonnes publications ! 🚀

Pour plus de détails techniques, consultez le code source ou le dépôt GitHub.

VEAF Tools — Guide utilisateur et administrateur¶

Vue d'ensemble¶

Fichier de configuration (optionnel mais recommandé)¶

Installation¶

Avantages¶

Interroger la documentation (assistant IA)¶

Utilisation¶

Pour les utilisateurs : Mise à jour¶

Mise à jour simple (recommandée)¶

Mise à jour vers une version spécifique¶

Forcer la mise à jour (ignorer la vérification de version)¶

Mise à jour avec token GitHub (meilleures limites de débit)¶

Ignorer la vérification de checksum (non recommandé)¶

Langue de l'interface¶

Sortie verbeuse (débogage)¶

Toutes les options combinées¶

Obtenir de l'aide¶

Pour les administrateurs : Publication¶

Prérequis¶

Compiler le paquet¶

Publication simple¶

Forcer la republication¶

Pré-release (test sans impacter les utilisateurs)¶

Mode CI¶

Build et publication en une étape¶

Publication locale (test, sans GitHub)¶

Obtenir de l'aide¶

Pas à pas : Publier une release¶

1. Configurer (première fois uniquement)¶

2. Compiler le paquet¶

3. Éditer les notes de version¶

4. Publier sur GitHub¶

5. Vérifier sur GitHub¶

6. Annoncer aux utilisateurs¶

Architecture du système¶

Système de versionnement¶

Vérification d'intégrité¶

Comparaison de versions¶

Structure des fichiers¶

Ce que les utilisateurs ont¶

Ce que GitHub affiche¶

Dépannage¶

Problème : « Tag not found on GitHub »¶

Problème : « Checksum mismatch » lors de la mise à jour¶

Problème : « GitHub rate limit exceeded »¶

Problème : « Permission denied » lors de l'installation¶

Problème : « Release package not found » lors de la publication¶

Problème : « Failed to create GitHub release »¶

Problème : la release existe déjà¶

Obtenir plus d'aide¶

Référence des commandes¶

Commande de mise à jour (veaf-tools-updater.exe)¶

Commande de publication (veaf-build publish)¶

Bonnes pratiques¶

Pour les utilisateurs¶

Pour les administrateurs¶

Sécurité¶

Sûreté du token¶

Vérification par checksum¶

HTTPS¶

FAQ¶

Obtenir de l'aide¶

Historique des versions¶

Actuelle (6.0.1+)¶

Précédente¶

Commande de mise à jour (`veaf-tools-updater.exe`)¶

Commande de publication (`veaf-build publish`)¶