Système de test automatisé — Docker par distro pour valider tous les scripts d'installation

[RajPorus19]

Concept

Tester tous les scripts d'installation de tous les programmes sur toutes les distributions, automatiquement, dans des conteneurs Docker isolés.

Principe

1 conteneur Docker par distro
         │
         ▼
  ScriptGenerator (JS → Node.js ou Python)
  génère un script d'install pour TOUS les programmes
         │
         ▼
  Le script est exécuté dans le conteneur
         │
         ▼
  ┌─ Succès → ✅ package OK
  └─ Échec  → ❌ loggué : quel package, quelle distro, quelle erreur

Règles de priorité d'installation

1. Package manager natif — toujours privilégié (apt, pacman, xbps, dnf, zypper, apk)
2. curl/wget — si pas dispo dans les repos, télécharger un binaire ou un script officiel
3. Compilation from source — dernier recours, avec les dépendances de build (build-essential, cmake, etc.) installées avant la compilation

Workflow

1. Le test runner lit tous les program.json du catalogue (291 programmes)
2. Pour une distro donnée, il génère un script d'installation complet (package manager d'abord, puis customs)
3. Le script est exécuté dans un conteneur Docker de cette distro
4. Les programmes qui échouent sont loggués avec :
   • Nom du programme
   • Distro testée
   • Message d'erreur
   • Type d'installation tentée (native / curl / compile)
5. Le reviewer analyse le rapport, corrige le program.json ou le custom_install/install.sh
6. On relance le test → le package passe au vert ✅

Architecture proposée

linux-setup-generator/
├── tests/
│   ├── docker/
│   │   ├── Dockerfile.alpine
│   │   ├── Dockerfile.arch
│   │   ├── Dockerfile.debian
│   │   ├── Dockerfile.fedora
│   │   ├── Dockerfile.opensuse
│   │   ├── Dockerfile.ubuntu
│   │   └── Dockerfile.void
│   ├── runner.py              # Test runner principal
│   ├── script_generator.py    # Replique la logique de script-generator.js
│   └── report.py              # Formate le rapport de test
├── .github/workflows/
│   └── test.yml               # CI : lance les tests sur push/PR
└── docs/
    └── testing-spec.md        # Spécifications détaillées

Composants

script_generator.py

Replique la classe ScriptGenerator JS en Python :

• Lit les program.json et distros/*.json
• Résout les dépendances (DFS topologique, visited set partagé)
• Gère CUSTOM_INSTALL → lit le install.sh depuis le filesystem
• Génère le script bash final

runner.py

• Prend une distro en argument (ex: python runner.py --distro void)
• Appelle script_generator.py pour générer le script
• Build l'image Docker de la distro si pas déjà built
• Monte le script dans le conteneur et l'exécute
• Capture stdout/stderr et le code de retour
• Parse la sortie pour identifier les packages qui ont fail

Dockerfile.<distro>

• Image minimale de la distro
• Pré-installe les outils de base (curl, git, build-essential, etc.)
• L'utilisateur root pour éviter les prompts sudo

test.yml (GitHub Actions)

• Matrix build : 7 distros × 1 job = 7 jobs parallèles
• Chaque job build son Dockerfile, lance runner.py, upload le rapport
• Option : lancer seulement sur les fichiers modifiés (paths: content/programs/**)

Format du rapport

{
  "distro": "void",
  "timestamp": "2026-06-10T12:00:00Z",
  "total": 291,
  "passed": 273,
  "failed": 18,
  "failures": [
    {
      "program": "virtualbox",
      "slug": "virtualbox",
      "error": "package 'virtualbox' not found in repository",
      "attempted_method": "native",
      "suggestion": "Use CUSTOM_INSTALL with curl to Oracle repo"
    },
    {
      "program": "tor-browser",
      "slug": "tor-browser",
      "error": "curl: (22) The requested URL returned error: 404",
      "attempted_method": "curl",
      "suggestion": "Update download URL in custom_install/install.sh"
    }
  ]
}

Défis

• Temps d'exécution : 291 programmes × builds from source = potentiellement des heures. Solution : paralléliser par distro (7 runners), et peut-être par lot de programmes (ex: 50 par run).
• Taille des images Docker : certaines installs sont lourdes (IDE, navigateurs). Solution : utiliser le cache de couches Docker, faire des runs incrémentaux.
• Interactivité : certaines commandes demandent une confirmation. Solution : toujours utiliser les flags non-interactifs (--noconfirm, -y, DEBIAN_FRONTEND=noninteractive).
• Réseau dans Docker : les conteneurs doivent avoir accès à Internet pour curl/cargo/npm. GitHub Actions le permet par défaut.

Fichiers à créer

• tests/docker/Dockerfile.alpine
• tests/docker/Dockerfile.arch
• tests/docker/Dockerfile.debian
• tests/docker/Dockerfile.fedora
• tests/docker/Dockerfile.opensuse
• tests/docker/Dockerfile.ubuntu
• tests/docker/Dockerfile.void
• tests/runner.py
• tests/script_generator.py
• tests/report.py
• .github/workflows/test.yml
• docs/testing-spec.md