Firebase-tools: デプロイメントのリストと削除

@Nowakerこれは間違いなく私たちのレーダーにあり、私たちが改善しようとしているものです

ねえ@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）を悩ませることなく、やりたいことを何でも達成できます。

他の2つは高レベルの機能です。 彼らはクールです。 しかし、次に質問があります。APIまたはfirebase-tools介してバージョンを固定または固定解除するにはどうすればよいですか？ ご想像のとおり、今日の古いデプロイを削除するのと同じように、FirebaseUIのリストを1つずつクリックする必要があります。 ：rofl：

要約すると、高レベルの機能は素晴らしく、必要ですが、APIのCRUDプリミティブは、Google CloudPlatformやFirebaseなどのツールにとって非常に重要です。

@Nowaker私は同意しません、そして両方とも重要です。 これは、最初のオプションと他の2つのオプションの間の誤った二分法であると言っても過言ではありません。 FWIW、2番目の2つのオプションを実装するには、とにかく最初のオプションに必要なすべてを実装する必要があります。

このようなものは間違いなく私たちのレーダーにありますが、いつ何かを表示するかについての詳細はありません。

ページ上のすべて/複数のエントリを選択して一度に削除するチェックボックスを使用します。 また、Enterキーを押して確認することにより、確認ダイアログを閉じることができるようにします。

削除機能を非表示にすることもできませんでした。 今あなた：

1. ロールオーバー展開行。
2. 3つのドットメニューをクリックします。
3. 削除をクリックして確認を呼び出します。
4. もう一度[削除]をクリックします。

各行に独自の削除ボタンがあり、Shiftキーを押しながら確認をバイパスできる場合は、それらを飛ぶことができます。

この機能を独自に実装したい場合（またはfirebase-toolsに実装してPRを送信したい場合）、デプロイを一覧表示および削除するためのREST APIは利用できますか？ エンドポイントが存在しない場合は、それがブロッキングの問題である可能性があります。 これは、期日と似たようなロードマップにありますか？

これに関するニュースはありますか？ CLIで以前のデプロイメントを削除する簡単な方法があると間違いなく役立ちます。 良い仕事をありがとう。

これに関するニュースはまだありませんが、チームにとって積極的に関心のある分野です。 お待ち頂きまして、ありがとうございます！

これに関するニュースはありますか？ 手動で削除しなければならないものがたくさんあります。

また、これに関するいくつかの進歩を本当に感謝します！

現在、展開インフラストラクチャで多くの作業を行っていますが、実現するには少し時間がかかります。 私たちがその仕事をしているとき、この問題は間違いなく私たちの頭の中にあります。

@mbleighちょっと、このトピックをロックするのはどう

「何らかの方法で「固定」されていない限り、特定の数の古いバージョンのみが保持されます」。

私が抱えているもう1つの問題は、この展開のリストを見ると、どちらがどちらかわからないことです。 package.jsonのバージョンや「ビルド」の概念など、いくつかの方法でアプリをバージョン管理しているので、バージョンやビルド＃をfirebase deployに提供することもできます。デプロイされたバージョンのリストにリストされる可能性があります。 現状では、100個のデプロイ済みバージョンがあり、どれがどれかわかりません。

@rtmデプロイメントのリストに表示されるデプロイのメッセージを指定できます。

firebase deploy --message "build 1234"

このオプションはドキュメントページには表示されませんが、実行時に表示されます。
firebase help deploy

@ a-xinありがとうございます。 私はそれを完全に見逃していました、そしてそれはとても便利です！

すべてのgitcommitの継続的デプロイを行い、各デプロイは数百MBであるため、この問題の優先度を上げることができれば素晴らしいと思います。 全体的なストレージ消費量を削減するために、古い展開をクリーンアップするためのいくつかのコマンドをCDスクリプトにも統合できれば便利です。

回避策として、ファイル名と内容が変更されていないファイルを再利用することは可能ですか（ハッシュによる）？

たとえば、Webpackが安定したハッシュでチャンクを生成する場合（たとえば、 HashedModuleIdsPlugin ）、これらのファイルは（実際には変更されていなくても）すべてのデプロイでアップロードされますか？

これにより、各デプロイメントでのファイル更新の量が大幅に削減される可能性があります（ベンダーライブラリが変更されていない場合は、アプリケーションコードのキロバイトまで）。

これは私たちにとって優先度が低いわけではありません。 私たちは実現に取り組んでいます
現在この問題に取り組むためのインフラストラクチャですが、大きな変化があります
私たちがやりたいことをするために必要です。 しばらく時間がかかります、ありがとう
フィードバックとあなたの忍耐。

日、2018年2月25日には、午前3時32分PMデニス・ロジノブ[email protected]
書きました：

一時的な回避策として、次のファイルを再利用することは可能ですか？
ファイル名と内容は変更されていませんか（ハッシュによると）？

たとえば、Webpackが安定したハッシュを持つチャンクを生成する場合（たとえば、
HashedModuleIdsPlugin）、これらのファイルはすべてのデプロイでアップロードされますか（
彼らは本当に変わっていませんが）？

これにより、それぞれのファイル更新の量を大幅に削減できます。
デプロイ（ベンダーライブラリがない場合は、アプリケーションコードのキロバイトまで）
悔しい）。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信し、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私が役立つことの1つは、可能な限りキーボードを使用することです。
楕円をクリックし、下矢印を押してEnterキーを押し、次にTabボタンを3回押して、Enterキーを押します。
そして繰り返します.....うまくいけば、それが役立つでしょう。

@mbleighこれに関するニュースや進展はありますか？

@mbleighステータスを教えていただけますか？

@mbleigh透明性の
（これは投票数が最も多い問題ですが、2番目に投票数が多い問題と比較してほぼ2倍です）。

これに対処するのに長い遅れがあったことをお詫びします-それは私たちのリストの上位にありますが、私たちはこのような多くの小さなプロジェクトを引き受けるための基盤を設定するインフラストラクチャプロジェクトに多額の投資をしています。

正確なタイムラインをお約束することはできませんが、これは間違いなく忘れられていません。

多分忘れられていませんが、確かに無視されています。 デプロイメントは、数回クリックするだけでUIで削除できます。APIを介して同じものを簡単に公開できなかった理由はありません。 Firebaseの製品ロードマップとDivshotの運命に非常に失望しています。

私は本当に欲求不満を理解しています。 この問題は仕事で対処されています
現在行っており、近い将来、皆様にお届けできることを願っております。

金、2018年6月29日には、1:01ダミアン貰えるの[email protected]は書きました：

多分忘れられていませんが、確かに無視されています。 デプロイメントは削除できます
数回クリックするだけのUIで-同じことができなかった理由はありません
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

しかし、私たちがやりたいことをするために必要な大きな変更があります。

恐らく、これらの大きな変化が何であるか、そしてそれらが可能にする他の地球を破壊する機能について、適切に漠然とした手を振ることによって、うっとうしい大衆は和らげられるでしょう。 それができないと、2年近く続いているので、単に機能を無視しているように見えることについて、下着をひねってしまうのは不合理ではありません。

非常に簡単です。FirebaseHostingにはパブリックAPIがありませんでした。また、コンソールでデプロイを一覧表示および削除する現在の方法は、パブリック化には適していません。 CLIはオープンソースであるため、CLIを介して公開されるアクションが適切にスケーラブルであることを確認する必要があります。

現在、Firebase Hostingの大部分をGoogleインフラストラクチャに移行しています。これにより、Firebase Hostingがよりスケーラブルになり、APIを適切に使用するための強力な基盤が提供されます。 この取り組みは、Firebase Hostingの長期的な健全性にとって非常に優れていますが、チームにとってはかなりの投資であり、長期にわたって明らかな進展は見られませんでした。

多くの方がこれについて強く感じていることを感謝します。サポートに連絡する場合は、暫定的に古いデプロイを手動で削除できます。 待ち時間がそれほど長くならないことを願っていますが、他のソフトウェアと同様に、物事の正確な日付を選択することは通常悪い考えです。

これで少し問題が解決することを願っています。FirebaseHostingのすべてのユーザーに感謝します😄

@mbleigh頭を上げてくれてありがとう。

@mbleighなぜこのタスクをパブリックAPIまたはインフラストラクチャの変更に依存させる必要があるのか

これは、Firebaseコンソールの[古いデプロイのプルーニング]ボタンを使用して短期的に解決できます。

コンソールはすでにバックエンドを呼び出しているため、すべてのデプロイメントのリストを取得してから、deleteを呼び出すことができます。 バックエンドのAPIはデプロイメントのバッチリストを取得しないと想定しているため、一度に1つのデプロイメントと同期して実行すると、このボタンによって問題が発生する可能性があります。

とにかく、重要なのは、バックエンドですでに確立されているAPIにボタンを追加するだけの場合は、ソリューションを過度に設計しないでください。 特に、ユーザーに2年間待たせないでください。

まったく専門家ではありません。

誰もが何についてうめき声を上げているのかわかりません。 古いデプロイメントを1つずつ削除するのはリラックスできます。 私はちょうど72のバックログをクリアしました。それから私がそれらすべてを手に入れたことを確認するために二重のチェックがありました（私は1つを逃しました）-再び非常に満足です。 私は高潔で、あえてSUPERIORと言います。 細部に気を配る; 適当な注意。 管理上のこだわり！ 私の唯一の後悔は、私が片付けるためにもっと持っていなかったことでした。 次の仕事に移るのに十分な気分になるために、私は実際にその後1時間ソリティアをプレイしなければなりませんでした。

そして、この機能を取得するのに2年（そして数えて）？！？ Pfftt。 エンジニアがこれらのことを正しく行うにはケアをしなければならないことは誰もが知っています！ そして、それは必要とされる巨大な予算です。 つまり、WAYMOとAlphabetの残りの部分が取っているすべての努力について考えてみてください。 Googleは、この機能により多くのリソースを投入する余裕がなかった可能性があります。

その上、私たちはただの開発者です！ ダブルPfftt。 DEVELOPERSをキューの先頭に置くことで、Googleがどのように生き残ると思いますか？！？ 本当に！

いいえ、私たち全員の利益のために、そして特に私たちの幸福のために、私は個人的に、この機能を実装する前に、ここの開発チームが少なくともあと2年間これに取り組んでいることを投票します。 神のために注意してください！ 急いではいけません。 急がないでください！

そして、天国のために、クイック削除ボタンなどの一時的な機能を持つような衝動的なことは何もしないでください。 それは、はるかに重要なものからリソースをそらすだけです。

すべてそのままで良いです。 管理の変更など、プロセスに変更を加えないでください。

おっと、行かなくちゃ。 昼寝の時間です（これらの展開をすべて削除するために必要なすべての集中力に疲れ果てています）。 そして、そのような生産的な時間に加えて、私は確かにしばらく休む価値があります！

削除するものが125個あります。

🤔どういうわけか、このスレッドで少し皮肉が起こっているような気がします...🙃

皆さん、私は本当に欲求不満を感じます。 以前のコメントからの声明を繰り返します。サポートに。 残しておきたい古いバージョンの数をお知らせください。

暫定的なバンドエイドソリューションをリリースしない理由については、サポート介入がバンドエイドです。 交換に積極的に取り組んでいるシステムで限られたエンジニアリングリソースを燃やしたくないので、これは少し難しい場所になってしまいます。

ほら、誰かがこのスレッドに関連するかもしれない要点を

PS私たちはまだより良い自動化されたソリューションに取り組んでいますが、それまでの間、これははるかに優れたバンドエイドです。 😼

回避策を提供するために時間を割いていただきありがとうございます。

上記の要点のスクリプトは、バージョンの削除に関しては正常に機能しますが、ストレージ使用量が低下しません（バージョンの削除後にこれを再計算するのに時間がかかりますか？）

バージョンの削除後にこれを再計算するのに時間がかかりますか？

私の経験では、そうです。 GUIを使用して多数のバージョンを手動で削除した場合でも、使用数が変更されるまでには時間がかかります。

はるかに優れたバンドエイドを提供してくれた@mbleighに本当に感謝します。 ：祈る：

@mbleighの更新はありますか？

ホスティングRESTAPI @alexanderwhatleyはUIソリューションではありませんが、新しいHosting Rest APIを使用すると、デプロイメントを調整するために必要なすべてのことを実行できるはずです。

RESTAPIのホスティング

@jackcwを調べましたか？ 原因私はcreateとlistメソッドしか見つけることができません。 deleteメソッドはありません。

私は実際にそれを使用していませんが、バージョンエンドポイントに削除があり、リリースのが含まれているので、リリースのリストを作成し、バージョンIDを取得して、バージョン削除エンドポイントにアクセスすると仮定します

申し訳ありません。 バージョンやリリースの意味を誤解しました。 APIを使用したバージョンと呼ばれる古いリリースを削除できるようになりました。

古いリリースをすべて削除するために、cronジョブを使用して1日1回実行される小さなシェルスクリプトを作成しました。
ここに要点があります。 JSONを解析するにはjqが必要@jackcwが書いたことを

私はシェルスクリプトやjqの作成の専門家ではありませんが、結果が重要だと思います。 スクリプトは私にとって非常に確実に機能します。 お気軽にご利用ください。

内部追跡ID：113235359

これに関する更新はありますか？

積極的に取り組んでいます。 🙂

こんにちは、みなさん！

Firebaseコンソールでバージョン履歴の保持を管理できるようになりました。

大規模なサイトをお持ちの方は、これでコストを抑えることができます。

みんなの利益のために、 @ samtsternが話している上記の機能は、私たちが取り組んでいると言ったことです。 それが人々が彼らのバージョン履歴をうまく処理するのに役立つことを願っています！

機能をありがとう！ ただし、まだいくつかのバグがあるようです。

@twistedpair ：cry：

この機能は機能していないようです。設定には1バージョンの上限がありますが、リストには削除されていないバージョンがたくさんあります。

@sharno

それは私たちのプロジェクトで完璧に機能します。
ビルドの制限は10で、ビルド11以降は「自動削除」されます

@billiaugありがとう

再度一定の数値に設定して動作を開始しました。 以前にこの値を設定していなかったためかもしれないので、ダイアログを開いて1を見たとき、すでに適用されていると思いましたが、適用されていませんでした

@sharnoと同じことに気づきました。 デフォルト設定では値が1に設定されていますが、設定を開いて初めて[保存]をクリックするまで、これは有効になりません。 その後、すべてが期待どおりに機能します。

新しいFirebaseプロジェクトでレプリケートするには、サイトを数回デプロイして、リリース履歴にいくつかのデプロイがあるようにします。 デフォルト値1が表示されている_Versionhistory settings_を開き、_Save_をクリックします。 ページを更新すると、現在以外の以前のすべてのデプロイメントのステータスは_Auto-deleted_になります。

おそらく、_Version history settings_ modalは、設定がデフォルトでは有効ではなく、ユーザーの操作を有効にする必要があることを言及または反映する必要があります。 例：

または、ユーザーが値の設定を解除できるようにする別の方法：

少なくともFirebaseヘルプ-保持されるバージョンの制限を設定すると、デフォルトがより適切に説明されるはずです。

同様のクエリがありますが、Firebaseホスティングではなく、Firebase関数についてです。 各機能のデプロイには、400MB以上のFirebaseストレージスペースが必要です。 私はfirebasecliのエキスパートユーザーではありませんが、GCPコンテナレジストリにアクセスすると、コンテナを1つずつ削除するオプションが提供されます

Firebaseコンソールは、現在リリースをホストする場合と同じように、古い関数コンテナを自動削除する方法を提供しますか？

PS：そのために新しい問題を開く必要がありますか？

@DibyodyutiMondalは間違いなく新しい問題です。

@ DibyodyutiMondal-新しい号を開きましたか？ もしそうなら、ここにそれへのリンクを入れてください、そうすれば見つけやすくなります。