Codes d’erreur
Ce que signifie chaque code GH- d’un log de déploiement, pourquoi il est apparu et comment le corriger.
Quand un déploiement échoue pour une cause connue, Gheima termine le log de déploiement par un code comme [GH-OOM] et affiche le même code dans le panneau « Ce qui a échoué » du déploiement. Un code a toujours le même sens : vous pouvez le rechercher ou le citer dans un ticket de support.
Un échec sans code a été expliqué par une lecture de votre log par l’IA. Cette explication est une piste à vérifier dans le log, elle n’a donc pas d’entrée ici.
GH-PLATFORM · Cet échec vient de notre côté, pas de votre application.#
- Cause
- Le build a rencontré une erreur interne de la plateforme. Ni votre dépôt ni vos réglages n'en sont la cause.
- Correction
- Relancez le déploiement. Si l'échec se répète à l'identique, ouvrez un ticket en mentionnant ce déploiement — notre équipe a déjà les détails.
GH-OOM · Le processus a manqué de mémoire et a été arrêté.#
- Cause
- Arrêt avec le code 137 — le conteneur a atteint sa limite mémoire ; ce n'est pas un plantage de votre code.
- Correction
- Augmentez la mémoire dans Réglages → Ressources (jusqu’au plafond de votre offre). Si c’est le build qui sature, réduisez ce qu’il charge d’un coup — moins de workers parallèles, une étape de bundle plus petite.
GH-REPO-SIZE · Le dépôt est trop volumineux pour être construit.#
- Cause
- Le clone a dépassé la limite de disque avant même le début du build. En général : des artefacts de build commités, des dépendances vendorisées ou de gros binaires dans l'historique git.
- Correction
- Ajoutez les dossiers de build et de dépendances au .gitignore, déplacez les gros fichiers vers le stockage objet, et définissez un répertoire racine dans Réglages → Build & exécution si un seul sous-dossier doit être construit.
GH-NO-START · Rien n’indique à la plateforme comment démarrer votre application.#
- Cause
- L'image a été construite, mais aucune commande de démarrage n'a été détectée — ni script `start` dans votre manifeste, ni commande configurée sur le service.
- Correction
- Définissez une commande de démarrage dans Réglages → Build & exécution (ex. `node dist/server.js`), ou ajoutez un script `start` à votre package.json. Vérifiez qu’elle écoute sur le port configuré pour ce service.
GH-NPM-ERESOLVE · Vos dépendances sont en conflit et npm a refusé de les installer.#
- Cause
- npm a rencontré un conflit ERESOLVE de peer-dependencies : deux paquets exigent des versions incompatibles de la même dépendance.
- Correction
- Reproduisez-le en local avec un `npm install` propre (supprimez d’abord node_modules et package-lock.json), corrigez le conflit de version signalé, puis commitez le lockfile mis à jour. N’utilisez pas --force pour le masquer.
GH-PRERENDER-ENV · Votre framework a exécuté votre code pendant le build, sans environnement.#
- Cause
- Le build a échoué au pré-rendu des pages. Les variables d'environnement d'exécution ne sont pas disponibles pendant le build tant que vous ne les exposez pas : tout accès à une base ou à une API au moment du build reçoit donc du vide.
- Correction
- Ouvrez Environnement → Variables de build et exposez uniquement les clés nécessaires (le panneau vous les suggère). Sinon, déplacez cette récupération de données au moment de la requête, où l’environnement complet est disponible.