Firebase-tools: 列出和删除部署

@Noaker这绝对是我们的雷达，我们正在寻求改进

嘿@brendanlim这里有任何更新吗？ 我们还在托管模块中看到无限加载，看起来我们有太多的部署:(

谢谢！

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 有任何更新吗？ 我们的部署历史在不断增长，每个 CI 都是一次构建，而且删除它们已经超出了我们人类的能力！

我们知道这里的问题，并正在考虑解决它的最佳方法。 一般而言，我们不希望您担心版本不断增长的历史。 对遇到此问题的人感到好奇（在此评论上用表情符号投票）：您最喜欢哪个？

• :tada: 列出并可能批量删除旧版本的能力
• :+1: 除非以某种方式“固定”，否则旧版本只会保留一定的时间
• :heart: 除非以某种方式“固定”，否则只会保留一定数量的旧版本

“列出并可能批量删除旧版本的能力”是一个原语。 API 是使用原语构建的。 这些原语允许用户在不打扰任何人的情况下实现他们想要的任何东西（在这种情况下，你是@mbleigh）。

另外两个是高级功能。 他们很酷。 但随之而来的问题是：如何通过 API 或firebase-tools固定或取消固定版本？ 可以想象，再一次，有人将不得不逐个点击 Firebase UI 中的列表，就像今天删除旧部署一样。 :rofl:

总而言之，高级功能非常棒且需要，但 API 中的 CRUD 原语对于 Google Cloud Platform 或 Firebase 等工具非常重要。

@Nowaker我不反对，两者都很重要。 公平地说，这是第一个选项和其他两个选项之间的错误二分法。 FWIW，为了实现后两个选项，我们几乎必须实现第一个选项所需的一切。

这些东西肯定在我们的关注范围内，但我没有具体说明我们什么时候可以展示一些东西。

我会用一个复选框来选择页面上的所有/多个条目并一次性删除它们。 此外，还可以通过按 Enter 确认来关闭确认对话框。

您也无法隐藏删除功能。 现在你：

1. 翻转部署行。
2. 单击三点菜单。
3. 单击删除以调出确认。
4. 再次点击删除。

如果每一行都有自己的删除按钮，并且如果您可以按住 shift 绕过确认，您就可以飞越它们。

如果想自己实现此功能（甚至在 firebase-tools 中实现并提交 PR），是否有用于列出和删除部署的 REST API？ 如果端点不存在，我可以看到这可能是一个阻塞问题。 这是在任何类似于到期日的路线图上吗？

有这方面的消息吗？ 有一种简单的方法可以在 CLI 中删除以前的部署，这肯定会有所帮助。 感谢您的出色工作。

目前还没有这方面的消息，但这是团队积极感兴趣的领域。 谢谢你的耐心！

有这方面的消息吗？ 我们有很多我们必须手动删除，一个一个。

也非常感谢这方面的一些进展！

我们现在正在我们的部署基础设施上做很多工作，这需要一些时间才能实现。 当我们做这项工作时，这个问题绝对是我们的想法。

@mbleigh嘿，锁定这个话题怎么样。 我希望在完成后收到通知，但我真的不想阅读所有“我也是”的评论。

“除非以某种方式“固定”，否则只会保留一定数量的旧版本”正是我们所需要的。

我遇到的另一个问题是，当我查看这个部署列表时，我不知道哪个是哪个。 我以多种方式版本我的应用程序，包括 package.json 中的版本，以及“构建”的概念，所以我还可以提供一个版本和/或构建 # 到firebase deploy ，然后如果可以列在已部署版本的列表中，这太棒了。 就目前而言，我看到 100 个已部署的版本，但不知道哪个是哪个。

@rtm您可以为部署指定一条消息，该消息显示在部署列表中：

firebase deploy --message "build 1234"

该选项未列在文档页面上，但在运行时列出：
firebase help deploy

@a-xin 谢谢。 我完全错过了它，它非常有用！

如果可以提高这个问题的优先级，那就太好了，因为我们对每个 git commit 进行持续部署，每次部署都有几百 MB。 如果我们能够在 CD 脚本中集成一些用于清理旧部署的命令，以减少整体存储消耗，那就太好了。

作为一种解决方法，是否可以重用文件名和内容未更改的文件（根据某些哈希）？

例如，如果 Webpack 生成具有稳定哈希值的块（例如使用HashedModuleIdsPlugin ），这些文件是否会在每次部署时上传（即使它们确实没有改变）？

这可以显着减少每次部署的文件更新量（如果供应商库没有改变，我们的应用程序代码可以减少到 KB）。

这对我们来说不是一个低优先级。 我们正在努力实现
现在解决这个问题的基础设施，但有很大的变化
有必要做我们想做的事情。 需要一些时间，谢谢
反馈和你的耐心。

在Sun，2018年2月25日，下午3时32丹尼斯·洛吉诺弗[email protected]
写道：

作为临时解决方法，是否可以重用其
文件名和内容没有改变（根据一些哈希）？

例如，如果 Webpack 生成具有稳定哈希值的块（例如使用
HashedModuleIdsPlugin），这些文件是否在每次部署时上传（甚至
虽然他们真的没有改变）？

这可以显着减少每个文件的更新量
部署（小到我们的应用程序代码的 KB，如果供应商库没有
改变）。

—
你收到这个是因为你被提到了。

直接回复本邮件，在GitHub上查看
https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU
.

我很高兴看到这是一个优先事项。 我在 Spark 计划中并且有一个大约 20MB 的 Web 应用程序。 我对我的部署有点自由，所以我有 300 个要通过和删除。 😅

除了历史上有限的部署数量之外，我还喜欢@dinvlad重用文件的想法。

@sejr我做的一件事是尽可能多地使用键盘。
我点击省略号，点击向下箭头然后输入，然后标签按钮 3 次然后输入
并重复.....希望这有帮助。

@mbleigh关于这方面的任何消息或进展吗？

@mbleigh你能给我们一个状态吗？

@mbleigh期待更高的透明度。 也许您可以详细说明一般的 firebase-tools 路线图，以及有关此问题的计划？
（顺便说一句，这是投票最高的问题，与第二高的投票相比几乎翻了一番）。

很抱歉在解决这个问题上拖延了很长时间——它在我们的清单上很重要，但我们一直在大量投资于一个基础设施项目，为承担许多像这样的小型项目奠定了基础。

我不能保证确切的时间表，但这绝对没有被遗忘。

也许没有被遗忘，但肯定被忽视了。 只需单击几下即可在 UI 中删除部署 - 没有理由不能通过 API 轻松公开相同内容。 我对 Firebase 产品路线图以及 Divshot 的命运感到非常失望。

我理解这种挫败感，真的。 这个问题正在通过工作解决
我们现在正在做，希望在不久的将来带给大家。

在周五，2018年6月29日，上午1:01达米安·诺瓦克[email protected]写道：

也许没有被遗忘，但肯定被忽视了。 可以删除部署
在用户界面中点击几下 - 没有理由不一样
很容易通过 API 公开。 我对 Firebase 产品非常失望
路线图，以及 Divshot 的命运。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU
.

@mbleigh

但是为了做我们想做的事情，需要进行很大的改变。

也许沸腾的群众会通过一些适当模糊的挥手来安抚这些巨大的变化是什么，以及它们将带来什么其他惊天动地的特征。 如果做不到这一点，对于某些人来说，让他们的内衣扭曲似乎只是忽略该功能并不是没有道理的，因为它已经持续了将近两年。

这非常简单——Firebase Hosting 从未有过公开的 API，目前在控制台中列出和删除部署的方法不太适合公开。 由于 CLI 是开源的，我们需要确保通过它公开的任何操作都具有适当的可扩展性。

我们正在将大部分 Firebase 托管迁移到 Google 基础架构，这将使其更具可扩展性，并为正确拥有 API 奠定坚实的基础。 这项工作对 Firebase Hosting 的长期健康发展非常有益，但对团队来说是一笔可观的投资，导致长期没有明显进展。

我很感激你们中的许多人对此有强烈的感受——如果您寻求支持，我们很乐意在此期间手动修剪您的旧部署。 我们希望等待的时间不会太长，但与任何软件一样，为事情选择确切的日期通常是一个坏主意。

我希望这能让事情变得更清楚，感谢所有 Firebase 托管用户对我们的支持 😄

@mbleigh 非常感谢您的

@mbleigh我不确定为什么您需要使此任务依赖于公共 API 或任何基础架构更改。

这可以在短期内通过 Firebase 控制台中的“修剪旧部署”按钮解决。

由于控制台已经在调用后端，它可以获取所有部署的列表，然后调用 delete。 我假设后端的 API 不采用批量部署列表，因此如果您一次与一个部署同步执行此按钮，则此按钮可能会导致一些问题。

无论如何，关键是当您需要做的只是向后端已经建立的 API 添加一个按钮时，不要过度设计解决方案。 特别是，不要让您的用户等待 2 年。

一点都不专业。

不知道大家在吐槽什么。 一一删除旧的部署是很轻松的。 我刚刚清理了 72 个积压的订单。然后进行了双重检查，以确保我已经全部拿到了（我错过了一个）——再次非常令人满意。 我觉得自己很贤惠，我敢说优秀。 注重细节； 尽职调查。 行政讲究！ 我唯一的遗憾是我没有更多的东西要清理。 之后我实际上不得不玩了整整一个小时的纸牌游戏，只是为了让我感觉足够好以进行下一个任务。

两年（和计数）获得此功能？！？ 噗。 每个人都知道工程师必须小心才能正确地做这些事情！ 这是一个巨大的预算，这是必需的。 我的意思是想想 WAYMO 和 Alphabet 的其余部分正在付出的所有努力。 Google 不可能为此功能投入更多资源。

此外，我们只是开发人员！ 双Pfftt。 通过将开发人员排在队列的前面，您如何期望 Google 生存？！？ 我是说真的！

不，为了我们所有人的利益，尤其是我们的福祉，我个人投票支持这里的开发团队在实施此功能之前至少再继续工作两年。 看在上帝的份上小心点！ 不要鲁莽； 不要着急！

看在上帝的份上，不要做任何冲动的事情，比如快速删除按钮之类的临时功能； 那只会从更重要的事情上转移资源。

一切都好； 请不要对您的流程进行任何更改，例如管理更改！

哎呀，得走了。 是时候小睡了（删除所有这些部署所需的所有注意力都让我筋疲力尽）。 除了有这么富有成效的时间，我当然应该有一些休息时间！

我有 125 个要删除。

🤔 不知怎的，我觉得这个帖子中发生了一些讽刺...... 🙃

伙计们，我真的很沮丧。 重申我之前评论中的声明：如果您联系支持，我们很乐意在此期间代表您手动修剪旧部署。 请告诉我们您希望保留多少旧版本。

至于为什么我们不发布临时创可贴解决方案——嗯，支持干预是我们的创可贴。 我们不希望在我们正在积极努力替换的系统上消耗有限的工程资源，这就是为什么这最终会陷入困境的原因。

哦，看，似乎有人放弃了可能与此线程相关

PS 我们仍在研究更好的自动化解决方案，但与此同时，这是一个更好的创可贴。 😼

感谢您抽出时间提供解决方法。

上述要点中的脚本在删除版本方面工作正常，但我没有看到我的存储使用率下降（删除版本后重新计算是否需要一段时间？）

删除版本后重新计算是否需要一段时间？

根据我的经验，是的。 即使你使用gui手动删除一堆版本，使用数量的变化也需要一些时间。

真的感谢@mbleigh为我们提供了更好的创可贴。 ：祈祷：

任何更新@mbleigh？

您是否看过托管休息 api @alexanderwhatley它不是一个 ui 解决方案，但新的 Hosting Rest API 应该使您能够完成修剪部署所需的一切

托管 REST API

你有没有研究过@jackcw ？ 因为我只能找到create和list方法。 没有delete方法。

我还没有真正使用过它，但据我所知，版本端点上有一个列表包含版本对象，所以我假设你做了一个版本列表并获取版本 ID 并点击版本删除端点

对不起这是我的错。 我误解了版本和发行版的含义。 您现在可以删除使用 API 称为版本的旧版本。

我创建了一个小的 shell 脚本，每天执行一次，并通过 cron 作业删除所有旧版本。
这是要点。 它需要jq来解析 JSON。 它基本上执行@jackcw所写的：它遍历所有版本并删除它们。

我不是编写 shell 脚本或 jq 的专家 - 但我猜结果才是最重要的。 该脚本对我来说非常可靠。 随意使用它自己。

内部跟踪 ID：113235359

有任何更新吗？

它正在积极开展工作。 🙂

嘿大家！

您现在可以在 Firebase 控制台中管理您的版本历史记录保留：

对于那些拥有大型网站的人来说，这应该可以帮助您降低成本。

为了大家的利益， @samtstern所说的上述功能就是我所说的我们正在研究的东西。 我希望它可以帮助人们更好地掌握他们的版本历史！

感谢您的功能！ 不过好像还是有一些bug。

@twistedpair :cry: 嗯，你能联系 Firebase 支持吗，最好是你在开发工具的网络面板中遇到的错误？ 这绝对不应该发生。

该功能似乎不起作用，我们在设置中设置了 1 个版本的上限，但列表中的大量版本从未被删除！

@沙诺

它适用于我们的项目。
我们有 10 个构建的限制，从构建 11 开始，它们会被“自动删除”

@billiaug谢谢

我再次将其设置为某个数字并开始工作。 我认为这可能是因为我们之前没有设置这个值，所以当我打开对话框看到 1 时，我认为它已经被应用，但它不是

我注意到与@sharno 相同。 默认设置将值设置为 1，但是直到设置被打开并且我第一次单击 _Save_ 时这才生效。 之后，一切都按预期运行。

要在新的 Firebase 项目上复制，请多次部署站点，以便在发布历史记录中有一些部署。 打开显示默认值为 1 的 _Version history settings_，然后单击 _Save_。 刷新页面，除当前部署之外的所有先前部署都应具有 _Auto-deleted_ 状态。

也许 _Version history settings_ 模式应该提到或反映该设置默认无效，需要用户操作才能启用。 例子：

或者不同的东西，允许用户取消设置一个值：

至少Firebase 帮助 - 设置保留版本的限制应该更好地描述默认值。

我有一个类似的查询，但不是针对 firebase 托管，而是针对 firebase 功能。 每个功能部署需要 400+MB 的 Firebase 存储空间。 我不是 firebase cli 的专家用户，但转到 GCP 容器注册表提供了一个一个删除容器的选项

firebase 控制台是否提供了一种自动删除旧功能容器的方法，就像它目前用于托管版本一样？

PS：我应该为此开一个新问题吗？

@DibyodyutiMondal绝对是一个新问题。

@DibyodyutiMondal - 您是否打开了一个新问题？ 如果是这样，请在这里放一个链接，这样更容易找到。