Firebase-tools: Listar e excluir implantações

@Nowaker Isso está definitivamente em nosso radar e algo que estamos procurando melhorar

hey @brendanlim alguma atualização aqui? Também estamos vendo carregamento infinito no módulo de hospedagem, parece que temos muitas implantações :(

Obrigado!

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 Alguma atualização sobre isso? Nosso histórico de implantação está crescendo constantemente, cada construção de CI por vez, e está além de nossas capacidades humanas para acompanhar a exclusão deles!

Estamos cientes do problema aqui e considerando a melhor maneira de resolvê-lo. Em geral, não queremos que você se preocupe em ter um histórico crescente de versões. Curioso para quem se depara com isso (vote com emoji neste comentário): qual você mais gosta?

• : tada: A capacidade de listar e possivelmente excluir em lote versões antigas
• : +1: as versões antigas são mantidas apenas por um determinado período de tempo, a menos que sejam "fixadas" de alguma forma
• : heart: Apenas um certo número de versões antigas são mantidas, a menos que "fixadas" de alguma forma

"A capacidade de listar e possivelmente excluir em lote versões antigas" é um princípio primitivo. APIs são construídas usando primitivas. Esses primitivos permitem que os usuários alcancem o que desejam sem incomodar ninguém (neste caso, você @mbleigh).

Os outros dois são recursos de alto nível. Eles são legais. Mas então surge uma pergunta: como faço para fixar ou liberar a versão via API ou firebase-tools ? Como você pode imaginar, mais uma vez, alguém terá que clicar na lista na IU do Firebase, um por um, da mesma forma que excluirá implantações antigas hoje. : rofl:

Resumindo, os recursos de alto nível são ótimos e necessários, mas os primitivos CRUD na API são muito importantes para ferramentas como Google Cloud Platform ou Firebase.

@Nowaker Eu não discordo, e ambos são importantes. É justo dizer que é uma falsa dicotomia entre a primeira opção e as outras duas. FWIW, para implementar as duas segundas opções, teríamos que implementar tudo o que é necessário para a primeira de qualquer maneira.

Esse material está definitivamente em nosso radar, mas não tenho detalhes sobre quando teremos algo para mostrar.

Eu me contentaria com uma caixa de seleção para selecionar todas / várias entradas em uma página e excluí-las de uma vez. Além disso, torne possível descartar a caixa de diálogo de confirmação pressionando enter para confirmar.

Você também não pode ocultar a funcionalidade de exclusão. Agora você:

1. Linha de implantação de rollover.
2. Clique no menu de três pontos.
3. Clique em deletar para acessar a confirmação.
4. Clique em deletar novamente.

Se cada linha tivesse seu próprio botão de exclusão e você pudesse segurar a tecla shift para ignorar a confirmação, você poderia voar através deles.

Uma API REST para listar e excluir implantações está disponível, se alguém quiser implementar essa funcionalidade por conta própria (ou mesmo implementá-la em firebase-tools e enviar um PR)? Se os pontos de extremidade simplesmente não estiverem lá, posso ver como isso pode ser um problema de bloqueio. Isso está em algum tipo de roteiro com algo semelhante a uma data de vencimento?

Alguma novidade sobre isso? Definitivamente ajudaria ter uma maneira simples de remover implantações anteriores na CLI. Obrigado pelo bom trabalho.

Ainda não há novidades, mas é uma área de interesse ativo para a equipa. Obrigado pela sua paciência!

Alguma novidade sobre isso? Temos tantos que devemos remover manualmente, um por um.

Também apreciaria realmente algum progresso nisso!

Estamos trabalhando muito em nossa infraestrutura de implantação agora, o que levará um pouco de tempo para ser concretizado. Esse problema está definitivamente em nossa mente enquanto fazemos esse trabalho.

@mbleigh ei, que tal bloquear este tópico. Gostaria de ser notificado quando estiver pronto, mas realmente não quero ler todos os comentários "eu também".

"Apenas um certo número de versões antigas são mantidas, a menos que" fixadas "de alguma forma" seja exatamente o que precisamos.

O outro problema que tenho é que, quando olho para esta lista de implantações, não tenho ideia de qual é qual. Eu faço a versão do meu aplicativo de algumas maneiras, incluindo a versão em package.json e uma noção de "builds", então também posso fornecer uma versão e / ou build # para firebase deploy e, se isso poderia ser listado na lista de versões implantadas, seria fantástico. Do jeito que está, vejo 100 versões implantadas e não tenho ideia de qual é.

@rtm Você pode especificar uma mensagem para implantações que é mostrada na lista de implantações:

firebase deploy --message "build 1234"

A opção não está listada nas páginas de documentação, mas é listada durante a execução:
firebase help deploy

@ a-xin Obrigado. Eu tinha perdido isso totalmente e é muito útil!

Seria ótimo se a prioridade desse problema pudesse ser aumentada, já que fazemos implantação contínua de cada git commit, e cada implantação tem algumas centenas de MB. Seria bom se pudéssemos integrar alguns comandos para limpar implantações antigas também no script do CD, a fim de reduzir o consumo geral de armazenamento.

Como solução alternativa, seria possível reutilizar os arquivos cujo nome de arquivo e conteúdo não foram alterados (de acordo com algum hash)?

Por exemplo, se o Webpack gera pedaços com hashes estáveis ​​(por exemplo, empregando HashedModuleIdsPlugin ), esses arquivos são carregados em cada implantação (mesmo que eles realmente não tenham mudado)?

Isso poderia reduzir significativamente a quantidade de atualizações de arquivo em cada implantação (até kbytes do código do nosso aplicativo, se as bibliotecas do fornecedor não tiverem mudado).

Esta não é uma baixa prioridade para nós. Estamos trabalhando para habilitar
infraestrutura para lidar com esse problema agora, mas há grandes mudanças
necessário fazer o que queremos fazer. Vai demorar um pouco, obrigado pelo
feedback e sua paciência.

No domingo, 25 de fevereiro de 2018, 15:32 Denis Loginov [email protected]
escreveu:

Como solução temporária, seria possível reutilizar os arquivos cujo
nome do arquivo e conteúdo não mudou (de acordo com algum hash)?

Por exemplo, se o Webpack gera pedaços com hashes estáveis ​​(por exemplo, empregando
HashedModuleIdsPlugin), esses arquivos são carregados em cada implantação (mesmo
embora eles realmente não tenham mudado)?

Isso poderia reduzir significativamente a quantidade de atualizações de arquivos em cada
implantação (até kbytes de nosso código de aplicativo, se as bibliotecas do fornecedor não
chagned).

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-368355645 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAD_nbNy4j3gsIpTk_YpLyhlAuPtNHOks5tYe2DgaJpZM4J0BKU
.

Fico feliz em ver que esta é uma prioridade. Estou no plano Spark e tenho um aplicativo da web que está em torno de 20 MB. Tenho sido um pouco liberal com minhas implantações, então tenho 300 para examinar e excluir. 😅

Além do número limitado de implantações na história, também gosto da ideia de @dinvlad de reutilizar arquivos.

@sejr uma coisa que eu faço que ajuda é usar o teclado o máximo possível.
Eu clico nas elipses, bato na seta para baixo e entro, depois o botão Tab 3 vezes e entro
E repita ... espero que ajude.

@mbleigh Alguma notícia ou progresso sobre isso?

@mbleigh, você pode nos dar um status?

@mbleigh Ansioso por mais transparência. Talvez você pudesse elaborar mais sobre o roteiro geral do firebase-tools e os planos em relação a esse problema.
(É a questão mais votada aliás, quase o dobro dos votos em comparação com a segunda questão mais votada).

Desculpe pela longa demora em resolver isso - está no topo da nossa lista, mas temos investido pesadamente em um projeto de infraestrutura que define a base para assumir muitos projetos menores como este.

Não posso prometer prazos exatos, mas isso definitivamente não foi esquecido.

Talvez não esquecido, mas certamente ignorado . Uma implantação pode ser excluída na IU com alguns cliques - não há razão para que a mesma não possa ser facilmente exposta via API. Estou extremamente decepcionado com o roteiro do produto Firebase, bem como com o destino do Divshot.

Eu entendo a frustração, de verdade. Este problema está sendo resolvido pelo trabalho
estamos fazendo agora e esperamos trazer para todos vocês em um futuro próximo.

Na sexta-feira, 29 de junho de 2018, 1:01, Damian Nowak [email protected] escreveu:

Talvez não esquecido, mas certamente ignorado . Uma implantação pode ser excluída
na interface do usuário com alguns cliques - não há razão para que o mesmo não possa ser
facilmente exposta via API. Estou extremamente decepcionado com o produto Firebase
roteiro, bem como o destino de Divshot.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/215#issuecomment-401279887 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAD_t_BTD_cT8eWOABg8sfs9Lf1n9g8ks5uBd7SgaJpZM4J0BKU
.

@mbleigh

mas há grandes mudanças necessárias para fazer o que queremos fazer.

Talvez as massas fervilhantes fossem pacificadas por algum aceno de mão adequadamente vago sobre o que são essas grandes mudanças e que outras características de estilhaçar a terra elas possibilitariam. Se isso falhar, não é irracional para algumas pessoas se intrometerem sobre o que parece ser simplesmente ignorar o recurso, já que está acontecendo há quase dois anos.

É muito simples - o Firebase Hosting nunca teve uma API pública e o método atual para listar e excluir implantações no console não é adequado para divulgação. Como a CLI é de código aberto, precisamos nos certificar de que todas as ações expostas por meio dela sejam adequadamente escalonáveis.

Estamos em processo de migração de uma grande parte do Firebase Hosting para a infraestrutura do Google, o que o tornará mais escalonável e também fornecerá uma base sólida para ter APIs adequadas para as coisas. Esse esforço é muito bom para a integridade a longo prazo do Firebase Hosting, mas foi um investimento substancial para a equipe que resultou em um longo período sem progresso aparente.

Agradeço que muitos de vocês se sintam firmes sobre isso - se você entrar em contato com o suporte, ficaremos felizes em podar manualmente suas implantações mais antigas nesse ínterim. Esperamos que a espera não seja muito mais longa, mas como acontece com qualquer software, escolher datas exatas para as coisas geralmente é uma má ideia.

Espero que isso esclareça um pouco as coisas, e obrigado a todos os usuários do Firebase Hosting por nos apoiar 😄

@mbleigh Muito obrigado pelo

@mbleigh Não sei por que você precisa tornar esta tarefa dependente de uma API pública ou de qualquer alteração de infraestrutura.

Isso pode ser resolvido em curto prazo com um botão no console do Firebase "Eliminar implantações antigas".

Como o console já está fazendo chamadas para o back-end, ele pode obter uma lista de todas as implantações e, em seguida, chamar delete. Estou assumindo que a API no back-end não leva uma lista de lotes de implantações, portanto, este botão pode causar alguns problemas se você fizer isso de forma síncrona com uma implantação por vez.

De qualquer forma, o ponto é que não exagere na engenharia de uma solução quando tudo o que você precisa fazer é adicionar um botão a uma API já estabelecida em seu back-end. Especialmente, não faça seus usuários esperarem 2 anos por isso.

Nem um pouco profissional.

Não sei do que todo mundo está reclamando. É RELAXANTE excluir implantações antigas uma por uma. Acabei de limpar um acúmulo de 72. Em seguida, houve uma verificação dupla para ter certeza de que peguei todos (perdi um) - novamente muito satisfatório. Eu me sentia virtuoso e ouso dizer SUPERIOR. Cuidando dos detalhes; diligência devida. Metade administrativa! Meu único arrependimento era não ter MAIS para esclarecer. Na verdade, tive que jogar paciência por UMA HORA INTEIRA depois, apenas para me sentir bem o suficiente para passar para a minha próxima tarefa.

E dois anos (e contando) para obter esse recurso?!? Pfftt. Todo mundo sabe que os engenheiros precisam ter o CARE para fazer essas coisas da maneira certa! E é um enorme ORÇAMENTO que é necessário. Quero dizer, pense em todo o esforço que o WAYMO e o resto da Alphabet estão fazendo. O Google POSSIVELMENTE não poderia se dar ao luxo de colocar mais recursos neste recurso.

Além disso, somos apenas DESENVOLVEDORES! DOUBLE Pfftt. Como você espera que o Google sobreviva colocando DESENVOLVEDORES no topo da fila?!? Eu quero dizer realmente!

Não, para o bem de todos nós, e particularmente para nosso bem-estar, eu pessoalmente voto para que a equipe de desenvolvimento aqui continue trabalhando nisso por pelo menos mais dois anos antes de implementar esse recurso. Pelo amor de Deus, tenha cuidado! Não seja precipitado; não se apresse!

E pelo amor de Deus, não faça nada impulsivo como ter um recurso temporário de um botão de exclusão rápido ou algo parecido; isso apenas desviaria recursos de coisas muito mais importantes.

Tudo bem como está; por favor, não faça NENHUMA mudança em seu processo, como, por exemplo, mudanças de GERENCIAMENTO!

Opa, preciso desligar. É hora do meu cochilo (estou exausto de toda a concentração necessária para excluir todas aquelas implantações). E além disso com um tempo tão produtivo, com certeza mereço uma folga!

Tenho 125 deles para excluir.

🤔 De alguma forma, sinto que há um pouco de sarcasmo acontecendo neste tópico ... 🙃

Gente, eu realmente entendo a frustração. Para reiterar uma declaração do meu comentário anterior: se você entrar em contato com o suporte , ficaremos felizes em podar manualmente suas implantações mais antigas em seu nome nesse ínterim . Diga-nos quantas versões antigas você gostaria de manter.

Quanto ao motivo pelo qual não estamos lançando uma solução provisória de band-aid - bem, a intervenção de suporte é nosso band-aid. Preferimos não queimar recursos de engenharia limitados em um sistema que estamos trabalhando ativamente para substituir, e é por isso que isso acaba em uma situação um pouco difícil.

Olha, alguém parece ter abandonado um ponto essencial que pode ser relevante para este tópico ...

PS: Ainda estamos trabalhando em uma solução automatizada melhor, mas, por enquanto, este é um band-aid muito melhor. 😼

Obrigado por dedicar seu tempo para fornecer uma solução alternativa.

O script na essência acima funciona bem em termos de exclusão de versões, mas não vejo meu uso de armazenamento diminuir (leva algum tempo para recalcular isso após as exclusões das versões?)

demora um pouco para recalcular isso após as exclusões das versões?

Na minha experiência, sim. Mesmo se você usar a interface do usuário para excluir manualmente um grupo de versões, leva algum tempo para que os números de uso mudem.

Muito obrigado a @mbleigh por nos fornecer um band-aid muito melhor. :rezar:

Alguma atualização @mbleigh?

Você já viu a api de hosting resto @alexanderwhatley? Não é uma solução de IU, mas a nova API de Hosting Rest deve permitir que você faça tudo o que precisa para ajustar suas implantações

API REST de hospedagem

Você já olhou para isso @jackcw ? Porque só consigo encontrar os métodos create e list . Nenhum método delete .

Eu não usei realmente, mas pelo que posso ver, há uma exclusão no endpoint de versões e a lista de lançamentos inclui o objeto de versão, então presumo que você faça uma lista de lançamentos e pegue o id da versão e acesse os endpoints de exclusão da versão

Desculpe, minha culpa. Eu entendi mal o significado de versões e lançamentos. Agora você pode excluir versões mais antigas, chamadas de versões com a API.

Criei um pequeno script de shell que é executado uma vez por dia com um cron job para remover todas as versões antigas.
Aqui está a essência . Requer jq para analisar o JSON. Ele basicamente faz o que @jackcw escreveu: itera sobre todos os lançamentos e os exclui.

Não sou um especialista em escrever scripts de shell ou jq - mas o resultado é o que conta, eu acho. O script funciona de forma bastante confiável para mim. Sinta-se à vontade para usá-lo.

ID de rastreamento interno: 113235359

Alguma atualização sobre isso?

Está sendo trabalhado ativamente. 🙂

Ei pessoal!

Agora você pode gerenciar a retenção do histórico de sua versão no Firebase console:

Para aqueles que têm sites grandes, isso deve ajudá-los a manter os custos baixos.

Para o benefício de todos, o recurso acima de que @samtstern está falando é o que eu disse que estávamos trabalhando. Espero que ajude as pessoas a manter um bom controle sobre seu histórico de versões!

Obrigado pelo recurso! Parece que ainda existem alguns bugs.

@twistedpair : cry: huh, você pode entrar em contato com o suporte do Firebase, de preferência com o erro que está obtendo no painel Rede das ferramentas de desenvolvimento? Isso definitivamente não deveria acontecer.

O recurso parece não estar funcionando, temos um limite máximo de 1 versão nas configurações, mas uma tonelada de versões na lista que nunca foram excluídas!

@sharno

Funciona perfeitamente em nossos projetos.
Temos um limite de 10 builds e a partir do build 11, eles são "excluídos automaticamente"

@billiaug Obrigado

Eu o configurei novamente para um certo número e ele começou a funcionar. Acho que pode ter sido porque não definimos esse valor antes, então, quando abri a caixa de diálogo e vi 1, presumi que já estava aplicado, mas não estava

Eu notei o mesmo que @sharno. As configurações padrão definem o valor como 1, no entanto, isso não terá efeito até que as configurações sejam abertas e eu clique em _Salvar_ pela primeira vez. Em seguida, tudo funciona conforme o esperado.

Para replicar em um novo projeto Firebase, implante um site várias vezes para que haja algumas implantações no histórico de lançamento. Abra as _configurações do histórico de versões_, que mostra o valor padrão 1, e clique em _Salvar_. Atualizar a página e todas as implantações anteriores, exceto a atual, devem ter um status de _Auto-excluído_.

Talvez o modal de _Configurações do histórico de versão_ deva mencionar ou refletir que a configuração não está em vigor por padrão e requer que a ação do usuário seja ativada. Exemplo:

Ou algo diferente, permitindo aos usuários cancelar a definição de um valor:

No mínimo, a ajuda do Firebase - definir o limite para versões retidas deve descrever melhor os padrões.

Eu tenho uma consulta semelhante, mas não para a hospedagem do Firebase, e sim para as funções do Firebase. Cada implantação de funções ocupa mais de 400 MB do espaço de armazenamento do firebase. Não sou um usuário especialista do firebase cli, mas acessar o registro de contêiner do GCP oferece a opção de excluir os contêineres um por um

O Firebase console fornece uma maneira de excluir automaticamente os contêineres de função mais antigos, assim como faz atualmente para hospedar versões?

PS: Devo abrir uma nova edição para isso?

@DibyodyutiMondal definitivamente um novo problema.

@DibyodyutiMondal - você abriu um novo problema? Em caso afirmativo, coloque um link para ele aqui, para que seja mais fácil de encontrar.