Aller au contenu

Garder mon Dev Container à jour

Vous développez dans le Dev Container Kirexo et votre image kirexo-dev a dérivé : le Dockerfile a bougé (nouvel outil, bump de version) mais votre conteneur tourne encore sur l'ancienne image, silencieusement. Cette recette montre comment repérer la dérive puis la rafraîchir : un geste côté hôte (castor devcontainer:refresh), un geste côté IDE (« Rebuild and Restart Container »). Pour le détail factuel du Dev Container, voir la Référence du Dev Container.

Le problème : une image dev qui dérive en silence

Deux causes s'empilent et laissent votre image tourner périmée sans erreur visible.

  • Amont — l'image base kirexo-dev:php8.5 n'est republiée que par le job CI docker:build-dev. Tant que ce job n'a pas rejoué, un commit qui touche le Dockerfile ne se propage pas dans le registre.
  • Aval — PhpStorm ne lance pas le tag image: du compose : il build et démarre sa propre surcouche jb-<hash>-uid (FROM …/kirexo-dev:php8.5 + un layer UID/GID). Les docker compose build lancés depuis un terminal hôte reconstruisent une autre image, jamais consommée par le devcontainer. Seul un « Rebuild and Restart Container » dans PhpStorm, partant d'une base à jour, propage réellement le changement.

Le détail de cette architecture (surcouche jb-…, FROM …/kirexo-dev, choix de ne pas utiliser les features devcontainer) est décrit dans la référence, section Node et Claude Code dans l'image et Service attaché. Cette recette ne réexplique pas le pourquoi — elle donne le geste.

Le signal : l'alerte du dashboard de session

Quand votre image a du retard, le dashboard de session Claude affiche exactement :

⚠ Image dev en retard de 3 commits sur le Dockerfile (buildée @a1b2c3d)
  → castor devcontainer:refresh
  • L'alerte n'apparaît que dans le dashboard de session Claude.
  • @a1b2c3d est le SHA de build, lu dans /etc/kirexo-dev.ref.
  • Silence total si l'image est à jour, si /etc/kirexo-dev.ref est absent (image d'avant ce mécanisme) ou vaut unknown (build local nu) : dans ces cas, la détection se dégrade silencieusement plutôt que d'émettre un faux positif.

Le geste : castor devcontainer:refresh

Lancez la cible depuis un terminal hôte :

castor devcontainer:refresh

Elle enchaîne :

  1. docker pull de l'image base kirexo-dev:php8.5 — rafraîchit le cache local que le rebuild PhpStorm consommera ;
  2. docker compose -p kirexo stop php — arrête le service ;
  3. docker rmi de la surcouche jb-<hash>-uid courante (son nom est résolu via docker inspect du conteneur php) — force le FROM de PhpStorm à re-résoudre contre la base fraîchement pull.

À lancer depuis un terminal hôte

castor devcontainer:refresh est une cible host-only : elle pilote Docker depuis l'extérieur. Lancée depuis l'intérieur du conteneur, elle appelle assert_outside_container() et échoue en erreur (on ne peut pas retirer l'image qui héberge le conteneur courant). Elle figure dans la référence, section Cibles qui refusent l'intérieur.

Limite : la commande ne rebuild pas l'IDE

castor devcontainer:refresh prépare le terrain (base à jour + suppression de la surcouche jb-…) mais ne peut pas déclencher le rebuild JetBrains : c'est l'IDE qui pilote la surcouche jb-…. Il faut donc enchaîner avec le geste PhpStorm ci-dessous.

Le rebuild PhpStorm : « Rebuild and Restart Container »

Le geste manuel qui termine le travail, dans PhpStorm :

  1. Ouvrez .devcontainer/devcontainer.json.
  2. Dans la gouttière (ou via l'icône Dev Container), choisissez « Rebuild and Restart Container ».

Rebuild ≠ Recreate ≠ Restart

  • Restart — redémarre le conteneur existant à partir de la même image jb-…. Ne prend aucun changement du Dockerfile.
  • Recreate — recrée le conteneur, mais toujours à partir de l'image jb-… déjà présente. N'aide pas non plus.
  • Rebuild — reconstruit la surcouche jb-<hash>-uid en repartant du FROM …/kirexo-dev:php8.5. C'est le seul qui propage le changement — à condition que la base ait été rafraîchie au préalable par castor devcontainer:refresh.

Cache JetBrains tenace

Si le Rebuild ne semble pas prendre le nouveau contenu, castor devcontainer:refresh a déjà fait le stop php + docker rmi jb-… nécessaires pour casser le cache. Relancez simplement « Rebuild and Restart Container » dans PhpStorm.

Vérifier

L'image en cours est à jour quand :

  • le dashboard de session Claude n'affiche plus l'alerte de retard au tour suivant ;
  • optionnellement, depuis le conteneur, cat /etc/kirexo-dev.ref reflète un SHA récent (postérieur au dernier commit touchant le Dockerfile).

Voir aussi