Aviso: Erro nos Deploy Previews about tabnews.com.br

[rhandrade]

Pelo que eu entendi da imagem que o @filipedeschamps postou o que está estourando é a otimização das imagens usadas no projeto. Esse limite de otimização também está na doc da Versel.

Dando uma olhada na documentação da Versel nesse item, ela fala que todas as imagens usando o componente next/image serão otimizados pela estrutura deles.

Nesse outro trecho fala que se não tiver setado o valor max-age no header Cache-control a versel aplicará um cache padrão de 60s, mas que se um novo deploy for realizado a Versel irá otimizar novamente as imagens para garantir que a versão mais atual está sendo exibida para o usuário.

Acredito que como temos muitas imagens dos membros que participaram do init e quando estava na conta free qualquer membro poderia fazer um deploy preview via Git, isso estava estourando os limites de otimização da conta, e provavelmente voltarão a ocorrer se fizermos vários deploys em um único mês.

Nessa página (print abaixo) a Versel da um exemplo de como usar a chamada do componente e reparei que nós no momento não especificamos o width e height. Talvez isso ajudaria também. Outro ponto seria estabelecer esse max-age no Cache-control ao obter o path para a imagem do colaborador. Como a ideia é ser algo de lembrança, podemos deixar um cache grande até.

Eu não manjo de React, mas quem souber pode fazer essas alterações para ver se normaliza os limites da conta.

[rhandrade]

Talvez poderíamos usar essa ideia junto com o Github actions para permitir que se um PR tiver uma tag específica, por exemplo need-preview, o merge possa ocorrer da branch solicitada para a preview e assim verificar se a integração da Vercel entenderia esse processo como sendo proveniente do autor da conta e fizesse o deploy dentro da estrutura deles.

Somente as PR com essa tag teriam esse tratamento e não afetariam a branch principal. Qualquer outra PR que não tivesse essa tag seria desconsiderada. Isso garantiria também que somente as PR que realmente precisassem ser feitas o deploy fossem processadas. Talvez isso garantia que os limites da conta, mesmo da PRO, não sejam estourados.

Existem algumas actions que fazem essa automação pelo que pesquisei.
https://github.com/pascalgn/automerge-action
https://github.com/marketplace/actions/branch-merge

Talvez seja um modo de manter essa dinamica que temos hoje de criar URLs de preview. Será que isso daria certo @filipedeschamps?

[filipedeschamps]

Talvez poderíamos usar essa ideia junto com o Github actions para permitir que se um PR tiver uma tag específica, por exemplo need-preview, o merge possa ocorrer da branch solicitada para a preview e assim verificar se a integração da Vercel entenderia esse processo como sendo proveniente do autor da conta e fizesse o deploy dentro da estrutura deles.

Excelente essa ideia @rhandrade ! E você também apontou de forma precisa o que estourou no limite da conta Hobby e o que me surpreendeu ao fazer o upgrade para a conta Pro é o número de assentos para pessoas conseguirem fazer o deploy lá na infra de Preview (e por consequência, Production).

E vendo aqui, o business da Vercel gira principalmente ao redor de quantas pessoas podem fazer o deploy, então se "arranjarmos" um jeito automatizado de burlar isso, provavelmente estaremos indo contra algum termo ou naturalmente contra o que o business deles se propõe, e isso não é legal nem sustentável.

Então por hora, vamos respeitar esse limite e entender até que ponto o fluxo de eu fazer o merge manual para uma outra branch (apenas se o PR for de fato aprovado) se sustenta.

Vou fechar a issue, mas podemos ir conversando, combinado? 🤝 👍

[huogerac]

1. No relatório tem mais detalhes do que está fazendo estourar? será que é a parte do frontend (páginas, nro de acesso), a parte server side? ou a parte de CI/Devops, muitos commits, cada um gerando uma "versao" da aplicação rodando?

Desculpa, mas pra mim não está claro oq exatamente está fazendo estourar o limite, pq nesta fase aparentemente não tem muito acessos, nem muito PRs gerando diversas versões, tirando a parte server side (que não sei muito como a Vercel faz a mágica), acredito que o restante da aplicação não deveria chegar no limite

2. Vi que a Vercel, tem upgrade do FREE para o PRO por $20 e depois só enterprice, certo? não é como Heroku que vai crescendo CPU/Memória conforme precisa.
   Será que Vercel para o backend é a melhor opção mesmo? Fiquei surpreso já ter chego no limite, bem antes do que eu estava imaginando

Enfim, se conseguirem mais detalhes da causa, dai vamos pensar juntos nas opções, qual dos itens abaixo está no limite:

Abraço