Holix release (hacer release)

Holix release («hacer release»)

Cuando el usuario dice hacer release (o equivalente), ejecuta este pipeline completo de principio a fin. No te detengas después del PR. No evites el CI. No hagas tag antes del merge.

Reglas canónicas del paquete: RULES.md §8. Este skill es el bucle operativo.

Precondiciones

• Repo: javded-itres/Holix. Rama predeterminada: main.
• Autenticación: gh auth status debe estar logueado.
• Hacer fetch primero: git fetch origin --tags.
• Versión siguiente = último release de GitHub + patch (1.0.7 → 1.0.8), a menos que el usuario haya solicitado minor/major.
• Confirmar que las versiones coincidan antes de etiquetar:
  • pyproject.toml [project].version
  • cli/__init__.py __version__
  • último gh release list / git tag
• No hacer rsync/scp/hotfix en producción. Etiquetar en main es suficiente: GHA GitHub Release + Publish to PyPI se ejecutan desde vX.Y.Z.
• Ejecutar ./scripts/lint.sh (o --fix) antes de cada push.

1) PR con los cambios

Incluir código + incremento de versión + changelog en el mismo PR para que haya un solo merge y luego un tag.

1. Si ya hay un PR abierto que cubre este trabajo, reutilízalo y agrega el incremento allí si falta.
2. En caso contrario, crear rama desde origin/main actualizada: release/X.Y.Z (ejemplo: release/1.0.8).
3. Hacer commit del trabajo no confirmado/no fusionado del usuario (sin secretos, sin node_modules/, sin .env local).
4. Incrementar versión con scripts/versioning.py (o editar ambos archivos):
   • pyproject.toml
   • cli/__init__.py
5. Actualizar docs/CHANGELOG.md:
   • Mover las notas de ## Sin publicar a ## X.Y.Z — YYYY-MM-DD
   • Dejar un nuevo ## Sin publicar vacío
   • Escribir Añadido/Corregido/Pruebas basado en el diff real
6. Hacer push y abrir PR → main:

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

## Lista de verificación
- [ ] La versión coincide en pyproject.toml y cli/__init__.py
- [ ] docs/CHANGELOG.md tiene la sección X.Y.Z
- [ ] CI verde (ruff + pytest matrix)

Después del merge: etiquetar `vX.Y.Z` (crea GitHub Release + PyPI).
EOF
)"

2) Pruebas de GitHub hasta que estén en verde

Vigilar GitHub Actions en el PR, no solo pytest local.

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

En caso de fallo:

1. gh run view <id> --log-failed (o logs del job).
2. Corregir el código / pruebas / ruff.
3. Local: ./scripts/lint.sh luego pytest dirigido.
4. Hacer commit, push, volver a vigilar.

Repetir hasta que todas las comprobaciones requeridas estén en verde. No fusionar CI rojo. Si un fallo necesita una decisión de producto, detenerse y preguntar — no lo tapes.

3) Fusionar en main

El usuario ya autorizó la fusión como parte de este comando.

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

Usar --squash solo si el usuario lo pidió. Esperar hasta que el PR esté FUSIONADO. Luego git checkout main && git pull origin main.

Verificar que main ahora tiene la versión X.Y.Z.

4) Siguiente release numerado de GitHub

El tag debe coincidir con pyproject.toml. No crear un release de GitHub manualmente si el workflow de tags puede hacerlo.

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

Vigilar:

• 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

Si el workflow de tags falla porque CHANGELOG no tiene la sección ## X.Y.Z, corregir en un PR posterior, eliminar/volver a hacer push del tag solo con --force-with-lease después de decirlo. Preferir un nuevo patch sobre reescribir un tag publicado.

Reportar

Cuando termine, responder con:

• URL del PR y SHA del merge
• Versión X.Y.Z / tag vX.Y.Z
• URL del release
• Estado de CI y workflow de PyPI