firebase-tools
firebase-tools copied to clipboard
firebase
List and delete deployments
I've just noticed by Firebase hosting usage is now almost 1 GB. Quite a lot given the fact our website is only 20 MB.
nowaker@nwkr-desktop ~/projekty/virtkick/website (git)-[master] % du -hs build
20M build
It seems all previous deployments are kept by Firebase and they're visible at https://console.firebase.google.com/project/PROJECTNAME/hosting/main.
Deleting 90 deployments one by one manually is out of question. There's a big need to have a way to list deployments via CLI and delete them.
@Nowaker This is definitely on our radar and something we're looking to improve
hey @brendanlim any updates here? We are also seeing infinite loading in the hosting module, looks like we have too many deployments :(
Thanks!
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 Any update on this? Our deployment history is constantly growing, each CI build at a time, and it's beyond our human capabilities to keep up with deleting them!
We're aware of the issue here and are considering the best way to tackle it. In general we don't want you to feel worried about having a growing history of versions. Curious for anyone who comes across this (vote with emoji on this comment): which would you like best?
- :tada: The ability to list and possibly batch delete old versions
- :+1: Old versions are only kept for a certain amount of time unless "pinned" in some way
- :heart: Only a certain number of old versions are kept unless "pinned" in some way
"The ability to list and possibly batch delete old versions" is a primitive. APIs are built using primitives. These primitives allow users to achieve whatever they want without bugging anyone (in this case, you @mbleigh).
The other two are high level features. They're cool. But then comes a question: how do I pin or unpin the version via API or firebase-tools? As you can imagine, once again someone will have to click through the list in Firebase UI one by one, just like to delete old deployments today. :rofl:
To sum up, high level features are great and needed, but CRUD primitives in API are super important for tools like Google Cloud Platform or Firebase.
@Nowaker I don't disagree, and both are important. It's fair to say it's a false dichotomy between the first option and the other two. FWIW, in order to implement the second two options we'd pretty much have to implement everything necessary for the first anyway.
This stuff is definitely on our radar, but I don't have specifics on when we'll have something to show.
I would make do with a checkbox to select all / multiple entries on a page and delete them in one go. Also, make it possible to dismiss the confirmation dialog by pressing enter to confirm.
You could also not hide the delete functionality. Right now you:
- Rollover deployment row.
- Click the three dots menu.
- Click delete to call up the confirmation.
- Click delete again.
If each row had it's own delete button, and if you could hold shift to bypass the confirmation, you could fly though them.
Is an REST API for listing and deleting deployments available, if one wanted to implement this functionality on their own (or even implement it in firebase-tools, and submit a PR)? If the endpoints are just not there, I can see how that might be a blocking issue. Is this on any kind of road map with something similar to a due date?
Any news on this? It would definitely help to have a simple way of removing previous deployments in CLI. Thanks for the good work.
No news on this yet, but it's an area of active interest for the team. Thanks for your patience!
Any news on this? We have so many we have to manually remove, one by one.
We're doing a lot of work on our deployment infrastructure right now that will take a bit of time to come to fruition. This issue is definitely on our mind as we do that work.
@mbleigh hey how about locking this topic. I'd like to be notified when it's done, but I really don't want to read all the "me too" comments.
"Only a certain number of old versions are kept unless "pinned" in some way" is exactly what we need.
The other problem I have is that I when I look at this list of deployments, I have no idea which is which. I version my app in a couple of ways, including the version in package.json, and an notion of "builds", so I could also provide a version and/or build # to firebase deploy, and then if that could be listed in the list of deployed versions it would be fantastic. As it stands, I see 100 deployed versions and have no idea which is which.
@rtm You can specify a message for deploys which is shown in the list of deployments:
firebase deploy --message "build 1234"
The option is not listed on the documentation pages, but it's listed when running:
firebase help deploy
It would be great if the priority of this issue could be increased, as we do continuous deployment of every git commit, and each deployment is a couple of hundred MB. Would be nice if we were able to integrate some commands for cleaning up old deployments in the CD script as well, in order to reduce the overall storage consumption.
As a workaround, would it be possible to reuse the files whose filename and contents haven't changed (according to some hash)?
E.g. if Webpack generates chunks with stable hashes (e.g. employing HashedModuleIdsPlugin), do these files get uploaded on every deploy (even though they truly haven't changed)?
That could significantly cut down on the amount of file updates on each deployment (down to kbytes of our application code, if vendor libs haven't changed).
This is not a low priority for us. We are working on the enabling infrastructure to tackle this issue now, but there are large changes necessary to do what we want to do. It will take some time, thanks for the feedback and your patience.
On Sun, Feb 25, 2018, 3:32 PM Denis Loginov [email protected] wrote:
As a temporary workaround, would it be possible to reuse the files whose filename and contents hasn't changed (according to some hash)?
E.g. if Webpack generates chunks with stable hashes (e.g employing HashedModuleIdsPlugin), do these files get uploaded on every deploy (even though they truly haven't changed)?
That could significantly cut down on the amount of file updates on each deployment (down to kbytes of our application code, if vendor libs haven't chagned).
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU .
I am glad to see that this is a priority. I am on the Spark plan and have a web application that is somewhere around 20MB. I have been a little liberal with my deployments so I have 300 to go through and delete. 😅
In addition to the limited # of deployments in history, I also like @dinvlad's idea of reusing files.
@sejr one thing I do that helps is use the keyboard as much as possible. I click the elipses, hit the down arrow then enter, then the tab button 3 times then enter And repeat.....hopefully that helps.
@mbleigh Looking forward to more transparency. Maybe you could elaborate more about the general firebase-tools roadmap, and the plans regarding this issue? (It's the highest voted issue btw, almost double the votes compared the second highest one).
Sorry for the long delay on addressing this -- it's high on our list, but we've been heavily investing in an infrastructure project that sets the foundation to take on many smaller projects like this one.
I can't promise exact timelines, but this definitely hasn't been forgotten.
Maybe not forgotten but surely ignored. A deployment can be deleted in the UI with a couple clicks - there's no reason why the same couldn't be easily exposed via API. I'm extremely disappointed by Firebase product roadmap, as well as the fate of Divshot.
I understand the frustration, truly. This issue is being addressed by work we're doing now and hope to bring to all of you in the near future.
On Fri, Jun 29, 2018, 1:01 AM Damian Nowak [email protected] wrote:
Maybe not forgotten but surely ignored. A deployment can be deleted in the UI with a couple clicks - there's no reason why the same couldn't be easily exposed via API. I'm extremely disappointed by Firebase product roadmap, as well as the fate of Divshot.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU .