[bfoujols]

Contexte

studoo-app/edu-framework#169 ajoute le déploiement sur Debian/Ubuntu avec FrankenDeploy (php bin/edu make:deploy). Les projets des élèves sont créés avec ce skeleton, mais il lui manquait de quoi construire l'image de production : son Dockerfile n'avait qu'un stage, et il n'y avait ni docker-entrypoint.sh ni .dockerignore. Sans ces fichiers, FrankenDeploy génère des fichiers Symfony (bin/console) et le build échoue.

Avec cette PR, un projet créé par composer create-project studoo/edu-framework-skeleton contient ces fichiers dès le départ.

Changements

Fichiers repris tels quels de la branche deploy d'edu-framework (commit 661ded3) :

• Dockerfile multi-stage :
  • frankenphp_base : socle commun (extensions PHP, Composer) ;
  • frankenphp_prod : image de production, HTTP sur le port 8080, utilisateur non-root app (uid 1000), healthcheck, docker-entrypoint ;
  • frankenphp_dev : stage par défaut, avec le profiler Excimer.
• docker-entrypoint.sh (exécutable) : attend que la base de données réponde, puis démarre FrankenPHP.
• .dockerignore : exclut .env, .env.local, var/, vendor/, la documentation et les dumps SQL de l'image.

Modifiés dans le skeleton :

• compose.yaml : le service frankenphp est construit sur le stage frankenphp_dev (build.context + build.target).
• .gitignore : la ligne composer.lock est retirée. L'image de production fait COPY composer.json composer.lock, et en build distant FrankenDeploy n'envoie que les fichiers suivis par git. Le lock doit donc être versionné dans les projets.

À propos de composer.lock

Cette PR n'ajoute pas de composer.lock au skeleton, qui n'en a jamais versionné. composer create-project génère le lock dans le projet de l'élève, et ce lock sera maintenant suivi par git. Revers : dans le dépôt du skeleton lui-même, un composer install fera apparaître un composer.lock non suivi, à ne pas commiter.

⚠️ À fusionner après studoo-app/edu-framework#169

Le skeleton dépend de studoo/edu-framework: dev-main. Or docker-entrypoint.sh appelle ConfigCore::loadEnv(), qui n'existe pas encore sur main (ca5968c). Avec le framework actuel de main, le conteneur de production s'arrête au démarrage :

Call to undefined method Studoo\EduFramework\Core\ConfigCore::loadEnv()
[Edu-Framework] Configuration invalide : vérifiez les variables d'environnement (frankendeploy env list prod)

La commande make:deploy arrive elle aussi avec #169.

Tests

Testé en local (Docker 29.9.1, avec un composer.lock généré localement et non commité) :

• docker compose config valide, build.target: frankenphp_dev bien pris en compte
• docker build --target frankenphp_prod . réussit
• docker build --target frankenphp_dev . réussit
• Image de prod, avec les sources du framework de la branche deploy (661ded3) à la place de vendor/studoo/edu-framework/src : démarre sans base (DB_HOST_STATUS=false), répond HTTP 200 sur le port 8080 et tourne sous l'utilisateur app (uid 1000)
• Image de prod avec le framework de main (ca5968c) : le conteneur s'arrête sur l'erreur loadEnv() (d'où la dépendance à #169)
• Image de dev : répond HTTP 200 sur le port 80, extensions excimer, intl, pdo_mysql et pdo_sqlite présentes

Non testé :

• Un vrai déploiement avec FrankenDeploy sur un serveur Debian/Ubuntu
• php bin/edu make:deploy dans un projet issu du skeleton (nécessite #169 sur main)
• composer create-project de bout en bout depuis cette branche
• L'attente de la base de données dans docker-entrypoint.sh (testée côté framework uniquement)
• docker compose up avec toute la stack (base, mailer, dbgate, phpMyAdmin)

Remarque hors périmètre (déjà présent sur 2.x)

Le README documente EDU_PROFILER_BUILD (image avec ou sans Excimer), mais compose.yaml ne passe pas cet argument au build. Dans edu-framework, le bloc build contient args: EDU_PROFILER: ${EDU_PROFILER_BUILD:-1}. Cette PR ne corrige pas ce point ; il peut être aligné séparément.

🤖 Generated with Claude Code