[pibahamondesw]

Description

Contexto. El release automático (#138) publica en PyPI y recién después, en release/finalize, empuja el commit de versión y el tag. Si alguien mergea a master mientras corre el release, ese push se rechaza con el paquete ya publicado, sin tag ni GitHub Release. fintoc-com/release-action#3 agregó push: 'true' a prepare para empujar antes de publicar. Issue: DX-3387.

¿Qué hay de nuevo?

• release/prepare corre con push: 'true': empuja el commit de versión y el tag a master en un push atómico y sin force, antes de poetry build y de publicar.
  • Si master se movió durante el release, el push se rechaza y no se publica nada.
  • release/finalize ve el tag en el remote, se salta el push y solo crea el GitHub Release.
• El chequeo de commits posteriores al PR solo deja pasar commits release: cuyo autor es fin-releases[bot]. Antes bastaba el prefijo del mensaje, así que un PR humano titulado release: ... se colaba. Es el mismo filtro de [DX-3327] Release automático de la CLI al mergear PRs con label release:* fintoc-cli#62.
• RELEASING.md documenta el nuevo orden y sus modos de falla en la tabla Si falla.

Tests

• actionlint sobre release.yml: 8 hallazgos, los mismos que en origin/master (actions @v3, label de Blacksmith, el typo steps.poetry-cache, $HOME sin comillas). La línea nueva no agrega ninguno.
• El filtro nuevo de compare, probado contra la historia real del repo: 31abd1b...d170905 lista 88c1ef6 d170905 y omite d54ea49 (release: v2.29.0 de fin-releases[bot]); un rango con solo el commit de versión y el mismo SHA no listan nada. Todos los commits release: recientes los autorea fin-releases[bot].
• shellcheck .github/scripts/*.sh sin hallazgos.
• .github/scripts/resolve-release.test.sh pasa (incluye "push sin PR mergeado se salta", que cubre el run del commit de versión).

Release notes

Requirements

None.

Additional changes

None.

Consideraciones

• El checkout del job release ya es por nombre de rama (ref: master), así que HEAD no queda detached y el push de prepare funciona sin más cambios.
• El chequeo de "commits posteriores al PR" queda igual: detecta lo que se mergeó antes de que arrancara el job. El push sin force de prepare cubre lo que se mergea durante el job.
• El commit de versión, ahora empujado antes de publicar, sigue disparando un run de release que no hace nada: no tiene PR mergeado asociado, así que resolve deja bump vacío y el job release queda skipped.
• Cambio de trade-off: las notas de respaldo (generate-notes), poetry build y la publicación en PyPI ahora corren después del push. Si fallan, el tag queda en master sin paquete en PyPI. El recovery (publicar desde el tag o saltarse la versión) está en RELEASING.md. Se acepta porque es menos dañino que un paquete publicado sin tag, y porque generate-notes ya funciona con el tag existente en el remote.
• Re-correr el job después de que el push entró publica la versión siguiente, no la que falló. Quedó escrito en RELEASING.md.
• Este PR no lleva label release:*, así que al mergearlo no publica.

¿Es seguro hacer rollback? Sí
¿Cuáles son los pasos para hacer rollback? Revert PR

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[fin-review]

LGTM ✅