Firebase-tools: Bereitstellungen auflisten und löschen

@Nowaker Das ist definitiv auf unserem Radar und etwas, das wir verbessern

hey @brendanlim gibt es hier Updates? Wir sehen auch unendliches Laden im Hosting-Modul, es sieht so aus, als hätten wir zu viele Bereitstellungen :(

Vielen Dank!

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 Irgendein Update dazu? Unsere Bereitstellungshistorie wächst ständig, jedes CI erstellt nach dem anderen, und es übersteigt unsere menschlichen Fähigkeiten, mit dem Löschen Schritt zu halten!

Wir sind uns des Problems hier bewusst und überlegen, wie wir es am besten angehen können. Im Allgemeinen möchten wir nicht, dass Sie sich Sorgen über eine wachsende Versionsgeschichte machen. Neugierig auf jeden, der darauf stößt (Stimme mit Emoji zu diesem Kommentar): Was würde dir am besten gefallen?

• :tada: Die Möglichkeit, alte Versionen aufzulisten und möglicherweise stapelweise zu löschen
• :+1: Alte Versionen werden nur für eine bestimmte Zeit aufbewahrt, es sei denn, sie werden irgendwie "gepinnt"
• :heart: Nur eine bestimmte Anzahl alter Versionen wird beibehalten, es sei denn, sie werden irgendwie "gepinnt"

"Die Möglichkeit, alte Versionen aufzulisten und möglicherweise im Stapel zu löschen" ist primitiv. APIs werden mit Primitiven erstellt. Mit diesen Primitiven können Benutzer alles erreichen, was sie wollen, ohne jemanden zu stören (in diesem Fall @mbleigh).

Die anderen beiden sind High-Level-Features. Sie sind cool. Aber dann kommt eine Frage: Wie kann ich die Version über API oder firebase-tools anheften oder entfernen? Wie Sie sich vorstellen können, muss sich wieder einmal jemand nacheinander durch die Liste in der Firebase-Benutzeroberfläche klicken, genau wie heute, um alte Bereitstellungen zu löschen. :rofl:

Zusammenfassend lässt sich sagen, dass High-Level-Funktionen großartig sind und benötigt werden, aber CRUD-Primitive in der API sind für Tools wie die Google Cloud Platform oder Firebase sehr wichtig.

@Nowaker Ich bin anderer Meinung und beides ist wichtig. Es ist fair zu sagen, dass es eine falsche Dichotomie zwischen der ersten Option und den anderen beiden ist. FWIW, um die zweiten beiden Optionen zu implementieren, müssten wir sowieso so ziemlich alles Notwendige für die erste implementieren.

Dieses Zeug ist definitiv auf unserem Radar, aber ich habe keine genauen Angaben, wann wir etwas zu zeigen haben.

Ich würde mich mit einer Checkbox begnügen, um alle / mehrere Einträge auf einer Seite auszuwählen und auf einmal zu löschen. Machen Sie es auch möglich, den Bestätigungsdialog zu schließen, indem Sie zur Bestätigung die Eingabetaste drücken.

Sie konnten die Löschfunktion auch nicht ausblenden. Im Moment du:

1. Rollover-Bereitstellungszeile.
2. Klicken Sie auf das Drei-Punkte-Menü.
3. Klicken Sie auf Löschen, um die Bestätigung aufzurufen.
4. Klicken Sie erneut auf Löschen.

Wenn jede Zeile eine eigene Löschtaste hätte und Sie die Umschalttaste gedrückt halten könnten, um die Bestätigung zu umgehen, könnten Sie durch sie hindurchfliegen.

Ist eine REST-API zum Auflisten und Löschen von Bereitstellungen verfügbar, wenn man diese Funktionalität selbst implementieren möchte (oder sogar in Firebase-Tools implementieren und eine PR einreichen möchte)? Wenn die Endpunkte einfach nicht vorhanden sind, kann ich sehen, dass dies ein blockierendes Problem sein könnte. Steht dies auf einer Art Roadmap mit so etwas wie einem Fälligkeitsdatum?

Gibt es darüber irgendwelche Neuigkeiten? Es wäre definitiv hilfreich, eine einfache Möglichkeit zum Entfernen früherer Bereitstellungen in der CLI zu haben. Danke für die gute Arbeit.

Es gibt noch keine Neuigkeiten dazu, aber es ist ein Bereich von aktivem Interesse für das Team. Danke für Ihre Geduld!

Gibt es darüber irgendwelche Neuigkeiten? Wir haben so viele, die wir einzeln manuell entfernen müssen.

Würde mich auch

Wir arbeiten gerade viel an unserer Bereitstellungsinfrastruktur, die einige Zeit in Anspruch nehmen wird. Dieses Thema beschäftigt uns definitiv, während wir diese Arbeit machen.

@mbleigh hey, wie wäre es mit dem Sperren dieses Themas. Ich würde gerne benachrichtigt werden, wenn es fertig ist, aber ich möchte wirklich nicht alle "Ich auch"-Kommentare lesen.

"Nur eine bestimmte Anzahl alter Versionen wird beibehalten, es sei denn, sie werden irgendwie "gepinnt"" ist genau das, was wir brauchen.

Das andere Problem, das ich habe, ist, dass ich, wenn ich mir diese Liste der Bereitstellungen ansehe, keine Ahnung habe, welche welche ist. Ich versioniere meine App auf verschiedene Weise, einschließlich der Version in package.json und einem Begriff von "Builds", also könnte ich auch eine Version und/oder einen Build # für firebase deploy bereitstellen, und dann, wenn das so ist in der Liste der bereitgestellten Versionen aufgeführt werden könnte, wäre es fantastisch. So wie es aussieht, sehe ich 100 bereitgestellte Versionen und habe keine Ahnung, welche welche ist.

@rtm Sie können eine Nachricht für

firebase deploy --message "build 1234"

Die Option ist auf den Dokumentationsseiten nicht aufgeführt, wird jedoch bei der Ausführung aufgeführt:
firebase help deploy

@a-xin Danke. Das hatte ich total übersehen und es ist sehr nützlich!

Es wäre großartig, wenn die Priorität dieses Problems erhöht werden könnte, da wir eine kontinuierliche Bereitstellung jedes Git-Commits durchführen und jede Bereitstellung ein paar hundert MB umfasst. Wäre schön, wenn wir auch einige Befehle zum Aufräumen alter Deployments in das CD-Skript integrieren könnten, um den Gesamtspeicherverbrauch zu reduzieren.

Wäre es als Workaround möglich, die Dateien wiederzuverwenden, deren Dateiname und Inhalt sich nicht geändert haben (laut einem Hash)?

ZB wenn Webpack Chunks mit stabilen Hashes generiert (zB mit HashedModuleIdsPlugin ), werden diese Dateien bei jedem Deploy hochgeladen (auch wenn sie sich wirklich nicht geändert haben)?

Dies könnte die Anzahl der Dateiaktualisierungen bei jeder Bereitstellung erheblich reduzieren (bis auf KB unseres Anwendungscodes, wenn sich die Anbieter-Bibliotheken nicht geändert haben).

Dies hat für uns keine geringe Priorität. Wir arbeiten an der Ermöglichung
Infrastruktur, um dieses Problem jetzt anzugehen, aber es gibt große Änderungen
notwendig, um das zu tun, was wir tun wollen. Es wird noch etwas dauern, danke für die
Feedback und Ihre Geduld.

Am So, 25. Februar 2018, 15:32 Denis Loginov [email protected]
schrieb:

Wäre es als vorübergehende Problemumgehung möglich, die Dateien wiederzuverwenden, deren
Dateiname und Inhalt hat sich nicht geändert (laut einem Hash)?

ZB wenn Webpack Chunks mit stabilen Hashes generiert (zB mit
HashedModuleIdsPlugin), werden diese Dateien bei jedem Deploy hochgeladen (sogar
obwohl sie sich wirklich nicht geändert haben)?

Dies könnte die Anzahl der Dateiaktualisierungen auf jedem erheblich reduzieren
Deployment (bis auf KB unseres Anwendungscodes, wenn die Anbieter-Bibliotheken dies nicht getan haben)
geändert).

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU
.

Ich freue mich zu sehen, dass dies eine Priorität ist. Ich habe den Spark-Plan und habe eine Webanwendung mit einer Größe von etwa 20 MB. Ich war bei meinen Bereitstellungen ein wenig liberal, also habe ich 300 zu durchlaufen und zu löschen. 😅

Neben der begrenzten Anzahl von Bereitstellungen in der Geschichte gefällt @dinvlad , Dateien

@sejr Eine Sache, die mir hilft, ist, die Tastatur so oft wie möglich zu verwenden.
Ich klicke auf die Ellipsen, drücke auf den Abwärtspfeil, dann gebe ich ein, dann dreimal die Tabulatortaste und dann gebe ich ein
Und wiederhole.....hoffentlich hilft das.

@mbleigh Irgendwelche Neuigkeiten oder Fortschritte dazu?

@mbleigh kannst du uns einen Status geben?

@mbleigh Wir freuen uns auf mehr Transparenz. Vielleicht könnten Sie mehr über die allgemeine Firebase-Tools-Roadmap und die Pläne in Bezug auf dieses Problem erläutern?
(Es ist übrigens die am höchsten gewählte Ausgabe, fast doppelt so viele Stimmen wie die zweithöchste).

Entschuldigen Sie die lange Verzögerung bei der Lösung dieses Problems – es steht ganz oben auf unserer Liste, aber wir haben stark in ein Infrastrukturprojekt investiert, das die Grundlage für viele kleinere Projekte wie dieses bildet.

Ich kann keine genauen Zeitpläne versprechen, aber das wurde definitiv nicht vergessen.

Vielleicht nicht vergessen, aber sicher ignoriert . Ein Deployment kann in der Benutzeroberfläche mit wenigen Klicks gelöscht werden – es gibt keinen Grund, warum es nicht einfach über die API verfügbar gemacht werden könnte. Ich bin extrem enttäuscht von der Firebase-Produkt-Roadmap sowie vom Schicksal von Divshot.

Ich verstehe die Frustration, wirklich. Dieses Problem wird von der Arbeit angegangen
Wir tun es jetzt und hoffen, Ihnen allen in naher Zukunft etwas bringen zu können.

Am Fr, 29.06.2018, 01:01 schrieb Damian Nowak [email protected] :

Vielleicht nicht vergessen, aber sicher ignoriert . Eine Bereitstellung kann gelöscht werden
in der Benutzeroberfläche mit ein paar Klicks - es gibt keinen Grund, warum das Gleiche nicht sein könnte
einfach über API verfügbar gemacht. Ich bin vom Firebase-Produkt extrem enttäuscht
Roadmap, sowie das Schicksal von Divshot.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU
.

@mbleigh

aber es sind große Veränderungen notwendig, um das zu tun, was wir tun wollen.

Vielleicht würden die brodelnden Massen durch einige entsprechend vage Handbewegungen besänftigt, was diese großen Veränderungen sind und welche anderen weltbewegenden Eigenschaften sie ermöglichen würden. Wenn dies nicht gelingt, ist es für einige Leute nicht unvernünftig, ihre Unterwäsche in eine Wendung zu bringen, die das Feature einfach zu ignorieren scheint, da es jetzt fast zwei Jahre dauert.

Es ist ziemlich einfach – Firebase Hosting hatte noch nie eine öffentliche API, und die aktuelle Methode zum Auflisten und Löschen von Bereitstellungen in der Konsole ist für die Veröffentlichung nicht gut geeignet. Da es sich bei der CLI um Open Source handelt, müssen wir sicherstellen, dass alle durch sie bereitgestellten Aktionen entsprechend skalierbar sind.

Wir sind dabei, einen großen Teil des Firebase-Hostings in die Google-Infrastruktur zu migrieren, um es skalierbarer zu machen und auch eine solide Grundlage für ordnungsgemäße APIs für Dinge zu schaffen. Diese Bemühungen sind sehr gut für die langfristige Gesundheit von Firebase Hosting, waren jedoch eine erhebliche Investition für das Team, die zu einer langen Zeit ohne erkennbare Fortschritte geführt hat.

Ich weiß zu schätzen, dass viele von Ihnen diesbezüglich ein starkes Gefühl haben. Wenn Sie sich an den Support wenden, können wir Ihre älteren Bereitstellungen in der Zwischenzeit gerne manuell bereinigen. Wir hoffen, dass die Wartezeit nicht mehr lange dauern wird, aber wie bei jeder Software ist es normalerweise eine schlechte Idee, genaue Daten für Dinge auszuwählen.

Ich hoffe, dies klärt die Dinge ein wenig und danke allen Firebase Hosting-Benutzern für Ihr Verständnis

@mbleigh Vielen Dank für die

@mbleigh Ich bin mir nicht sicher, warum Sie diese Aufgabe von einer öffentlichen API oder einer Infrastrukturänderung abhängig machen müssen.

Dies lässt sich kurzfristig mit einem Button in der Firebase-Konsole „Alte Deployments bereinigen“ beheben.

Da die Konsole bereits Aufrufe an das Back-End durchführt, kann sie eine Liste aller Bereitstellungen abrufen und dann delete aufrufen. Ich gehe davon aus, dass die API im Back-End keine Batchliste von Bereitstellungen verwendet, daher kann diese Schaltfläche einige Probleme verursachen, wenn Sie sie synchron mit einer Bereitstellung gleichzeitig ausführen.

Wie auch immer, der Punkt ist, dass Sie eine Lösung nicht überkonstruieren, wenn Sie nur eine Schaltfläche zu einer bereits etablierten API in Ihrem Backend hinzufügen müssen. Lassen Sie Ihre Benutzer insbesondere nicht 2 Jahre darauf warten.

Gar nicht professionell.

Ich weiß nicht, worüber alle meckern. Es ist ENTSPANNEND, alte Bereitstellungen einzeln zu löschen. Ich habe gerade einen Rückstand von 72 abgebaut. Dann wurde noch einmal überprüft, ob ich sie alle bekommen hatte (ich habe eine verpasst) – wieder sehr zufriedenstellend. Ich fühlte mich tugendhaft und wage es, SUPERIOR zu sagen. Auf Details achten; gebührende Sorgfalt. Administrative Sorgfalt! Ich bedauere nur, dass ich nicht MEHR zu klären hatte. Ich musste danach tatsächlich eine GANZE STUNDE Solitaire spielen, nur um mich gut genug zu fühlen, um zu meiner nächsten Aufgabe überzugehen.

Und zwei Jahre (und noch mehr), um diese Funktion zu bekommen?!? Pfft. Jeder weiß, dass Ingenieure SORGFÄLTIG sein müssen, um diese Dinge richtig zu machen! Und es ist ein riesiges BUDGET erforderlich. Ich meine, denk an all die Mühe, die WAYMO und der Rest von Alphabet auf sich nehmen. Google konnte es sich MÖGLICH nicht leisten, mehr Ressourcen in diese Funktion zu stecken.

Und außerdem sind wir nur ENTWICKLER! DOPPELpfft. Wie soll Google überleben, indem es ENTWICKLER an die Spitze der Warteschlange stellt?!? Ich meine es ernst!

Nein, zum Wohle von uns allen und vor allem zu unserem Wohlbefinden stimme ich persönlich dafür, dass das Entwicklerteam hier MINDESTENS weitere zwei Jahre weiter daran arbeitet, bevor es dieses Feature implementiert. Seien Sie um Gottes willen vorsichtig! Seien Sie nicht voreilig; lass dich nicht hetzen!

Und um Himmels willen, tun Sie nichts Impulsives wie eine temporäre Funktion einer Schnelllöschtaste oder ähnlichem; das würde nur Ressourcen von viel wichtigeren Dingen ablenken.

Alles gut wie es ist; Bitte nehmen Sie KEINE Änderungen an Ihrem Prozess vor, wie z. B. MANAGEMENT-Änderungen!

Ups, muss los. Zeit für mein Nickerchen (ich bin erschöpft von all der Konzentration, die erforderlich ist, um all diese Bereitstellungen zu löschen). Und außerdem habe ich mir bei so einer produktiven Zeit sicherlich eine Auszeit verdient!

Ich muss 125 davon löschen.

🤔 Irgendwie habe ich das Gefühl, dass in diesem Thread ein bisschen Sarkasmus passiert...

Leute, ich verstehe wirklich die Frustration. Um eine Aussage aus meinem vorherigen Kommentar zu wiederholen: Wenn Sie sich an den Support wenden, bereinigen wir Ihre älteren Bereitstellungen in der Zwischenzeit gerne manuell in Ihrem Namen . Teilen Sie uns einfach mit, wie viele alte Versionen Sie behalten möchten.

Warum wir keine vorläufige Pflasterlösung herausbringen – nun, die Support-Intervention ist unser Pflaster. Wir würden es vorziehen, keine begrenzten Engineering-Ressourcen für ein System zu verbrauchen, an dessen Ersatz wir aktiv arbeiten, weshalb dies an einer schwierigen Stelle endet.

Oh, schau, jemand scheint einen Kernsatz fallen gelassen zu haben, der für diesen Thread relevant sein könnte ...

PS Wir arbeiten noch an einer besseren, automatisierten Lösung, aber in der Zwischenzeit ist dies ein viel besseres Pflaster. 😼

Vielen Dank, dass Sie sich die Zeit genommen haben, einen Workaround bereitzustellen.

Das Skript in der obigen Zusammenfassung funktioniert in Bezug auf das Löschen der Versionen einwandfrei, aber ich sehe nicht, dass meine Speichernutzung sinkt (dauert es eine Weile, dies nach dem Löschen der Versionen neu zu berechnen?)

dauert es eine Weile, dies nach dem Löschen der Versionen neu zu berechnen?

Nach meiner Erfahrung ja. Selbst wenn Sie die Benutzeroberfläche verwenden, um eine Reihe von Versionen manuell zu löschen, dauert es einige Zeit, bis sich die Nutzungszahlen ändern.

Vielen Dank an Pflaster zur Verfügung gestellt haben. :beten:

Irgendwelche Updates @mbleigh?

Haben Sie sich die Hosting-Rest-API @alexanderwhatley angesehen, es ist keine ?

Hosten der REST-API

Hast du dir das @jackcw angeschaut ? Weil ich nur die Methoden create und list kann. Keine delete Methode.

Ich habe es nicht wirklich verwendet, aber soweit ich sehen kann, gibt es eine Löschung auf dem Versionsendpunkt und die Liste der Releases enthält das Versionsobjekt

Es tut mir leid. Ich habe die Bedeutung von Versionen und Releases falsch verstanden. Sie können jetzt ältere Releases löschen, die mit der API als Versionen bezeichnet werden.

Ich habe ein kleines Shell-Skript erstellt, das einmal täglich mit einem Cron-Job ausgeführt wird, um alle alten Releases zu entfernen.
Hier ist das Wesentliche . Es erfordert jq , um das JSON zu parsen. Es macht im Grunde das, was @jackcw geschrieben hat: Es iteriert über alle Releases und löscht sie.

Ich bin kein Experte im Schreiben von Shell-Skripten oder jq - aber das Ergebnis zählt, denke ich. Das Skript funktioniert bei mir recht zuverlässig. Fühlen Sie sich frei, es selbst zu verwenden.

Interne Tracking-ID: 113235359

Irgendwelche Updates dazu?

Daran wird aktiv gearbeitet. 🙂

Hallo allerseits!

Sie können jetzt die Aufbewahrung Ihres Versionsverlaufs in der Firebase Console verwalten:

Für diejenigen unter Ihnen mit großen Websites sollte dies helfen, die Kosten niedrig zu halten.

Zum Nutzen aller ist das obige Feature, von dem @samtstern spricht, das,

Danke für die Funktion! Scheint aber noch einige Bugs zu geben.

@twistedpair :cry: huh, können Sie sich an den Firebase-Support

Die Funktion scheint nicht zu funktionieren, wir haben eine Obergrenze von 1 Version in den Einstellungen, aber eine Menge Versionen in der Liste, die nie gelöscht wurden!

@sharno

Es funktioniert perfekt in unseren Projekten.
Wir haben ein Limit von 10 Builds und ab Build 11 werden sie "automatisch gelöscht"

@billiaug Danke

Ich habe es wieder auf eine bestimmte Zahl eingestellt und es hat angefangen zu arbeiten. Ich denke, das könnte daran liegen, dass wir diesen Wert vorher nicht festgelegt haben. Als ich den Dialog öffnete und 1 sah, nahm ich an, dass er bereits angewendet wurde, aber das war nicht der Fall

Mir ist das gleiche aufgefallen wie @sharno. In den Standardeinstellungen wird der Wert auf 1 gesetzt, dies ist jedoch erst wirksam, wenn die Einstellungen geöffnet wurden und ich zum ersten Mal auf _Speichern_ geklickt habe. Danach funktioniert alles wie erwartet.

Um in einem neuen Firebase-Projekt zu replizieren, stellen Sie eine Site mehrmals bereit, damit der Versionsverlauf einige Bereitstellungen enthält. Öffnen Sie die _Versionsverlaufseinstellungen_, die einen Standardwert von 1 anzeigen, und klicken Sie dann auf _Speichern_. Aktualisieren Sie die Seite und alle vorherigen Bereitstellungen außer der aktuellen sollten den Status _Automatisch gelöscht_ haben.

Vielleicht sollte das Modal _Versionsverlaufseinstellungen_ erwähnen oder widerspiegeln, dass die Einstellung standardmäßig nicht wirksam ist und Benutzeraktionen aktiviert werden müssen. Beispiel:

Oder etwas anderes, das es Benutzern ermöglicht, einen Wert aufzuheben:

Zumindest Firebase Help - Limit für beibehaltene Versionen festlegen sollte die Standardeinstellungen besser beschreiben.

Ich habe eine ähnliche Abfrage, aber nicht für Firebase-Hosting, sondern für Firebase-Funktionen. Jede Funktionsbereitstellung benötigt über 400 MB des Firebase-Speicherplatzes. Ich bin kein erfahrener Benutzer der Firebase-Cli, aber wenn Sie zur GCP-Container-Registry gehen, können Sie die Container einzeln löschen

Bietet die Firebase-Konsole eine Möglichkeit, ältere Funktionscontainer automatisch zu löschen, wie es derzeit beim Hosten von Releases der Fall ist?

PS: Soll ich dafür ein neues Thema eröffnen?

@DibyodyutiMondal definitiv ein neues Thema.

@DibyodyutiMondal - hast du eine neue Ausgabe eröffnet? Wenn ja, fügen Sie bitte hier einen Link hinzu, damit es leichter zu finden ist.