Files
DeskcommCRM/scripts/pr-mexe-no-piso-do-postgres.sh
PessoaandClaude Opus 5 a9ed944e79 ci: a major de piso do Postgres só roda quando o PR a alcança
Medido de 15 a 18/09/2026: as duas pernas do invariants-majors somam 1.658
min de runner por dia, e 55 dos 199 PRs recentes (28%) tocam schema, script
de banco, kit ou invariante. Nos outros 72% a perna do piso mede o mesmo que
a de cima, com outra versão de Postgres.

- invariants-alcance (job de segundos, sempre no GitHub) responde a matriz:
  ["15","17"] quando o PR alcança o piso e fora de pull_request, ["17"] no
  PR que não alcança. Falha ao listar, lista cortada ou resposta estranha →
  as duas.
- O agregador `invariants` exige o portão em `success`, a matriz em `success`
  (skipped nunca passa) e, fora de pull_request, piso=sim: a `main` mede as
  duas majors em toda árvore integrada.
- scripts/pr-mexe-no-piso-do-postgres.sh: aqui a lista é de quem ALCANÇA,
  porque a superfície do piso é pequena e nomeável (schema, quem o aplica,
  kit, invariantes, este workflow e o próprio script).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 17:33:48 -03:00

46 lines
2.1 KiB
Bash
Executable File
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
#!/usr/bin/env bash
# Lê caminhos (um por linha) na entrada e responde `sim` se ALGUM deles pode
# mudar o comportamento do banco na major de PISO (pg15); `nao` quando nenhum
# alcança. Entrada vazia responde `sim`: não saber o que mudou nunca pode virar
# "não precisa".
#
# Usado pelo ci.yml em pull_request, para escolher a matriz do
# `invariants-majors`. A major de CIMA (pg17) roda SEMPRE, em todo PR e na
# `main`; é ela que reprova invariante de RLS, de governança e de vocabulário
# banco × TypeScript, que não dependem da versão do Postgres.
#
# O piso existe por outra razão (issue #454): provar que o `baseline.sql` que o
# self-hoster aplica sobe na MENOR major que dizemos suportar. Isso só muda
# quando muda o schema, o script que o aplica ou o kit que o instala — e não
# quando muda código de produto. Medido em 18/09/2026: 55 dos 199 PRs recentes
# (28%) tocam essas superfícies, e os outros 72% pagavam uma segunda passada de
# ~8 min sem chance de reprovar por razão de major.
#
# Aqui a lista é de quem ALCANÇA (e não de quem não alcança, como nos scripts
# irmãos), porque a superfície do piso é pequena e nomeável: schema, os scripts
# que o aplicam, o kit e os próprios invariantes. Na `main` a pergunta nem é
# feita — lá as duas majors rodam sempre.
set -euo pipefail
algum=nao
while IFS= read -r caminho || [ -n "$caminho" ]; do
[ -z "$caminho" ] && continue
algum=sim
case "$caminho" in
# O schema, em qualquer forma: baseline, migrations, MANIFEST, config.
supabase/*) echo sim; exit 0 ;;
# Quem aplica o schema e quem mede o resultado.
scripts/test-db.sh | scripts/test-update-com-dados.sh) echo sim; exit 0 ;;
tests/invariants/*) echo sim; exit 0 ;;
# O kit do self-hoster aplica o baseline no install e no update.
hostgator-setup-kit/*) echo sim; exit 0 ;;
# O próprio workflow que decide isto.
.github/workflows/ci.yml) echo sim; exit 0 ;;
# E o script desta regra.
scripts/pr-mexe-no-piso-do-postgres.sh) echo sim; exit 0 ;;
esac
done
# Nenhuma linha lida: não sei o que mudou, então roda as duas.
if [ "$algum" = nao ]; then echo sim; else echo nao; fi