4 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	d474303a55	Corrige la CI (suite) : exécute les tests pendant un docker build, pas dans un container de job ... "container: image: python:3.13-slim" (tentative précédente) casse actions/checkout@v4 : c'est une action Node.js, qui a besoin de Node dans l'environnement d'exécution des steps — "container:" remplace CET environnement en entier par l'image donnée, qui n'a pas Node ("command not found", nektos/act#107), pas seulement l'environnement des commandes qu'on y lance soi-même. Nouvelle approche : le job tourne sur le runner par défaut (checkout fonctionne normalement, Node y est déjà disponible), et les tests s'exécutent PENDANT un `docker build` (Dockerfile jetable passé par stdin, jamais commité, un par langage) plutôt que dans un conteneur lancé après coup — le transfert du contexte de build vers le démon Docker passe par le protocole API (tar), jamais par un chemin hôte à monter, donc insensible au problème Docker-outside-of-Docker qui avait fait échouer le tout premier essai (docker run -v "$PWD":/app). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 16:08:59 +02:00
williamandClaude Sonnet 5	8e8a159e88	Corrige la CI : les jobs de test tournent dans "container" au lieu d'un docker run imbriqué ... Le job "test" échouait ("Could not open requirements file: requirements-dev.txt") : docker run -v "$PWD":/app lancé DEPUIS un runner qui exécute déjà le job dans son propre conteneur (Docker- outside-of-Docker) ne peut pas monter "$PWD" — ce chemin vit dans le conteneur du job, pas sur l'hôte où tourne le vrai démon Docker sollicité par ce docker run imbriqué ; /app se retrouvait donc vide dans le conteneur imbriqué. Corrigé en utilisant la clé "container" (standard Gitea/GitHub Actions) : le job tourne DIRECTEMENT dans l'image voulue, le checkout dépose les fichiers dans son propre système de fichiers, aucun montage de volume à faire. Un seul job "test" ne peut avoir qu'UNE image : scindé en test-python (python:3.13-slim) et test-js (node:20-slim, pour les tests node:test de static/js/play/__tests__/), build-and-push dépend des deux. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 16:04:10 +02:00
williamandClaude Sonnet 5	bb84b7b377	Phase 0 : factorise compute_new_value + ajoute pytest/node test à la CI ... 1. Duplication éliminée avant que la Phase 2 (hasard/opérations mathématiques) n'en ajoute 6 de plus aux DEUX fichiers : la chaîne d'opérations quasi identique entre screens/data_actions/ apply_data_action.py (champ d'objet) et apply_variable_action.py (variable globale) est factorisée dans un nouveau compute_operation.py::compute_new_value(operation, current, raw_value, is_decimal), réutilisé par les deux. Nouveau tests/test_compute_operation.py verrouille le comportement des 7 opérations existantes (dont les cas limites : valeur invalide, type décimal vs entier, opération inconnue) avant d'en ajouter d'autres. 2. .gitea/workflows/deploy.yml déployait en prod à chaque push sur main sans jamais exécuter la suite de tests — rien ne bloquait techniquement un commit cassé. Nouveau job "test" (pytest + node:test sur la logique pure de static/js/play/, via des conteneurs officiels plutôt que des actions du marketplace, cohérent avec le choix déjà fait dans ce fichier) tourne sur CHAQUE push (main ET dev, utile pour ce dépôt qui travaille sur dev) ; "build-and-push"/"deploy" gagnent un "needs: test" et restent réservés à main (filtre sur gitea.ref) — un push sur dev ne redéploie jamais la prod, seulement les tests. Vérifié : 223 tests passent (8 nouveaux), YAML validé. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-30 15:00:23 +02:00
williamandwilliam	3f4ebc4527	first commit	2026-08-21 16:23:49 +02:00