test(kit): o cron sem crontab prévio ganha a prova das DUAS funções no mesmo processo (@rafaelbatistazz, do #726) - #735
test(kit): o cron sem crontab prévio ganha a prova das DUAS funções no mesmo processo (@rafaelbatistazz, do #726)#735melgarafael wants to merge 3 commits into
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 #715
# Conflicts: # hostgator-setup-kit/_common.sh
@rafaelbatistazz escreveu um fragmento para o mesmo conserto que o #709 (de @luiscgc91) já trouxe. Dois fragmentos para uma mudança produzem **duas entradas** no CHANGELOG de quem atualiza, descrevendo a mesma coisa — e quem lê fica procurando a diferença entre elas. Fica o que já está na fila da v1.20.0. Mas **o texto dele é melhor**, e por um motivo concreto: ele nomeia o que a pessoa VÊ. "Para logo depois de «chave de cifra ativa no banco»", "mostra «A instalação parou»", "com o CRM já no ar", "rodar de novo contornava" — é a descrição de quem viveu, não de quem leu o diff. Esse texto foi para a seção da v1.20.0 no PR de release, com o crédito dos dois. O que fica deste PR é o que ele acrescenta de verdade: o teste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 2 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 2 changed file(s). No taxonomy bucket signals were detected. Scanned 2 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 2 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 2 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. |
2 participants
Reconciliação do #726 de @rafaelbatistazz. O PR original fecha como mergeado.
A parte mais importante deste PR não é o código
@rafaelbatistazz achou, de forma independente, o mesmo defeito que @luiscgc91 achou no mesmo dia (#683 → #709, já na
main). E os dois escreveram exatamente a mesma linha:O conflito do merge foi só de comentário — o código era idêntico, caractere por caractere. Isso não é redundância: é a medida de quanto o defeito doía. Duas pessoas que não se falaram, no mesmo dia, instalando numa VPS limpa.
Ele também abriu a issue #715, que descreve o sintoma como quem o viveu: o instalador para logo depois de "✓ chave de cifra ativa no banco", cai em "A instalação parou", e os contêineres estão saudáveis. Rodar de novo passa — porque aí o crontab já não está vazio, o que faz o defeito parecer fantasma.
O que este PR acrescenta de verdade
O teste dele é melhor que o meu, e por uma razão concreta. O meu (
tests/shell/cron-sem-crontab-previo.test.sh) roda cada função isolada. O dele roda as duas no mesmo processo — como oinstall.shfaz — e confere que as duas linhas foram gravadas:E ele plugou no lugar certo: o bloco entra em
hostgator-setup-kit/test-validators.sh, reusando o dublê decrontabcomCRONTAB_SANDBOXque já existia. 27 linhas, nenhuma infraestrutura nova. Os dois testes ficam — eles medem coisas diferentes, e o comentário do_common.shagora diz qual mede o quê.pnpm test:shellcompleto → exit 0, com os dois blocos verdes.O que eu mudei
_common.shvirou um só, com os dois nomes, a issue install.sh morre em "Ativando as automações" quando o crontab do root está vazio #715 e o sintoma que ela descreve. Ele é longo de propósito: existe para a terceira pessoa não precisar descobrir isso de novo..changes/. Dois fragmentos para uma mudança produzem duas entradas no CHANGELOG, descrevendo a mesma coisa — e quem lê fica procurando a diferença. Mas o texto dele é melhor, então ele foi para a seção da v1.20.0 no PR de release (Release 1.20.0 #734), com o crédito dos dois.NÃO MEDIDO
Uma instalação real numa VPS virgem, de ponta a ponta. O que está medido é o mecanismo, no arquivo real, com o mesmo
set -euo pipefaildo instalador.Fecha #726. Fecha #715.