Aller au contenu

Tests plateforme et déploiement

Démarrage et santé

PLAT-001 — Construction et migrations

Prérequis : configuration de recette complète et volumes sauvegardés.

  1. Exécuter les tests API qui parcourent toutes les révisions et refusent tout identifiant Alembic supérieur à 32 caractères.
  2. Construire la stack sur un PostgreSQL réel positionné au head précédent, démarrer les services et appliquer alembic upgrade head.
  3. Pour 0038_merge_buildings, exécuter une première recette depuis une copie au head 0037_merge_crafting_vehicles, puis une seconde depuis un volume neuf. Vérifier que 0037_buildings est appliquée une seule fois dans les deux cas.
  4. Appliquer 0039_building_timestamps depuis 0038_merge_buildings, créer une agence puis contrôler que PostgreSQL renseigne created_at et updated_at sans valeur fournie par le client.
  5. Contrôler alembic heads, alembic current, les tables immobilières, les données existantes, les états Compose et les journaux de chaque service.
  6. Relancer la migration une seconde fois.

Attendu : toutes les images se construisent, les services deviennent sains, l'API répond à /ready, la valeur d'alembic_version.version_num correspond à l'unique head et tient dans le VARCHAR(32), et la seconde migration est sans effet ni erreur. Une révision synthétique de 33 caractères est refusée par le garde-fou automatisé avant toute tentative de migration. Le head unique est 0039_building_timestamps; l'API, puis l'admin et FiveM, démarrent sans erreur multi-head et un INSERT immobilier n'échoue pas sur ses timestamps.

PLAT-002 — Dépendances et isolation réseau

  1. Vérifier que l'API attend PostgreSQL et Redis et que FiveM attend /ready.
  2. Confirmer que le port API n'est pas publié sur l'hôte.
  3. Ouvrir admin, documentation, FiveM et txAdmin sur leurs ports configurés.

Attendu : chaque service communique sur le réseau prévu ; seuls les points d'entrée documentés sont publiés et l'admin accède à l'API via /api.

PLAT-003 — Persistance après recréation

  1. Créer une donnée de chaque famille persistante : personnage, note whitelist, actualité, tenue, vestiaire et prop.
  2. Recréer les conteneurs sans supprimer les volumes.
  3. Relire les données depuis le web et FiveM.

Attendu : les données et ressources attendues sont restaurées ; aucun élément supprimé d'une nouvelle image ne subsiste parmi les ressources gérées.

Mappings, MLO et exploitation

PLAT-004 — Synchronisation des trois dépôts de mappings

  1. Démarrer FiveM avec les trois groupes absents, puis relever les SHA .bundle-revision.
  2. Redémarrer sans nouvelle révision.
  3. Publier ou simuler une nouvelle révision de main, puis recréer FiveM.

Attendu : les trois dépôts publics sont téléchargés avant FXServer, le second démarrage les conserve, puis la nouvelle révision remplace intégralement le groupe concerné.

PLAT-005 — Échec de synchronisation

  1. Sur l'environnement de recette, rendre temporairement un dépôt inaccessible.
  2. Démarrer le conteneur FiveM et consulter son journal.

Attendu : le conteneur échoue avant le lancement de FXServer avec un message explicite ; aucun serveur partiellement synchronisé n'accepte de joueur.

PLAT-005B — Environnement léger sans MLO

  1. Définir FIVEM_LOAD_MLOS=false avec un volume de ressources vide et démarrer FiveM.
  2. Vérifier les journaux, le server.cfg généré et les états des ressources.
  3. Refaire le test avec un volume contenant déjà les trois groupes de mappings.
  4. Demander l'activation d'un MLO depuis le web admin et attendre deux cycles de synchronisation.
  5. Tester une valeur invalide telle que FIVEM_LOAD_MLOS=maybe.

Attendu : aucun accès Git aux mappings n'a lieu, aucun MLO/IPL connu n'est démarré, les ressources persistées restent arrêtées et l'admin ne peut pas les réactiver. La valeur invalide arrête le conteneur avant FXServer avec un message explicite. Avec true, le comportement complet de PLAT-004 reste inchangé.

PLAT-006 — Logs et rotation

  1. Produire des événements API, admin, bot et FiveM.
  2. Vérifier les fichiers séparés, la lecture par l'API et la rotation bornée.
  3. Injecter une valeur ressemblant à un secret dans un message de recette.

Attendu : les sources restent séparées, les montages de consultation sont en lecture seule et les secrets sont masqués dans les résultats exposés.

PLAT-006B — Deux stacks et permissions PostgreSQL

Prérequis : deux stacks Git Portainer portant des noms distincts et ciblant deux branches, avec des ports publics différents et des volumes neufs.

  1. Déployer les deux stacks sur le même endpoint Docker sans définir COMPOSE_PROJECT_NAME.
  2. Vérifier que chaque stack possède ses propres volumes postgres_data et database_logs.
  3. Contrôler la fin normale de logs-init, puis démarrer et redémarrer chaque base.
  4. Inspecter le propriétaire et les modes du répertoire et du fichier de journal PostgreSQL.
  5. Remettre volontairement un mauvais propriétaire sur le journal, puis recréer uniquement la base.

Attendu : les données et journaux ne sont pas partagés. Le répertoire appartient à 70:70 en 0775, postgresql.log appartient à 70:70 en 0664, et les deux bases deviennent saines sans erreur Permission denied. Le wrapper de la base répare aussi le propriétaire erroné avant le démarrage officiel, sans réinitialiser PGDATA.

PLAT-007 — Documentation stricte

  1. Exécuter docker compose build docs.
  2. Ouvrir le site et parcourir Fonctionnel, Technique et Tests sur ordinateur et mobile.

Attendu : aucune alerte MkDocs, aucun lien de navigation cassé et la recherche indexe les trois sections.

PLAT-008 — Protection de l'API interne

Appeler une route interne sans clé, avec une mauvaise clé puis avec la clé attendue depuis un service autorisé. Envoyer aussi un payload invalide et une cible inconnue.

Attendu : les deux premiers appels sont refusés sans détail sensible, l'appel authentifié suit les permissions métier, les erreurs de validation sont structurées et aucune donnée partielle n'est écrite.

PLAT-009 — Dernier artefact et build de jeu

Prérequis : accès sortant à runtime.fivem.net et au fichier public server-commands.md de Cfx.re sur GitHub.

  1. Recréer le conteneur FiveM avec un volume d'artefacts vide.
  2. Comparer l'URL journalisée et .artifact-url au numéro le plus élevé de l'index officiel.
  3. Vérifier que le build journalisé correspond à production_game_build dans fivem/game-build-policy.conf et que cette valeur figure dans la table officielle sv_enforceGameBuild.
  4. Avec une table contenant un numéro supérieur (par exemple 3889 au-dessus de 3751), vérifier que le journal le signale comme non promu et conserve le build Production approuvé.
  5. Vérifier dans le server.cfg rendu sv_enforceGameBuild 3751 et sv_replaceExeToSwitchBuilds false.
  6. Exécuter sh fivem/tests/resolve-game-build.test.sh.
  7. Redémarrer sans publication nouvelle, puis simuler une URL d'artefact plus récente en recette.

Attendu : le premier démarrage télécharge le dernier artefact, le second réutilise le cache, une publication plus récente remplace entièrement le cache et le build GTA Production approuvé est imposé indépendamment du maximum documenté.

Erreurs : rendre chaque source officielle ou le téléchargement inaccessible, retirer 3751 de la table simulée, puis tester une politique vide, dupliquée, inconnue et non numérique. Chaque cas doit échouer avant FXServer avec un diagnostic explicite et sans fallback silencieux.

PLAT-010 — Migration des noms de ressources

  1. Démarrer depuis un volume contenant les anciens dossiers locaux gta-* et basicspawn.
  2. Recréer le conteneur avec la nouvelle image et inspecter le volume ainsi que la console FXServer.
  3. Exécuter les parcours admin, inventaire, vêtements, vestiaires, interactions et commandes.

Attendu : seuls les dossiers locaux medusa-* subsistent, aucune ressource n'est absente ou chargée deux fois, les dépendances et exports se résolvent, et les fonctionnalités conservent leur comportement et leurs permissions antérieurs.

PLAT-011 — Readiness interne et clé FiveM

  1. Démarrer la stack avec la bonne clé, puis avec une clé FiveM absente ou fausse.
  2. Sur un volume jetable, placer alembic_version sur une révision antérieure sans lancer les migrations.
  3. Rendre tour à tour PostgreSQL et Redis indisponibles, puis les restaurer.

Attendu : FXServer démarre uniquement quand DB, Redis, schéma et clé sont valides. Une clé refusée échoue immédiatement sans être affichée ; les autres pannes attendent jusqu'au timeout avec un statut lisible. /ready et la route interne exposent les mêmes checks assainis.

PLAT-012 — Contrat d'erreur HTTP FiveM

Simuler succès JSON/204, 401, 503, timeout, réseau coupé et JSON invalide sur le client medusa-core.

Attendu : les succès restent compatibles ; chaque erreur est sérialisable et contient méthode, route, code, statut éventuel et corrélation sans secret ni payload. Seules les erreurs transitoires sont rejouées par l'export explicite, dans la limite configurée.

PLAT-013 — Migration et reprise des véhicules

  1. Sauvegarder la base puis auto-déployer VirgiilBranch sans override de VEHICLES_ENABLED.
  2. Vérifier que 0028_vehicle_keys est appliquée avant /ready, puis enregistrer deux véhicules et en laisser un déverrouillé.
  3. Redémarrer uniquement medusa-vehicles, puis FXServer, et reconnecter deux clients.
  4. Définir VEHICLES_ENABLED=false dans Portainer, redéployer et vérifier le coupe-circuit sans supprimer les données.

Attendu : une seule entité existe par UUID, les deux véhicules reviennent verrouillés et moteur coupé avant interaction, la position sûre et l'apparence persistent, et le flag coupe les nouvelles actions sans altérer les dossiers.

PLAT-014 — PostgreSQL 0036 et migration des préférences

  1. Créer une copie PostgreSQL jetable au head 0035_speedometer_cruise_v2 avec des lignes small, normal et large, plusieurs comptes et deux personnages partageant un compte.
  2. Exécuter alembic upgrade 0036_speedometer_placement, puis alembic heads et /ready.
  3. Vérifier small→80, normal→100, large→120 et (position_x,position_y)=(0.5,0.8). Thème, visibilité, éclairage, révision, timestamps, FK cascade et ownership des reçus doivent être inchangés. Confirmer les contraintes 60–140/pas de 5 et coordonnées [0,1]. Rejouer l'upgrade ; ne jamais downgrader la production.
  4. Lancer simultanément 48 GET puis PATCH, doubles clics identiques et deux PATCH concurrents de la même révision. Mesurer côté API/DB, hors latence volontairement injectée.
  5. Couper séparément VEHICLE_SPEEDOMETER_ENABLED et VEHICLE_CONTROL_MENUS_ENABLED, puis les réactiver sans restart. Redémarrer API, HUD et véhicules séparément. Vérifier également l'absence de mapping/action K/Page précédente/Page suivante.

Attendu : head unique 0036, readiness verte uniquement après migration, aucune donnée véhicule/handling modifiée, p95 <500 ms, aucun doublon, un succès et un conflit pour la même révision, replay canonique du même UUID et préférence conservée lorsque les flags sont coupés.

Migration et déploiement énergie 0040 à 0042

Exécuter api/tests/postgres/run_vehicle_energy_0040.ps1 sur Docker : projet Compose isolé, chemin 0038→0039, fixtures, dump, upgrade 0040, API/recovery, assertions, second passage et downgrade refusé. Confirmer ensuite /ready, l'ordre medusa-vehicles → lc_utils → medusa-energy → lc_fuel → medusa-admin, le contrat LC sans writer et l'absence de ressource fuel concurrente.

Le canary à deux joueurs vérifie Essence/Diesel/Électrique, six produits, 26 chargeurs, 14 points spécialisés, objets portables, interruptions, garages et maintien des pourcentages historiques à 30/60/144 FPS après restart. Push/hook, build, migration et preuve en jeu sont rapportés séparément. Voir Tests du système énergie.

Exécuter ensuite api/tests/postgres/run_vehicle_energy_0041.ps1 -Cleanup. Le projet isolé medusa-energy-0041-test part du head 0040, empreinte les données existantes, applique 0041 deux fois et vérifie 669 baselines LC immuables, Buffalo, collisions/contraintes, /ready, alembic check et downgrade refusé. Le canary R1 ajoute une Buffalo devant une pompe GTA native, un modèle à bones, l’override/reset F10 et sa lecture web, puis restart/reconnexion et mesure resmon.

Exécuter enfin api/tests/postgres/run_vehicle_energy_0042.ps1 -Cleanup. Le projet isolé medusa-energy-0042-test part du head 0041, conserve un dump et les empreintes hors heading, préserve une rotation F10 et une installation custom, puis exige les rotations conditionnelles, l’audit unique, un second upgrade head, /ready, alembic check et le refus du downgrade. Le canary inspecte les 26 faces utiles, la persistance après restart et la restauration F10 vers la nouvelle orientation canonique.