Firebase-tools: Répertorier et supprimer les déploiements

@Nowaker C'est définitivement sur notre radar et quelque chose que nous cherchons à améliorer

salut @brendanlim des mises à jour ici ? Nous constatons également un chargement infini dans le module d'hébergement, il semble que nous ayons trop de déploiements :(

Merci!

Error: too_big: The data requested exceeds the maximum size that can be accessed with a single request. at r (rs=AON9PunUVzISsT9OTTHxul9qDyFtbYjNGA:8597) at H (third_party/javascript/firebase/firebase_js_minified.jslib:126) at Object.eval [as H] (third_party/javascript/firebase/firebase_js_minified.jslib:206) at eval (third_party/javascript/firebase/firebase_js_minified.jslib:190) at Kh.g.Id (third_party/javascript/firebase/firebase_js_minified.jslib:196) at yh.Id (third_party/javascript/firebase/firebase_js_minified.jslib:186) at qh.eval [as zg] (third_party/javascript/firebase/firebase_js_minified.jslib:184) at th (third_party/javascript/firebase/firebase_js_minified.jslib:178) at WebSocket.ua.onmessage (third_party/javascript/firebase/firebase_js_minified.jslib:177) at WebSocket.b [as __zone_symbol___onmessage] (rs=AON9PunUVzISsT9OTTHxul9qDyFtbYjNGA:8568) at w.invokeTask (rs=AON9PunUVzISsT9OTTHxul9qDyFtbYjNGA:8611) at u.runTask (rs=AON9PunUVzISsT9OTTHxul9qDyFtbYjNGA:8601) at WebSocket.invoke (rs=AON9PunUVzISsT9OTTHxul9qDyFtbYjNGA:8613)

@brendanlim @mbleigh Une mise à jour à ce sujet ? Notre historique de déploiement ne cesse de croître, chaque CI construit à la fois, et il est au-delà de nos capacités humaines de continuer à les supprimer !

Nous sommes conscients du problème et réfléchissons à la meilleure façon de le résoudre. En général, nous ne voulons pas que vous vous inquiétiez d'avoir un historique croissant de versions. Curieux pour tous ceux qui rencontrent cela (votez avec emoji sur ce commentaire) : que préférez-vous ?

• :tada: La possibilité de répertorier et éventuellement de supprimer par lots les anciennes versions
• :+1: Les anciennes versions ne sont conservées que pendant un certain temps à moins d'être "épinglées" d'une manière ou d'une autre
• :heart: Seul un certain nombre d'anciennes versions sont conservées à moins d'être "épinglées" d'une manière ou d'une autre

« La possibilité de répertorier et éventuellement de supprimer par lots les anciennes versions » est une primitive. Les API sont construites à l'aide de primitives. Ces primitives permettent aux utilisateurs de réaliser ce qu'ils veulent sans déranger personne (dans ce cas, vous @mbleigh).

Les deux autres sont des fonctionnalités de haut niveau. Ils sont cool. Mais vient alors une question : comment épingler ou désépingler la version via l'API ou firebase-tools ? Comme vous pouvez l'imaginer, une fois de plus, quelqu'un devra cliquer sur la liste dans l'interface utilisateur de Firebase, comme pour supprimer les anciens déploiements aujourd'hui. :rofl:

Pour résumer, les fonctionnalités de haut niveau sont excellentes et nécessaires, mais les primitives CRUD dans l'API sont très importantes pour des outils tels que Google Cloud Platform ou Firebase.

@Nowaker Je ne suis pas en désaccord, et les deux sont importants. Il est juste de dire que c'est une fausse dichotomie entre la première option et les deux autres. FWIW, afin de mettre en œuvre les deux deuxièmes options, nous devrions de toute façon mettre en œuvre tout ce qui est nécessaire pour la première.

Ce truc est définitivement sur notre radar, mais je n'ai pas de détails sur quand nous aurons quelque chose à montrer.

Je me contenterais d'une case à cocher pour sélectionner toutes / plusieurs entrées sur une page et les supprimer en une seule fois. Permet également de fermer la boîte de dialogue de confirmation en appuyant sur Entrée pour confirmer.

Vous ne pouvez pas non plus masquer la fonctionnalité de suppression. En ce moment vous :

1. Rollover de la ligne de déploiement.
2. Cliquez sur le menu à trois points.
3. Cliquez sur supprimer pour appeler la confirmation.
4. Cliquez à nouveau sur supprimer.

Si chaque ligne avait son propre bouton de suppression, et si vous pouviez maintenir la touche Maj enfoncée pour contourner la confirmation, vous pourriez les survoler.

Une API REST pour répertorier et supprimer les déploiements est-elle disponible, si l'on souhaite implémenter cette fonctionnalité par lui-même (ou même l'implémenter dans firebase-tools et soumettre un PR) ? Si les points de terminaison ne sont tout simplement pas là, je peux voir en quoi cela pourrait être un problème de blocage. Est-ce sur n'importe quel type de feuille de route avec quelque chose de similaire à une date d'échéance ?

des nouvelles à ce sujet? Il serait certainement utile d'avoir un moyen simple de supprimer les déploiements précédents dans CLI. Merci pour le bon travail.

Aucune nouvelle à ce sujet pour le moment, mais c'est un domaine d'intérêt actif pour l'équipe. Merci pour votre patience!

des nouvelles à ce sujet? Nous en avons tellement que nous devons les supprimer manuellement, un par un.

J'apprécierais aussi vraiment des progrès sur ce point !

Nous effectuons actuellement beaucoup de travail sur notre infrastructure de déploiement, ce qui prendra un peu de temps avant de se concrétiser. Cette question est définitivement dans notre esprit pendant que nous effectuons ce travail.

@mbleigh hey que diriez-vous de verrouiller ce sujet. J'aimerais être notifié quand c'est fait, mais je ne veux vraiment pas lire tous les commentaires "moi aussi".

"Seul un certain nombre d'anciennes versions sont conservées à moins qu'elles ne soient " épinglées " d'une manière ou d'une autre ", c'est exactement ce dont nous avons besoin.

L'autre problème que j'ai, c'est que lorsque je regarde cette liste de déploiements, je n'ai aucune idée de qui est lequel. Je version mon application de plusieurs manières, y compris la version dans package.json, et une notion de "builds", donc je pourrais également fournir une version et/ou build # à firebase deploy , et puis si cela pourrait être répertorié dans la liste des versions déployées, ce serait fantastique. Dans l'état actuel des choses, je vois 100 versions déployées et je n'ai aucune idée de laquelle est laquelle.

@rtm Vous pouvez spécifier un message pour les déploiements qui s'affiche dans la liste des déploiements :

firebase deploy --message "build 1234"

L'option n'est pas répertoriée sur les pages de documentation, mais elle est répertoriée lors de l'exécution :
firebase help deploy

@a-xin Merci. J'avais totalement raté ça et c'est très utile !

Ce serait formidable si la priorité de ce problème pouvait être augmentée, car nous déployons en continu chaque commit git, et chaque déploiement représente quelques centaines de Mo. Ce serait bien si nous pouvions également intégrer des commandes pour nettoyer les anciens déploiements dans le script du CD, afin de réduire la consommation globale de stockage.

Pour contourner le problème, serait-il possible de réutiliser les fichiers dont le nom et le contenu n'ont pas changé (selon certains hash) ?

Par exemple, si Webpack génère des morceaux avec des hachages stables (par exemple en utilisant HashedModuleIdsPlugin ), ces fichiers sont-ils téléchargés à chaque déploiement (même s'ils n'ont vraiment pas changé) ?

Cela pourrait réduire considérablement le nombre de mises à jour de fichiers sur chaque déploiement (jusqu'à des kilo-octets de notre code d'application, si les bibliothèques des fournisseurs n'ont pas changé).

Ce n'est pas une priorité pour nous. Nous travaillons sur l'habilitation
infrastructures pour s'attaquer à ce problème maintenant, mais il y a de grands changements
nécessaire de faire ce que nous voulons faire. Cela prendra du temps, merci pour le
rétroaction et votre patience.

Le dimanche 25 février 2018, 15h32 Denis Loginov [email protected]
a écrit:

Comme solution de contournement temporaire, serait-il possible de réutiliser les fichiers dont
le nom et le contenu du fichier n'ont pas changé (selon certains hash) ?

Par exemple, si Webpack génère des morceaux avec des hachages stables (par exemple, en utilisant
HashedModuleIdsPlugin), ces fichiers sont-ils téléchargés à chaque déploiement (même
bien qu'ils n'aient vraiment pas changé) ?

Cela pourrait réduire considérablement le nombre de mises à jour de fichiers sur chaque
déploiement (jusqu'à des kilo-octets de notre code d'application, si les bibliothèques du fournisseur n'ont pas
changé).

-
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU
.

Je suis content de voir que c'est une priorité. Je suis sur le plan Spark et j'ai une application Web d'environ 20 Mo. J'ai été un peu libéral avec mes déploiements, j'en ai donc 300 à parcourir et à supprimer. ??

En plus du nombre limité de déploiements dans l'histoire, j'aime aussi l'idée de @dinvlad de réutiliser les fichiers.

@sejr, une chose que je fais qui aide est d'utiliser le clavier autant que possible.
Je clique sur les ellipses, appuyez sur la flèche vers le bas puis entrez, puis le bouton de tabulation 3 fois puis entrez
Et répétez... j'espère que cela vous aidera.

@mbleigh Des nouvelles ou une progression à ce sujet ?

@mbleigh peux-tu nous donner un statut ?

@mbleigh Dans l' attente de plus de transparence. Peut-être pourriez-vous en dire plus sur la feuille de route générale des outils Firebase et les plans concernant ce problème ?
(C'est la question la plus votée d'ailleurs, presque le double des voix par rapport à la deuxième plus élevée).

Désolé pour le long retard pris pour résoudre ce problème - c'est en haut de notre liste, mais nous avons massivement investi dans un projet d'infrastructure qui jette les bases pour entreprendre de nombreux petits projets comme celui-ci.

Je ne peux pas promettre de délais exacts, mais cela n'a certainement pas été oublié.

Peut-être pas oublié mais sûrement ignoré . Un déploiement peut être supprimé dans l'interface utilisateur en quelques clics - il n'y a aucune raison pour que le même ne puisse pas être facilement exposé via l'API. Je suis extrêmement déçu par la feuille de route du produit Firebase, ainsi que par le sort de Divshot.

Je comprends la frustration, vraiment. Cette question est traitée par le travail
nous faisons maintenant et espérons vous apporter à tous dans un proche avenir.

Le vendredi 29 juin 2018, 01h01 Damian Nowak [email protected] a écrit :

Peut-être pas oublié mais sûrement ignoré . Un déploiement peut être supprimé
dans l'interface utilisateur en quelques clics - il n'y a aucune raison pour que la même chose ne puisse pas être
facilement exposé via l'API. Je suis extrêmement déçu par le produit Firebase
feuille de route, ainsi que le sort de Divshot.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU
.

@mbleigh

mais il y a de grands changements nécessaires pour faire ce que nous voulons faire.

Peut-être que les masses bouillonnantes seraient pacifiées par un vague mouvement de la main suffisamment vague sur ce que sont ces grands changements et quelles autres caractéristiques bouleversantes ils permettraient. À défaut, il n'est pas déraisonnable pour certaines personnes de mettre leurs sous-vêtements dans une torsion à propos de ce qui semble simplement ignorer la fonctionnalité, car elle dure maintenant depuis près de deux ans.

C'est assez simple - Firebase Hosting n'a jamais eu d'API publique, et la méthode actuelle pour répertorier et supprimer les déploiements dans la console n'est pas bien adaptée à la publicité. Étant donné que la CLI est open source, nous devons nous assurer que toutes les actions exposées à travers elle sont évolutives de manière appropriée.

Nous sommes en train de migrer une grande partie de Firebase Hosting vers l'infrastructure de Google, ce qui le rendra plus évolutif et fournira également une base solide pour disposer correctement d'API pour les choses. Cet effort est très bon pour la santé à long terme de Firebase Hosting, mais a été un investissement substantiel pour l'équipe qui a entraîné une longue période sans progrès apparent.

J'apprécie que beaucoup d'entre vous se sentent fortement à ce sujet - si vous contactez l'assistance, nous serons heureux d'élaguer manuellement vos anciens déploiements dans l'intervalle. Nous espérons que l'attente ne sera pas beaucoup plus longue, mais comme pour tout logiciel, choisir des dates exactes pour les choses est généralement une mauvaise idée.

J'espère que cela clarifie un peu les choses, et merci à tous les utilisateurs de Firebase Hosting d'avoir été avec nous 😄

@mbleigh Merci beaucoup pour l'

@mbleigh Je ne sais pas pourquoi vous devez rendre cette tâche dépendante d'une API publique ou de tout changement d'infrastructure.

Cela peut être résolu à court terme avec un bouton dans la console Firebase "Élaguer les anciens déploiements".

Étant donné que la console effectue déjà des appels vers le backend, elle peut obtenir une liste de tous les déploiements, puis appeler la suppression. Je suppose que l'API sur le backend ne prend pas une liste de déploiements par lots, donc ce bouton peut causer des problèmes si vous le faites de manière synchrone avec un déploiement à la fois.

Quoi qu'il en soit, le fait est de ne pas trop concevoir une solution lorsque tout ce que vous avez à faire est d'ajouter un bouton à une API déjà établie dans votre backend. Surtout, ne faites pas attendre vos utilisateurs 2 ans pour cela.

Pas du tout professionnel.

Je ne sais pas de quoi tout le monde se plaint. C'est RELAXANT de supprimer les anciens déploiements un par un. Je viens d'effacer un arriéré de 72. Ensuite, il y a eu une double vérification pour m'assurer que je les avais tous (j'en ai raté un) - encore une fois très satisfaisant. Je me sentais vertueux et oserais-je dire SUPÉRIEURE. Prendre soin des détails; vérifications nécessaires. Rigueur administrative ! Mon seul regret était de ne pas avoir PLUS à éclaircir. En fait, j'ai dû jouer au solitaire pendant UNE HEURE ENTIÈRE par la suite, juste pour me sentir suffisamment bien pour passer à ma prochaine tâche.

Et deux ans (et ça continue) pour obtenir cette fonctionnalité ?!? Pfftt. Tout le monde sait que les ingénieurs doivent PRENDRE SOIN de bien faire ces choses ! Et c'est un BUDGET énorme qui est nécessaire. Je veux dire, pensez à tous les efforts déployés par WAYMO et le reste d'Alphabet. Google ne pouvait PAS POSSIBLEMENT se permettre de consacrer plus de ressources à cette fonctionnalité.

Et en plus, nous ne sommes que des DÉVELOPPEURS ! DOUBLE Pfftt. Comment voulez-vous que Google survive en mettant les DÉVELOPPEURS en tête de file ?!? Je veux dire vraiment!

Non, pour le bien de nous tous, et en particulier pour notre bien-être, je vote personnellement pour que l'équipe de développement ici continue à travailler dessus pendant AU MOINS deux ans avant de mettre en œuvre cette fonctionnalité. Pour l'amour de Dieu, soyez prudent ! Ne soyez pas téméraire ; ne soyez pas pressé !

Et pour l'amour du ciel, ne faites rien d'impulsif comme avoir une fonction temporaire d'un bouton de suppression rapide ou quelque chose du genre ; cela détournerait simplement des ressources de choses beaucoup plus importantes.

Tout bon tel quel ; veuillez ne faire AUCUN changement à votre processus, comme, par exemple, des changements de GESTION !

Oups, faut y aller. C'est l'heure de ma sieste (je suis épuisé de toute la concentration nécessaire pour supprimer tous ces déploiements). Et en plus avec un temps aussi productif, je mérite certainement un peu de temps libre !

J'en ai 125 à supprimer.

J'ai l'impression qu'il y a un peu de sarcasme dans ce fil... 🙃

Les gens, je reçois vraiment la frustration. Pour réitérer une déclaration de mon commentaire précédent : si vous contactez le support , nous serons heureux d'élaguer manuellement vos anciens déploiements en votre nom dans l'intervalle . Faites-nous savoir combien d'anciennes versions vous souhaitez conserver.

Quant à savoir pourquoi nous ne publions pas de solution provisoire de pansement -- eh bien, l'intervention de soutien est notre pansement. Nous préférerions ne pas brûler des ressources d'ingénierie limitées sur un système que nous travaillons activement à remplacer, c'est pourquoi cela se retrouve dans une situation un peu difficile.

Oh écoutez, quelqu'un semble avoir laissé tomber un élément qui pourrait être pertinent pour ce fil...

PS Nous travaillons toujours sur une meilleure solution automatisée, mais en attendant, c'est un bien meilleur pansement. ??

Merci d'avoir pris le temps de fournir une solution de contournement.

Le script dans l'essentiel ci-dessus fonctionne bien en termes de suppression des versions, mais je ne vois pas mon utilisation du stockage baisser (cela prend-il un certain temps pour recalculer cela après la suppression des versions ?)

cela prend-il un certain temps pour recalculer cela après les suppressions des versions ?

D'après mon expérience, oui. Même si vous utilisez l'interface graphique pour supprimer manuellement un tas de versions, il faut un certain temps pour que les numéros d'utilisation changent.

Merci vraiment @mbleigh de nous avoir fourni un bien meilleur

Des mises à jour @mbleigh ?

Avez-vous regardé l'API de repos d'hébergement @alexanderwhatley ce n'est pas une solution d'interface

Hébergement API REST

Avez-vous regardé @jackcw ? Parce que je ne peux trouver que les méthodes create et list . Pas delete méthode

Je ne l'ai pas réellement utilisé, mais pour autant que je sache, il y a une suppression sur le point de terminaison des versions et la liste des versions inclut l'objet de version.

Désolé mon mauvais. J'ai mal compris le sens des versions et des versions. Vous pouvez désormais supprimer les anciennes versions appelées versions avec l'API.

J'ai créé un petit script shell qui est exécuté une fois par jour avec une tâche cron pour supprimer toutes les anciennes versions.
Voici l' essentiel . Il faut jq pour analyser le JSON. Il fait essentiellement ce que @jackcw a écrit : il itère sur toutes les versions et les supprime.

Je ne suis pas un expert dans l'écriture de scripts shell ou jq - mais le résultat est ce qui compte, je suppose. Le script fonctionne de manière assez fiable pour moi. N'hésitez pas à l'utiliser vous-même.

Identifiant de suivi interne : 113235359

Des mises à jour à ce sujet ?

Il est activement travaillé. ??

Salut tout le monde!

Vous pouvez désormais gérer la conservation de l'historique des versions dans la console Firebase :

Pour ceux d'entre vous qui ont de grands sites, cela devrait vous aider à réduire les coûts.

Pour le bénéfice de tous, la fonctionnalité ci-dessus dont parle

Merci pour la fonctionnalité ! Il semble qu'il y ait quand même quelques bugs.

@twistedpair :cry: hein, pouvez-vous contacter l'assistance Firebase, de préférence avec l'erreur que vous obtenez dans le panneau Réseau des outils de développement ? Ce n'est certainement pas censé arriver.

La fonctionnalité semble ne pas fonctionner, nous avons une limite supérieure de 1 version dans les paramètres mais une tonne de versions dans la liste qui n'ont jamais été supprimées !

@sharno

Cela fonctionne parfaitement sur nos projets.
Nous avons une limite de 10 builds et à partir de la build 11, ils sont "auto-supprimés"

@billiaug Merci

Je l'ai remis à un certain nombre et il a commencé à fonctionner. Je pense que cela pourrait être dû au fait que nous n'avions pas défini cette valeur auparavant, donc lorsque j'ai ouvert la boîte de dialogue et que j'ai vu 1, j'ai supposé qu'elle était déjà appliquée, mais ce n'était pas le cas.

J'ai remarqué la même chose que @sharno. Les paramètres par défaut définissent la valeur sur 1, mais cela ne prend effet que lorsque les paramètres sont ouverts et que j'ai cliqué sur _Enregistrer_ pour la première fois. Ensuite, tout fonctionne comme prévu.

Pour répliquer sur un nouveau projet Firebase, déployez un site plusieurs fois afin qu'il y ait quelques déploiements dans l'historique des versions. Ouvrez les _Paramètres de l'historique des versions_ qui affiche une valeur par défaut de 1, puis cliquez sur _Enregistrer_. Actualisez la page et tous les déploiements précédents, à l'exception du déploiement actuel, doivent avoir le statut _Auto-deleted_.

Peut-être que le modal _Paramètres de l'historique des versions_ devrait mentionner ou refléter que le paramètre n'est pas en vigueur par défaut et nécessite une action de l'utilisateur pour être activé. Exemple:

Ou quelque chose de différent, permettant aux utilisateurs de supprimer une valeur :

Au minimum, l' aide de Firebase - Définir la limite pour les versions conservées devrait mieux décrire les valeurs par défaut.

J'ai une requête similaire, mais pas pour l'hébergement firebase, plutôt pour les fonctions firebase. Chaque déploiement de fonctions prend plus de 400 Mo d'espace de stockage Firebase. Je ne suis pas un utilisateur expert du cli firebase, mais accéder au registre des conteneurs GCP offre la possibilité de supprimer les conteneurs un par un

La console firebase offre-t-elle un moyen de supprimer automatiquement les anciens conteneurs de fonctions, comme c'est le cas actuellement pour les versions d'hébergement ?

PS : dois-je ouvrir un nouveau numéro pour ça ?

@DibyodyutiMondal est définitivement un nouveau numéro.

@DibyodyutiMondal - avez-vous ouvert un nouveau numéro ? Si c'est le cas, s'il vous plaît mettre un lien ici, c'est donc plus facile à trouver.