Holix — «Fazer Release» (javded-itres/Holix)

Holix — «Fazer Release»

Quando o usuário disser fazer release (ou equivalente), execute este pipeline do início ao fim. Não pare após o PR. Não pule a CI. Não crie a tag antes do merge.

Regras canônicas do pacote: RULES.md §8. Esta habilidade é o loop operacional.

Pré-condições

• Repo: javded-itres/Holix. Branch padrão: main.
• Autenticação: gh auth status deve estar logado.
• Buscar primeiro: git fetch origin --tags.
• Próxima versão = última release do GitHub + patch (1.0.7 → 1.0.8), a menos que o usuário tenha solicitado minor/major.
• Confirmar que as versões concordam antes de criar a tag:
  • pyproject.toml [project].version
  • cli/__init__.py __version__
  • última gh release list / git tag
• Não use rsync/scp/hotfix em produção. Criar a tag em main é suficiente: GHA GitHub Release + Publish to PyPI executam a partir de vX.Y.Z.
• Execute ./scripts/lint.sh (ou --fix) antes de cada push.

1) PR com as alterações

Inclua código + incremento de versão + changelog no mesmo PR para haver apenas um merge e, em seguida, uma tag.

1. Se um PR aberto já cobre este trabalho, reutilize-o e adicione o incremento lá se estiver faltando.
2. Caso contrário, crie uma branch a partir de origin/main atualizada: release/X.Y.Z (exemplo: release/1.0.8).
3. Faça commit do trabalho não commitado/não mergeado do usuário (sem secrets, sem node_modules/, sem .env local).
4. Incremente a versão com scripts/versioning.py (ou edite ambos os arquivos):
   • pyproject.toml
   • cli/__init__.py
5. Atualize docs/CHANGELOG.md:
   • Mova as notas de ## Unreleased para ## X.Y.Z — YYYY-MM-DD
   • Deixe um ## Unreleased vazio
   • Escreva Adicionado/Corrigido/Testes a partir do diff real
6. Faça push e abra o PR → main:

gh pr create --base main --title "Holix X.Y.Z" --body "$(cat <<'EOF'
## Resumo
Release Holix X.Y.Z.

## Checklist
- [ ] Versão coincide em pyproject.toml e cli/__init__.py
- [ ] docs/CHANGELOG.md tem a seção X.Y.Z
- [ ] CI verde (ruff + matriz pytest)

Após o merge: tag `vX.Y.Z` (cria GitHub Release + PyPI).
EOF
)"

2) Testes do GitHub até ficarem verdes

Acompanhe o GitHub Actions no PR, não apenas o pytest local.

gh pr checks <n> --watch
# ou
gh run watch <run-id>

Em caso de falha:

1. gh run view <id> --log-failed (ou logs do job).
2. Corrija o código / testes / ruff.
3. Localmente: ./scripts/lint.sh depois pytest direcionado.
4. Commit, push, re-watch.

Repita até que todas as verificações obrigatórias estejam verdes. Não faça merge com CI vermelha. Se uma falha exigir uma decisão de produto, pare e pergunte — não a esconda.

3) Merge em main

O usuário já autorizou o merge como parte deste comando.

gh pr merge <n> --merge --delete-branch

Use --squash apenas se o usuário pediu. Aguarde até que o PR esteja MERGED. Depois git checkout main && git pull origin main.

Verifique se main agora tem a versão X.Y.Z.

4) Próxima release numerada do GitHub

A tag deve coincidir com pyproject.toml. Não crie uma release do GitHub manualmente se o workflow de tag pode fazê-lo.

git checkout main
git pull origin main
python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])"
git tag vX.Y.Z
git push origin vX.Y.Z

Acompanhe:

• GitHub Release → https://github.com/javded-itres/Holix/releases/tag/vX.Y.Z
• Publish to PyPI

gh run list --branch vX.Y.Z --limit 5
gh release view vX.Y.Z

Se o workflow de tag falhar porque o CHANGELOG não tem a seção ## X.Y.Z, corrija em um PR seguinte, delete/re-faça push da tag apenas com --force-with-lease após avisar. Prefira um novo patch a reescrever uma tag publicada.

Relatório final

Quando terminar, responda com:

• URL do PR e SHA do merge
• Versão X.Y.Z / tag vX.Y.Z
• URL da Release
• Status do CI e do workflow do PyPI