J'ai eu cette erreur pendant près d'une heure, mais j'ai trouvé une solution résultant en un grand dilemme inquiétant. La solution a permis de réaliser que l'on ne peut pas exécuter gcloud app deploy alors qu'il y a une tâche dans la file d'attente des tâches à servir par la version du serveur à remplacer.
L'erreur était: ERREUR: (gcloud.app.deploy) Réponse d'erreur: [9] État de la build du cloud XXXXXXXXXXXX: ÉCHEC cette partie xxxx est une valeur base64 générée automatiquement.
La solution était la suivante: Suppression de toutes les tâches de la file d'attente des tâches
Question: Y a-t-il une solution de contournement ou je dois supprimer toutes les tâches de la file d'attente des tâches (comme je l'ai fait) avant le déploiement?
Détails: Le serveur est écrit en nodejs.
3 Réponses :
Je soupçonne que la nécessité de vider les files d'attente de tâches lorsque les tâches destinées à la version en cours de suppression pourrait être motivée par le "blocage de tête de ligne" virtuel qui se produirait dans ce cas, affectant d'autres services / versions dans le projet (les files d'attente de tâches sont partagées dans un projet) et peut-être même la fonctionnalité infra GAE associée.
Fondamentalement, réécrire une certaine version d'application / service va à l'encontre de l'objectif du contrôle de version (imaginez que git vous permette de changer le contenu du commit / refpoint associé à une certaine signature SHA!). Mais dans certains cas - par exemple lorsque la version est réellement utilisée pour implémenter un certain environnement d'exécution - c'est intentionnel.
Ce que vous avez décrit n'est pas le seul problème avec les déploiements GAE écraser une certaine version d'une application / service (à laquelle je n'avais pas pensé auparavant, BTW, merci pour cela!). Un autre est capturé dans Continu intégration / déploiement / livraison sur Google App Engine, trop risqué? .
Si vos déploiements avec réécriture de version sont en fait une tentative d'implémentation d'environnements de déploiement, vous voudrez peut-être également examiner quelques autres alternatives potentielles (meilleures à mon humble avis) comparées à Avantages de la mise en œuvre d'environnements CI / CD au niveau projet / application GAE par rapport au niveau service / module ?
Mmmm je ne sais pas comment cela résoudra le problème.
J'ai configuré mon compte de facturation, mais je n'ai pas résolu le problème.
J'ai eu le même problème, je suis revenu en arrière et j'ai correctement assuré que le compte de facturation était correctement configuré, puis cela a fonctionné pour moi ...
Ce n’est pas la seule raison pour laquelle le redéploiement de la même version (surtout en production) n’est pas une bonne idée, voir stackoverflow.com/questions/40192557/…
Merci @DanCornilescu pour cet aperçu du lien qui a été très utile. Je pense également que vous devriez donner une autre réponse sur mesure pour cette question, car les développeurs rechercheront en utilisant le message d'erreur ci-dessus et cela varie largement de celui du lien partagé, même si les causes semblent liées comme vous l'avez mentionné.
Est-ce que
gcloud app deploy --no-modifygénère un ID de version si l'ID de version n'est pas inclus dans la commande?Lorsque vous découvert < / a> - oui