List and delete deployments

[Nowaker]

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.

[brendanlim]

@Nowaker This is definitely on our radar and something we're looking to improve

[zhenhaolei]

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)

[Nowaker]

@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!

[mbleigh]

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?

• 🎉 The ability to list and possibly batch delete old versions
• 👍 Old versions are only kept for a certain amount of time unless "pinned" in some way
• ❤️ Only a certain number of old versions are kept unless "pinned" in some way

[Nowaker]

"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. 🤣

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.

[mbleigh]

@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.

[CaptainCodeman]

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.

[WhatsThatItsPat]

You could also not hide the delete functionality. Right now you:

1. Rollover deployment row.
2. Click the three dots menu.
3. Click delete to call up the confirmation.
4. 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.

[titpetric]

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?

[Thkasis]

Any news on this? It would definitely help to have a simple way of removing previous deployments in CLI. Thanks for the good work.

[mbleigh]

No news on this yet, but it's an area of active interest for the team. Thanks for your patience!

[shaun-sweet]

Any news on this? We have so many we have to manually remove, one by one.

[glennlawyer]

Would also really appreciate some progress on this!

[mbleigh]

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.

[titpetric]

@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.

[ludvig-larsson]

"Only a certain number of old versions are kept unless "pinned" in some way" is exactly what we need.

[rtm]

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.

[a-xin]

@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

[rtm]

@a-xin Thank you. I had totally missed that and it's very useful!

[haraldreingruber]

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.

[dinvlad]

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).

[mbleigh]

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 ***@***.***> 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 <#215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU> .

[sejr]

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.

[sboyd]

@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.

[billiaug]

@mbleigh Any news or progression on this?

[haraldreingruber]

Thanks for taking the time to provide a work-around.

[anatesan-stream]

The script in the gist above works fine in terms of deleting the versions, but I don't see my Storage Usage come down (does it take a while to recompute this after the deletes of the versions?)

[zevdg]

does it take a while to recompute this after the deletes of the versions?

In my experience, yes. Even if you use the gui to manually delete a bunch of versions, it takes some time for the usage numbers to change.

[wahidyankf]

Really thanks @mbleigh for providing us with a much better band-aid. 🙏

[alexanderwhatley]

Any updates @mbleigh?

[jackcw]

Have you looked at the hosting rest api @alexanderwhatley its not a ui solution but the new Hosting Rest API should enable you to do everything you need to trim up your deployments

Hosting REST API

[ghost]

Have you looked into it @jackcw ? Cause I can only find create and list methods. No delete method.

[jackcw]

I havent actually used it but as far as i can see there is a delete on the versions endpoint and the list on releases includes the version object so i assume you do a list of releases and take the version id and hit the version delete endpoints

[ghost]

Sorry my bad. I misunderstood the meaning of versions and releases. You can now delete older releases which are called versions with the API.

[andipaetzold]

I created a small shell script that is executed once a day with a cron job to remove all old releases.
Here is the gist. It requires jq to parse the JSON. It basically does what @jackcw wrote: It iterates over all releases and deletes them.

I am not an expert in writing shell scripts or jq - but the result is what counts, I guess. The script works quite reliably for me. Feel free to use it yourself.

[mbleigh]

Internal tracking id: 113235359

[paulmand3l]

Any updates on this?

[bkendall]

It is actively being worked on. 🙂

[samtstern]

Hey everyone!

You can now manage your version history retention in the Firebase console:

For those of you with large sites this should help you keep costs down.

[mbleigh]

For everyone's benefit, the above feature @samtstern is talking about is the thing I said we were working on. I hope it helps people keep a good handle on their version history!

[twistedpair]

Thanks for the feature! Seems there are still some bugs, though.

[mbleigh]

@twistedpair 😢 huh, can you reach out to Firebase support, preferably with the error you're getting in the Network panel of dev tools? That's definitely not supposed to happen.

[sharno]

The feature seems to be not working, we have an upper limit of 1 version in the settings but a ton of versions in the list that never got deleted!

[billiaug]

@sharno

It works perfect on our projects.
We have a limit of 10 builds and as from build 11 they get "auto-deleted"

[sharno]

@billiaug Thanks

I set it again to a certain number and it started working. I think that might have been because we didn't set this value before so when I opened the dialog and saw 1, I assumed it was already applied but it wasn't

[ashnewport]

I've noticed the same as @sharno. Default settings set the value to 1 however this isn't in effect until the settings were opened and I clicked Save for the first time. Following that everything functions as expected.

To replicate on a new Firebase project, deploy a site several times so there are a few deployments in the release history. Open the Version history settings which shows a default value of 1, then click Save. Refresh the page and all previous deployments apart from the current should have a status of Auto-deleted.

Perhaps the Version history settings modal should mention or reflect that the setting isn't in effect by default and requires user action to become enabled. Example:

Or something different, allowing users to unset a value:

At a minimum Firebase Help - Set the limit for retained versions should describe the defaults better.

[DibyodyutiMondal]

I have a similar query, but not for firebase hosting, rather for firebase functions. Each functions deployments takes 400+MB of the firebase storage space. I am not an expert user of the firebase cli, but going to the GCP container registry provides the option deleting the containers one by one

Does firebase console provide a way to auto-delete older function containers just like it currently does for hosting releases?

PS: Should I open a new issue for that?

[jthegedus]

@DibyodyutiMondal definitely a new issue.

[MappingSteve]

@DibyodyutiMondal - did you open a new issue? If so, please put a link to it here, so is easier to find.

[PaulD1980]

Any progress on DELETE Previous Deployed app functionality availability on CLI?

[mikehardy]

I am on the late late show here, but I noticed that the configuration of how many versions to keep is working well via the firebase console web interface, but it does not appear to be available in the firebase.json file (https://firebase.google.com/docs/hosting/full-config#firebase-json_example - no docs saying how to do it, not present in the "complete" example).

Is configuration of number of versions to keep possible via firebase.json, and if not is there an existing feature request to track here, or should I/we create one?

Cheers