Échec du build ? Comprendre l’erreur avec l’IA

Un échec de build ne signifie pas que le serveur est en panne. La cause peut être une commande, une dépendance, une variable manquante, le chemin du Dockerfile ou un port incorrect. Ouvrez le déploiement en échec et vérifiez le message et l’heure de cette exécution.

Ouvrez Problèmes ou le déploiement en échec, puis choisissez Analyser l’échec lorsque cette option est disponible. L’IA utilise le contexte fourni par l’analyseur pour proposer des causes possibles et des étapes suivantes. Vérifiez ces conseils dans les journaux : un diagnostic ne garantit pas la correction.

Comparez les suggestions avec votre dépôt. Vérifiez la version du runtime, le répertoire racine, les commandes d’installation et de build, le mode de déploiement et le port. La configuration doit correspondre au code. Une modification de configuration peut suffire sans changer le code.

Si l’analyse propose des changements de code, examinez les fichiers et les différences avant d’appliquer une correction proposée dans le tableau de bord. Déployez une nouvelle version, puis vérifiez journaux et état de santé. Une analyse ne signifie pas que l’application a été automatiquement réparée ou déployée.

Vérifiez aussi les ressources connectées. La base gérée conserve des données structurées ; images, vidéos et pièces jointes utilisent S3. Pour obtenir de l’aide à l’intégration, fournissez les noms des variables et le contexte nécessaire sans publier mots de passe, jetons ou clés secrètes dans des journaux ou du contenu public.

Dans l’aide et l’assistance, décrivez le problème dans la langue du tableau de bord. Les premiers conseils couvrent builds, domaines, messagerie et stockage avant l’ouverture d’un ticket. Si le problème persiste, transmettez le numéro du déploiement, l’erreur et les étapes essayées. Le site et les guides existent en portugais, anglais, espagnol, français et allemand.