Firebase-tools: Enumerar y eliminar implementaciones

Creado en 2 sept. 2016  ·  62Comentarios  ·  Fuente: firebase/firebase-tools

Me acabo de dar cuenta de que el uso del alojamiento de Firebase ahora es de casi 1 GB. Mucho dado que nuestro sitio web tiene solo 20 MB.

nowaker@nwkr-desktop ~/projekty/virtkick/website (git)-[master] % du -hs build 
20M     build

Parece que todas las implementaciones anteriores las mantiene Firebase y están visibles en https://console.firebase.google.com/project/PROJECTNAME/hosting/main.

Eliminar 90 implementaciones una por una manualmente está fuera de discusión. Existe una gran necesidad de tener una forma de enumerar las implementaciones a través de CLI y eliminarlas.

hosting feature request

Comentario más útil

Somos conscientes del problema aquí y estamos considerando la mejor manera de abordarlo. En general, no queremos que se preocupe por tener un historial de versiones cada vez mayor. Curioso por cualquiera que se encuentre con esto (vote con emoji en este comentario): ¿cuál le gustaría más?

  • : tada: la capacidad de enumerar y posiblemente eliminar por lotes versiones antiguas
  • : +1: las versiones antiguas solo se conservan durante un cierto período de tiempo a menos que se "fijen" de alguna manera
  • : corazón: solo se conserva una cierta cantidad de versiones antiguas a menos que se "fije" de alguna manera

Todos 62 comentarios

@Nowaker Esto definitivamente está en nuestro radar y es algo que estamos buscando mejorar.

hey @brendanlim ¿ alguna actualización aquí? También estamos viendo una carga infinita en el módulo de alojamiento, parece que tenemos demasiadas implementaciones :(

¡Gracias!

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 ¿ Alguna actualización sobre esto? Nuestro historial de implementación está en constante crecimiento, cada CI se construye a la vez, ¡y está más allá de nuestras capacidades humanas para continuar eliminándolos!

Somos conscientes del problema aquí y estamos considerando la mejor manera de abordarlo. En general, no queremos que se preocupe por tener un historial de versiones cada vez mayor. Curioso por cualquiera que se encuentre con esto (vote con emoji en este comentario): ¿cuál le gustaría más?

  • : tada: la capacidad de enumerar y posiblemente eliminar por lotes versiones antiguas
  • : +1: las versiones antiguas solo se conservan durante un cierto período de tiempo a menos que se "fijen" de alguna manera
  • : corazón: solo se conserva una cierta cantidad de versiones antiguas a menos que se "fije" de alguna manera

"La capacidad de enumerar y posiblemente eliminar por lotes versiones antiguas" es una primitiva. Las API se crean utilizando primitivas. Estas primitivas permiten a los usuarios lograr lo que quieran sin molestar a nadie (en este caso, tú @mbleigh).

Los otros dos son funciones de alto nivel. Son geniales. Pero luego surge una pregunta: ¿cómo puedo anclar o desanclar la versión a través de API o firebase-tools ? Como puede imaginar, una vez más alguien tendrá que hacer clic en la lista en la interfaz de usuario de Firebase una por una, al igual que eliminar implementaciones antiguas hoy. : rofl:

En resumen, las funciones de alto nivel son excelentes y necesarias, pero las primitivas de CRUD en la API son muy importantes para herramientas como Google Cloud Platform o Firebase.

@Nowaker No estoy en desacuerdo, y ambos son importantes. Es justo decir que es una falsa dicotomía entre la primera opción y las otras dos. FWIW, para implementar las segundas dos opciones tendríamos que implementar todo lo necesario para la primera de todos modos.

Esto definitivamente está en nuestro radar, pero no tengo detalles sobre cuándo tendremos algo que mostrar.

Me conformaría con una casilla de verificación para seleccionar todas / varias entradas en una página y eliminarlas de una vez. Además, haga posible cerrar el cuadro de diálogo de confirmación presionando Intro para confirmar.

Tampoco puede ocultar la función de eliminación. Ahora mismo tu:

  1. Fila de despliegue de rollover.
  2. Haga clic en el menú de tres puntos.
  3. Haga clic en eliminar para acceder a la confirmación.
  4. Haga clic en eliminar nuevamente.

Si cada fila tuviera su propio botón de eliminación, y si pudiera mantener presionada la tecla Mayús para omitir la confirmación, podría volar a través de ellas.

¿Hay disponible una API REST para enumerar y eliminar implementaciones, si uno quisiera implementar esta funcionalidad por su cuenta (o incluso implementarla en firebase-tools y enviar un PR)? Si los puntos finales simplemente no están allí, puedo ver cómo eso podría ser un problema de bloqueo. ¿Está esto en algún tipo de hoja de ruta con algo similar a una fecha de vencimiento?

¿Alguna noticia sobre esto? Definitivamente sería útil tener una forma sencilla de eliminar implementaciones anteriores en CLI. Gracias por el buen trabajo.

Aún no hay noticias sobre esto, pero es un área de interés activo para el equipo. ¡Gracias por su paciencia!

¿Alguna noticia sobre esto? Tenemos tantos que tenemos que eliminar manualmente, uno por uno.

¡También agradecería mucho algún progreso en esto!

Estamos trabajando mucho en nuestra infraestructura de implementación en este momento, lo que llevará un poco de tiempo materializar. Definitivamente, este tema está en nuestra mente mientras hacemos ese trabajo.

@mbleigh hey, ¿qué tal bloquear este tema? Me gustaría recibir una notificación cuando esté terminado, pero realmente no quiero leer todos los comentarios de "yo también".

"Sólo se conserva un cierto número de versiones antiguas a menos que" anclado "de alguna manera" es exactamente lo que necesitamos ".

El otro problema que tengo es que cuando miro esta lista de implementaciones, no tengo idea de cuál es cuál. Versión de mi aplicación de un par de formas, incluida la versión en package.json, y una noción de "compilaciones", por lo que también podría proporcionar una versión y / o compilación # a firebase deploy , y luego si eso podría aparecer en la lista de versiones implementadas, sería fantástico. Tal como está, veo 100 versiones implementadas y no tengo idea de cuál es cuál.

@rtm Puede especificar un mensaje para implementaciones que se muestra en la lista de implementaciones:

firebase deploy --message "build 1234"

La opción no aparece en las páginas de documentación, pero aparece cuando se ejecuta:
firebase help deploy

@ a-xin Gracias. ¡Me había perdido por completo y es muy útil!

Sería genial si se pudiera aumentar la prioridad de este problema, ya que realizamos una implementación continua de cada confirmación de git, y cada implementación tiene un par de cientos de MB. Sería bueno si pudiéramos integrar algunos comandos para limpiar implementaciones antiguas en el script del CD también, con el fin de reducir el consumo general de almacenamiento.

Como solución alternativa, ¿sería posible reutilizar los archivos cuyo nombre de archivo y contenido no han cambiado (según algunos hash)?

Por ejemplo, si Webpack genera fragmentos con hashes estables (por ejemplo, empleando HashedModuleIdsPlugin ), ¿estos archivos se cargan en cada implementación (aunque realmente no hayan cambiado)?

Eso podría reducir significativamente la cantidad de actualizaciones de archivos en cada implementación (hasta kbytes de nuestro código de aplicación, si las bibliotecas de proveedores no han cambiado).

Esta no es una prioridad baja para nosotros. Estamos trabajando en la habilitación
infraestructura para abordar este problema ahora, pero hay grandes cambios
necesario para hacer lo que queremos hacer. Tomará algo de tiempo, gracias por el
retroalimentación y su paciencia.

El domingo 25 de febrero de 2018 a las 3:32 p.m. Denis Loginov [email protected]
escribió:

Como solución temporal, ¿sería posible reutilizar los archivos cuyo
el nombre del archivo y el contenido no han cambiado (según algunos hash)?

Por ejemplo, si Webpack genera fragmentos con hashes estables (por ejemplo, empleando
HashedModuleIdsPlugin), ¿estos archivos se cargan en cada implementación (incluso
aunque realmente no han cambiado)?

Eso podría reducir significativamente la cantidad de actualizaciones de archivos en cada
implementación (hasta kbytes de nuestro código de aplicación, si las bibliotecas del proveedor no
cambiado).

-
Recibes esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU
.

Me alegra ver que se trata de una prioridad. Estoy en el plan Spark y tengo una aplicación web que ronda los 20 MB. He sido un poco liberal con mis implementaciones, así que tengo 300 para revisar y eliminar. 😅

Además del número limitado de implementaciones en el historial, también me gusta la idea de @dinvlad de reutilizar archivos.

@sejr una cosa que hago que ayuda es usar el teclado tanto como sea posible.
Hago clic en los puntos suspensivos, presiono la flecha hacia abajo y luego entro, luego el botón de tabulación 3 veces y luego entro
Y repito ... espero que eso ayude.

@mbleigh ¿ Alguna noticia o progreso en esto?

@mbleigh, ¿puedes darnos un estado?

@mbleigh Esperamos una mayor transparencia. ¿Quizás podría elaborar más sobre la hoja de ruta general de herramientas de base de fuego y los planes con respecto a este tema?
(Es el tema más votado por cierto, casi el doble de votos en comparación con el segundo más alto).

Perdón por la larga demora en abordar esto; es uno de los primeros en nuestra lista, pero hemos estado invirtiendo mucho en un proyecto de infraestructura que sienta las bases para asumir muchos proyectos más pequeños como este.

No puedo prometer líneas de tiempo exactas, pero esto definitivamente no se ha olvidado.

Quizás no olvidado, pero seguramente ignorado . Una implementación se puede eliminar en la interfaz de usuario con un par de clics; no hay ninguna razón por la que la misma no pueda exponerse fácilmente a través de la API. Estoy extremadamente decepcionado con la hoja de ruta del producto Firebase, así como con el destino de Divshot.

Entiendo la frustración, de verdad. Este problema está siendo abordado por el trabajo
que estamos haciendo ahora y esperamos poder traerles a todos ustedes en un futuro cercano.

El viernes, 29 de junio de 2018, 1:01 a.m., Damian Nowak [email protected] escribió:

Quizás no olvidado, pero seguramente ignorado . Se puede eliminar una implementación
en la interfaz de usuario con un par de clics; no hay ninguna razón por la que no pueda ser lo mismo
fácilmente expuesto a través de API. Estoy muy decepcionado con el producto de Firebase
hoja de ruta, así como el destino de Divshot.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU
.

@mbleigh

pero hay grandes cambios necesarios para hacer lo que queremos hacer.

Tal vez las masas hirvientes se tranquilizarían con algún vago saludo con la mano sobre lo que son estos grandes cambios y qué otras características trascendentales permitirían. De lo contrario, no es descabellado que algunas personas se pongan la ropa interior en un giro sobre lo que parece simplemente ignorar la función, ya que está sucediendo hace casi dos años.

Es bastante sencillo: Firebase Hosting nunca ha tenido una API pública y el método actual para enumerar y eliminar implementaciones en la consola no es adecuado para la publicidad. Dado que la CLI es de código abierto, debemos asegurarnos de que todas las acciones expuestas a través de ella sean adecuadamente escalables.

Estamos en el proceso de migrar una gran parte de Firebase Hosting a la infraestructura de Google, lo que lo hará más escalable y también proporcionará una base sólida para tener API adecuadas para las cosas. Este esfuerzo es muy bueno para la salud a largo plazo de Firebase Hosting, pero ha sido una inversión sustancial para el equipo que ha resultado en un largo período sin progreso aparente.

Aprecio que muchos de ustedes se sientan convencidos de esto: si se comunican con el soporte, estaremos felices de podar manualmente sus implementaciones más antiguas mientras tanto. Esperamos que la espera no sea mucho más larga, pero como con cualquier software, elegir las fechas exactas para las cosas suele ser una mala idea.

Espero que esto aclare un poco las cosas, y gracias a todos los usuarios de Firebase Hosting por soportarnos 😄

@mbleigh Muchas gracias por el

@mbleigh No estoy seguro de por qué necesita hacer que esta tarea dependa de una API pública o de cualquier cambio de infraestructura.

Esto se puede solucionar a corto plazo con un botón en la consola de Firebase "Eliminar implementaciones antiguas".

Dado que la consola ya está haciendo llamadas al backend, puede obtener una lista de todas las implementaciones y luego llamar a delete. Supongo que la API en el backend no toma una lista por lotes de implementaciones, por lo que este botón puede causar algunos problemas si lo hace sincrónicamente con una implementación a la vez.

De todos modos, el punto es que no diseñe demasiado una solución cuando todo lo que necesita hacer es agregar un botón a una API ya establecida en su backend. Especialmente, no haga que sus usuarios esperen 2 años.

No es profesional en absoluto.

No sé de qué se están quejando todos. Es RELAJANTE eliminar implementaciones antiguas una por una. Acabo de borrar una acumulación de 72. Luego hubo una doble verificación para asegurarme de que los había recibido todos (me perdí uno), nuevamente muy satisfactorio. Me sentí virtuoso y me atrevo a decir SUPERIOR. Cuidando los detalles; debida diligencia. ¡Meticulosidad administrativa! Lo único que lamento es no tener MÁS que aclarar. De hecho, tuve que jugar al solitario durante UNA HORA ENTERA después, solo para sentirme lo suficientemente bien como para pasar a mi siguiente tarea.

¿¡¿Y dos años (y contando) para obtener esta función?!? Pfftt. ¡Todo el mundo sabe que los ingenieros deben tener CUIDADO para hacer bien estas cosas! Y es un PRESUPUESTO enorme que se requiere. Me refiero a pensar en todo el esfuerzo que están haciendo WAYMO y el resto de Alphabet. Google POSIBLEMENTE no podría darse el lujo de poner más recursos en esta función.

Y además, ¡solo somos DESARROLLADORES! DOBLE Pfftt. ¿Cómo espera que Google sobreviva poniendo a los DESARROLLADORES a la cabeza de la cola? ¡En serio!

No, por el bien de todos nosotros, y en particular por nuestro bienestar, personalmente voto que el equipo de desarrollo aquí continúe trabajando en esto por lo MENOS otros dos años antes de implementar esta función. ¡Por el amor de Dios, ten cuidado! No seas precipitado; ¡no se apresure!

Y por el amor de Dios, no hagas nada impulsivo como tener una función temporal de un botón de eliminación rápida o algo así; eso solo desviaría recursos de cosas mucho más importantes.

Todo bien como está; ¡No realice NINGÚN cambio en su proceso, como, por ejemplo, cambios de GESTIÓN!

Vaya, tengo que irme. Es hora de mi siesta (estoy agotado por toda la concentración necesaria para eliminar todas esas implementaciones). Y además de un tiempo tan productivo, ¡ciertamente merezco un tiempo libre!

Tengo 125 de ellos para eliminar.

🤔 De alguna manera siento que hay un poco de sarcasmo en este hilo ... 🙃

Amigos, realmente siento la frustración. Para reiterar una declaración de mi comentario anterior: si se comunica con el soporte , estaremos felices de podar manualmente sus implementaciones más antiguas en su nombre en el ínterin . Háganos saber cuántas versiones antiguas le gustaría conservar.

En cuanto a por qué no estamos lanzando una solución provisional de curita, bueno, la intervención de soporte es nuestra curita. Preferiríamos no gastar recursos de ingeniería limitados en un sistema que estamos trabajando activamente para reemplazar, razón por la cual esto termina en un lugar un poco difícil.

Hang In There, Baby

Oh, mira, alguien parece haber dejado caer una idea que podría ser relevante para este hilo ...

Ducks Out

PD: Todavía estamos trabajando en una solución automatizada mejor, pero mientras tanto, esta es una curita mucho mejor. 😼

Gracias por tomarse el tiempo para proporcionar una solución alternativa.

La secuencia de comandos en la esencia anterior funciona bien en términos de eliminar las versiones, pero no veo que mi uso de almacenamiento disminuya (¿toma un tiempo volver a calcular esto después de eliminar las versiones?)

¿Se tarda un poco en volver a calcular esto después de eliminar las versiones?

En mi experiencia, sí. Incluso si usa la interfaz gráfica de usuario para eliminar manualmente un montón de versiones, los números de uso tardan un poco en cambiar.

Realmente gracias @mbleigh por proporcionarnos una curita mucho mejor. :rezar:

¿Alguna actualización @mbleigh?

¿Ha mirado la API de hosting rest @alexanderwhatley? No es una solución de interfaz de usuario, pero la nueva API de Hosting Rest debería permitirle hacer todo lo que necesita para recortar sus implementaciones.

Hospedaje de API REST

¿Lo has investigado @jackcw ? Porque solo puedo encontrar los métodos create y list . Sin método delete .

En realidad, no lo he usado, pero por lo que puedo ver, hay una eliminación en el punto final de las versiones y la lista de lanzamientos incluye el objeto de la versión, así que supongo que haces una lista de lanzamientos y tomas la identificación de la versión y presionas los puntos finales de eliminación de la versión.

Perdón, es mi culpa. Entendí mal el significado de versiones y lanzamientos. Ahora puede eliminar versiones anteriores que se denominan versiones con la API.

Creé un pequeño script de shell que se ejecuta una vez al día con un trabajo cron para eliminar todas las versiones antiguas.
Aquí está la esencia . Requiere jq para analizar el JSON. Básicamente hace lo que escribió @jackcw : itera sobre todas las versiones y las elimina.

No soy un experto en escribir scripts de shell o jq, pero el resultado es lo que cuenta, supongo. El guión funciona de manera bastante confiable para mí. Siéntase libre de usarlo usted mismo.

ID de seguimiento interno: 113235359

¿Alguna actualización sobre esto?

Se está trabajando activamente en ello. 🙂

¡Hola a todos!

Ahora puede administrar la retención del historial de versiones en Firebase console:
Screen Shot 2019-03-11 at 10 08 56 AM

Para aquellos de ustedes con sitios grandes, esto debería ayudarlos a mantener bajos los costos.

Para beneficio de todos, la característica anterior de la que habla

¡Gracias por la función! Sin embargo, parece que todavía hay algunos errores.

save_fail_firebase_versions gif

@twistedpair : cry: eh, ¿puede comunicarse con el soporte de Firebase, preferiblemente con el error que está obteniendo en el panel de red de herramientas de desarrollo? Eso definitivamente no se supone que suceda.

La función parece no estar funcionando, tenemos un límite superior de 1 versión en la configuración, ¡pero un montón de versiones en la lista que nunca se eliminaron!

@sharno

Funciona perfectamente en nuestros proyectos.
Tenemos un límite de 10 compilaciones y, a partir de la compilación 11, se "borran automáticamente".

@billiaug Gracias

Lo puse de nuevo en un cierto número y empezó a funcionar. Creo que podría haber sido porque no establecimos este valor antes, así que cuando abrí el cuadro de diálogo y vi 1, asumí que ya se había aplicado, pero no lo estaba.

He notado lo mismo que @sharno. La configuración predeterminada establece el valor en 1, sin embargo, esto no está en efecto hasta que se abrió la configuración y hice clic en _Guardar_ por primera vez. Después de eso, todo funciona como se esperaba.

Para replicar en un nuevo proyecto de Firebase, implemente un sitio varias veces para que haya algunas implementaciones en el historial de versiones. Abra la _Configuración del historial de versiones_ que muestra un valor predeterminado de 1, luego haga clic en _Guardar_. Actualizar la página y todas las implementaciones anteriores, además de la actual, deben tener un estado de _ Eliminado automáticamente_.

Quizás el modal _Configuración del historial de versiones_ debería mencionar o reflejar que la configuración no está en vigor de forma predeterminada y requiere la acción del usuario para habilitarse. Ejemplo:
image
O algo diferente, permitiendo a los usuarios anular un valor:
image

Como mínimo, Firebase Help: establecer el límite para las versiones retenidas debería describir mejor los valores predeterminados.

Tengo una consulta similar, pero no para el alojamiento de Firebase, sino para las funciones de Firebase. Cada implementación de funciones ocupa más de 400 MB del espacio de almacenamiento de la base de fuego. No soy un usuario experto de firebase cli, pero ir al registro de contenedores de GCP brinda la opción de eliminar los contenedores uno por uno.

¿Firebase console proporciona una forma de eliminar automáticamente los contenedores de funciones más antiguos tal como lo hace actualmente para las versiones de alojamiento?

PD: ¿Debería abrir una nueva edición para eso?

@DibyodyutiMondal definitivamente es un tema nuevo.

@DibyodyutiMondal - ¿

¿Fue útil esta página
0 / 5 - 0 calificaciones