fix(kit): o instalador não para em "Ativando as automações" numa VPS sem crontab - #726
Conversation
…sem crontab
Numa VPS nova o root não tem crontab: `crontab -l` sai 1 ("no crontab for
root"), e sob o `set -euo pipefail` do install.sh o cano inteiro falhava. O
`set -e` derrubava o script logo depois de o `crontab -` já ter gravado a
linha do drain, e a pessoa via "A instalação parou" com o CRM no ar.
`{ crontab -l 2>/dev/null || true; }` nas duas funções que agendam
(setup_event_log_drain_cron e setup_update_agent_cron).
O dublê de crontab da suíte já simulava o "no crontab", mas nenhuma rodada
agendava com o sandbox vazio. O teste novo roda as duas funções sob o mesmo
`set -euo pipefail`, sem crontab prévio, e cobra as duas linhas gravadas.
Closes melgarafael#715
|
@rafaelbatistazz is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 3 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy clear (success) Scanned 3 changed file(s). No taxonomy bucket signals were detected. Scanned 3 changed file(s). No PR taxonomy bucket signals were detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 3 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 3 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @rafaelbatistazz — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
|
Recebido, @rafaelbatistazz — e eu preciso te contar uma coisa antes de qualquer outra: você achou o mesmo defeito que outra pessoa achou hoje, de forma independente, e o conserto entrou na Isso não diminui o seu trabalho — aumenta o peso do achado. Quando duas pessoas que não se falaram tropeçam no mesmo ponto no mesmo dia, isso não é coincidência: é medida de quanto ele doía. E o fato de vocês dois terem instalado numa VPS limpa e visto o script morrer é exatamente o tipo de prova que nenhum teste automático nosso estava dando. Vou medir o seu de verdade mesmo assim, e por dois motivos que não são consolo:
Duas coisas que vão parecer erro seu e não são:
Volto com o resultado. Se o seu for equivalente, o crédito pelo achado é seu também, e eu registro isso. |
2 participants
O que muda para quem usa
Numa VPS nova, o
install.shparava logo depois de✓ chave de cifra ativa no banco, sem erro nenhum na tela, e mostrava "A instalação parou" — com os contêineres já saudáveis e o CRM no ar. Rodar o instalador de novo passava, o que escondia a causa.O motivo é o crontab vazio: numa máquina recém-criada o root não tem agendamento,
crontab -lsai1("no crontab for root") e, sob oset -euo pipefaildoinstall.sh(linha 12), o cano inteiro devolvia1. Oset -ederrubava o script depois de ocrontab -já ter gravado a linha do drain; o2>/dev/nullescondia a mensagem, por isso a tela não dizia nada.O conserto tolera o crontab vazio nas duas funções que agendam —
setup_event_log_drain_cronesetup_update_agent_cron:( { crontab -l 2>/dev/null || true; } | cron_merge ... ) | crontab -Closes #715
O teste
O dublê de
crontabda suíte já simulava o "no crontab" (sai1quando o sandbox não existe), mas nenhuma rodada agendava com ele vazio — as rodadas de integração já tinham linhas gravadas quando chegavam ali. O teste novo monta uma fixture própria, aponta o sandbox para um arquivo que não existe e roda as duas funções sob o mesmoset -euo pipefaildo instalador, cobrando as duas linhas no fim.O que eu medi
Sabotagem (revertendo só a linha do conserto, sem desfazer o commit): previ 1 vermelho, o do teste novo, e foi exatamente isso —
257 ✓ / 1 ✗, com a mensagem✗ agendar o cron numa VPS sem crontab derrubou o script (saída 1). Restaurei depois.Onde achei: instalando numa VPS que já tinha o Traefik da Coolify nas portas 80/443 (
REVERSE_PROXY=traefik, detectado pelo próprio instalador), em modo--yes.O que NÃO medi
pnpm test:dbepnpm test:e2e— não rodei. A mudança é de shell e não toca schema nem UI, mas fica declarado.⚠ marca/config de instalação no diffapontando paraNEXT_PUBLIC_APP_URL=https://crm.exemplo.com.br— é valor de fixture do meu teste, o mesmo domínio de exemplo que o resto da suíte usa, não marca de instalação.🤖 Generated with Claude Code