Build — du code à l'image Docker

📍 Où trouver ça dans l'UI — Infra → onglet Builds (liste globale de tous les builds de l'app)

C'est quoi un Build ? L'opération qui prend ton code Git et en fait une image Docker — un paquet exécutable et reproductible que K8s peut lancer.

Le pipeline d'un Build

textCopier
Repository (code source)
     ↓
   git checkout <branch / tag / commit>
     ↓
   docker build (Dockerfile)
     ↓
   Image Docker dans le registry privé Wakastart
     ↓
   Disponible pour déploiement

Statuts d'un build

Comment déclencher un build

Une fois SUCCEEDED, l'image est disponible : tu peux la déployer dans un environnement via une ServiceInstance.

Diagnostiquer un build en échec

Si un build Wakastart termine en FAILED, le premier réflexe est de reproduire l'erreur localement avec docker build. Le builder Wakastart exécute exactement la même commande que toi en local — si elle passe en local, elle passe sur la plateforme.

Pour un diagnostic fiable, cloner le repo dans un dossier neuf avant de lancer le build :

bashCopier
git clone <url-du-repo> /tmp/build-check
cd /tmp/build-check
git checkout <branche-ou-commit-qui-échoue>
docker build -f <dockerfilePath> <buildContext>

C'est important parce qu'un dépôt de travail contient typiquement des artefacts qui n'existent pas côté Wakastart et qui peuvent masquer l'erreur :

• un node_modules/ installé localement (et qui contredit ce que pnpm install produit dans le Dockerfile)
• un dossier dist/ ou .next/ issu d'un build précédent
• un fichier .env local qui injecte des variables manquantes côté plateforme
• des binaires Prisma générés (@prisma/client) qui pourraient compenser un prisma generate oublié dans le Dockerfile
• un lockfile désynchronisé (pnpm-lock.yaml modifié mais non commité)

Un build dans un repo fraîchement cloné reproduit exactement le contexte du builder Wakastart : seuls les fichiers versionnés sont présents, rien d'autre. Si l'erreur ne se reproduit pas dans ces conditions, c'est qu'elle vient d'un artefact local, pas du code committé.

💡 Un .dockerignore bien écrit (excluant node_modules, .next, dist, .env*) protège déjà contre la plupart des fuites d'artefacts vers le contexte Docker — mais ne dispense pas du test en repo neuf si un doute persiste.