ci: avisar quando a release ficar para trás

[janeiaraujo]

Por que

É a terceira vez que vários PRs entram na main sem bump e a release fica
para trás — a última vez com uma correção de segurança dentro (fast-uri, #35),
que ficou sem tag. Bumpar à mão de novo (#48) conserta o sintoma; isto aqui é o
que impede a quarta.

Duas guardas, nenhuma bloqueante

No PR (ci.yml, job novo): se o PR mexe em backend/src/ ou
frontend/src/ e mantém a versão, o CI emite um ::warning:: e escreve no
resumo do job.

Não é erro de propósito. PR de documentação, teste ou CI não precisa de
release, e falhar nesses casos ensinaria a ignorar o aviso — que é justamente
como uma guarda deixa de funcionar. Agrupar vários PRs numa release só continua
sendo válido; o aviso só garante que a decisão seja consciente.

Na main (release-drift.yml, novo): a cada push, compara a main com a
última tag. Havendo mudança de produção sem tag, abre (ou atualiza) uma issue
listando o que entrou e como fechar. Quando a release sai, ela se fecha
sozinha com um comentário.

Esta é a que teria pego os três casos: o problema nunca foi um PR isolado, foi
a sequência deles.

Um detalhe que importa

O filtro inclui os lockfiles, não só src/. É por eles que uma correção de
segurança transitiva chega — e foi exatamente o caso que passou despercebido:
o fast-uri não toca em src nenhum e mesmo assim precisava ser publicado.

Rodando a lógica contra o estado real de hoje:

$ git log --oneline v2.4.0..origin/main -- backend/src frontend/src \
    backend/package-lock.json frontend/package-lock.json | wc -l
5

Cinco commits de produção sem tag — que é precisamente a situação que o #48
está corrigindo.

O que estas guardas não fazem

Não bumpam versão sozinhas. Se é patch, minor ou major continua sendo decisão
de quem abre o PR — automatizar isso exigiria confiar cegamente no prefixo do
commit, e um fix: que quebra contrato viraria patch silenciosamente.

Verificação

• os dois YAML validados como YAML
• lógica de detecção simulada contra o histórico real: acusa 5 commits desde a
  v2.4.0, e a lista bate com os PRs que ficaram sem release
• READMEs (pt e en) atualizados na seção de Versionamento

[Copilot]

Pull request overview

Este PR adiciona duas “guardas” no GitHub Actions para reduzir o risco de a branch main ficar à frente da última release/tag sem ninguém perceber, mantendo o time consciente quando há mudanças de produção sem bump de versão.

Changes:

• Adiciona um novo job no CI para emitir ::warning:: quando PRs alterarem código de produto sem bump de versão.
• Cria um workflow (release-drift.yml) que, a cada push na main, compara main com a última tag e abre/atualiza uma issue enquanto houver “drift”.
• Atualiza os READMEs (pt/en) explicando as novas guardas no fluxo de versionamento.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/ci.yml	Novo job de aviso (não-bloqueante) para PRs que mudam produto sem bump de versão.
.github/workflows/release-drift.yml	Novo workflow para detectar drift entre main e a última tag e manter uma issue de lembrete.
README.md	Documenta as duas guardas no processo de versionamento.
README.en.md	Documenta as duas guardas no processo de versionamento (EN).

Suppressed comments (1)

.github/workflows/ci.yml:66

• O resumo do job menciona apenas mudanças em backend/src//frontend/src/, mas a própria descrição do PR diz que lockfiles também contam como mudança de produção. Se você passar a checar lockfiles, atualize esta linha para não induzir quem lê o summary a ignorar esse caso.

            echo "Este PR mexe em \`backend/src/\` ou \`frontend/src/\` e mantem a versao em **$VERSAO_PR**."

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.