Correção de horario e implantação da geração de Romaneio

bin/docker-boot

@@ -0,0 +1,76 @@
+#!/usr/bin/env bash
+#
+# Boot do container do Rails (deploy e todo restart do Docker).
+#
+# POR QUE ISSO VIROU UM SCRIPT: antes era um `command:` de uma linha só no
+# docker-compose.yml. Com `restart: unless-stopped` o boot passou a rodar
+# sozinho — depois de queda, de reboot do servidor e de cada deploy — e um
+# passo que falha em silêncio vira loop de reinício sem ninguém entender por
+# quê. Aqui cada etapa diz o que está fazendo no log do container
+# (`docker compose logs -f app`).
+#
+# ORDEM DOS PASSOS (não troque sem ler o motivo):
+#   1. relógio      — só imprime, para diagnóstico (ver comentário abaixo).
+#   2. pid órfão    — se o container morreu sem limpar, o Puma se recusa a subir.
+#   3. gems         — o volume bundle_cache SOMBREIA os gems da imagem, então
+#                     gem nova no Gemfile não chega no container só com --build.
+#   4. migrations   — db:prepare: cria o banco se não existir, roda as migrations
+#                     pendentes e só faz seed em banco recém-criado (idempotente).
+#   5. cron         — grava o crontab do config/schedule.rb e sobe o daemon.
+#   6. Puma         — processo em primeiro plano (é ele que segura o container).
+set -uo pipefail
+
+log() { echo "[boot] $*"; }
+
+# ── 1. Relógio ───────────────────────────────────────────────────────────────
+# O container NÃO tem relógio próprio: ele lê o clock do kernel do HOST. Não
+# adianta rodar NTP aqui dentro (exigiria CAP_SYS_TIME e mexeria na hora do
+# servidor inteiro) — quem sincroniza é o host, via chrony/NTS; ver
+# deploy/ntp-seguro.sh. O que é do container é só o FUSO (TZ), fixado no
+# Dockerfile. Se a linha abaixo aparecer em UTC, o rebuild da imagem não pegou.
+log "relógio do container: $(date '+%Y-%m-%d %H:%M:%S %Z (%z)')  |  UTC: $(date -u '+%H:%M:%S')"
+
+# ── 2. PID órfão do Puma ─────────────────────────────────────────────────────
+rm -f tmp/pids/server.pid
+
+# ── 3. Gems ──────────────────────────────────────────────────────────────────
+if ! bundle check >/dev/null 2>&1; then
+  log "gem faltando no volume bundle_cache — rodando bundle install"
+  bundle install || { log "ERRO: bundle install falhou"; exit 1; }
+fi
+
+# ── 4. Migrations ────────────────────────────────────────────────────────────
+# O PostgreSQL é EXTERNO ao compose: num reboot do servidor o Rails pode subir
+# antes do banco aceitar conexão. Sem a espera abaixo o container sairia com
+# erro e o `restart: unless-stopped` ficaria reiniciando em loop — parecendo
+# problema de migration quando é só ordem de boot. 10 tentativas × 6s = 1 min.
+tentativas=10
+for i in $(seq 1 $tentativas); do
+  log "migrations (db:prepare) — tentativa $i/$tentativas"
+  if bundle exec rails db:prepare; then
+    log "banco pronto e migrations aplicadas"
+    break
+  fi
+  if [ "$i" -eq "$tentativas" ]; then
+    # Aqui é falha DE VERDADE (migration quebrada ou credencial errada): sair
+    # com erro é melhor do que subir a aplicação contra um schema desatualizado.
+    log "ERRO: db:prepare falhou após $tentativas tentativas — veja o erro acima"
+    exit 1
+  fi
+  log "banco indisponível ou migration falhou; nova tentativa em 6s"
+  sleep 6
+done
+
+# ── 5. Cron (best-effort) ────────────────────────────────────────────────────
+# Best-effort de propósito: agendamento quebrado atrasa um relatório, mas NUNCA
+# pode impedir o sistema de subir. As variáveis do banco chegam ao job pelo
+# dotenv quando o rake carrega o Rails — o cron não precisa herdar o ENV.
+if bundle exec whenever --update-crontab && cron; then
+  log "cron no ar (jobs do config/schedule.rb, no fuso ${TZ:-?})"
+else
+  log "AVISO: cron/crontab indisponível (rode com --build) — seguindo sem agendamento"
+fi
+
+# ── 6. Puma ──────────────────────────────────────────────────────────────────
+log "subindo o Rails"
+exec bundle exec rails s -b 0.0.0.0