[pibahamondesw]

Description

Hoy los SDK solo se publican corriendo a mano el workflow release (workflow_dispatch). Compose no puede dispararlo sin actions: write, permiso que no le damos a propósito. Con este cambio el release corre solo al mergear a master un PR con label release:*. Es el mismo diseño que va en fintoc-ruby, fintoc-python y fintoc-cli; resolve-release.sh y sus tests son los mismos de fintoc-com/fintoc-ruby#47 (DX-3326).

• release también corre en push a master. El workflow_dispatch queda igual, como respaldo manual.
• Un job resolve decide el bump y las notas:
  • Manual: usa los inputs, como hoy.
  • Push: busca el PR mergeado del commit (3 intentos cada 10 s, por si GitHub tarda en asociarlo). El bump sale de su label release:patch|minor|major.
  • Si no hay PR o no hay label, no se publica: el job release queda skipped, no falla. Esto también cubre el commit de versión que empuja prepare.
  • Si hay más de un label release:* o un label desconocido, falla con un mensaje claro.
  • Las notas salen de la sección ## Release notes del PR, sin comentarios HTML.
• Si las notas quedan vacías (en push o en manual), se usan las notas autogeneradas de GitHub (releases/generate-notes).
• El job release tiene concurrency (sin cancel-in-progress), así que nunca hay dos releases en paralelo.
• prepare usa push: 'true' ([DX-3359] Empujar commit y tag de forma atómica antes de publicar en release-action release-action#3): empuja el commit de versión y el tag a master de forma atómica antes de npm publish, y finalize solo crea el GitHub Release. Si master avanzó, el release falla sin publicar nada.
• Releases encadenados (igual que [DX-3327] Release automático de la CLI al mergear PRs con label release:* fintoc-cli#62): el job release hace checkout de master y no de github.sha. En push, si master tiene commits posteriores al PR mergeado (aparte de los release: ... de fin-releases[bot]), falla antes de publicar. Así no salen los cambios de otro PR con el bump y las notas de este; esos cambios van en el siguiente release, o por el manual si necesitan un bump mayor.
• El job resolve corre en Blacksmith (blacksmith-2vcpu-ubuntu-2404). El job release sigue en ubuntu-24.04 (ver Consideraciones).
• El PR template incluye la sección ## Release notes.

Tests:

• .github/scripts/resolve-release.test.sh corre en CI (workflow release-scripts, solo cuando cambian los scripts) y cubre: notas al final, notas seguidas de otra sección, solo un comentario, sin sección, sin label, dos labels, label desconocido, PR no mergeado, y dispatch con y sin notas.
• Local, contra commits reales: el merge de [ONB-4206] [Compose] [Compose] Agrega actualización de organizaciones (PATCH /v1/organizations/{id}) #113 (sin label) y release: v1.31.0 (sin PR) se saltan.
• actionlint y shellcheck sin errores (salvo el label de Blacksmith, que actionlint no conoce).

Release notes

Requirements

Antes de mergear, crear en el repo los labels release:patch, release:minor y release:major.

Additional changes

RELEASING.md y AGENTS.md documentan el release automático y qué pasa con merges encadenados.

Consideraciones

• Pre-merge: crear los labels release:patch, release:minor y release:major.
• El job release no se movió a Blacksmith: npm solo acepta trusted publishing (OIDC y provenance) desde runners cloud de GitHub, y Blacksmith cuenta como self-hosted, así que npm publish fallaría con E422 (docs de npm). El job resolve sí corre en Blacksmith.
• La convención del lado de Compose (poner el label y escribir las notas) la ve Francisca.
• La concurrency va en el job release y no en el workflow, porque GitHub cancela los runs pendientes del grupo aunque cancel-in-progress sea false. Si fuera a nivel de workflow, un run que no publica (el commit de versión o un PR sin label) podría cancelar un release encolado. Igual, si se encolan dos releases detrás de uno en curso, GitHub deja solo el más reciente.
• Para el PR se usa el de merge_commit_sha == github.sha y ya mergeado: commits/{sha}/pulls también devuelve PRs abiertos que contienen el commit.
• Las notas autogeneradas se piden antes de npm publish. Si esa llamada falla, no se publica nada.
• El chequeo de releases encadenados atrapa los merges que llegan antes de que parta el job release y falla con un mensaje claro. Si alguien mergea a master durante el release, el push atómico de prepare se rechaza antes de publicar. Ya no puede quedar un paquete publicado sin commit ni tag, ni un tag huérfano. Si algo falla después del push (las notas autogeneradas o npm publish), quedan commit y tag en master sin paquete; RELEASING.md explica cómo recuperarlo.
• Solo se actualizó .github/pull_request_template.md, que es el template por defecto. PULL_REQUEST_TEMPLATE/release.md solo aplica con ?template=release.md, y es el template antiguo de los PR de release manuales.

Rollback

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

[pibahamondesw]

fin review

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[pibahamondesw]

fin review

[fin-review]

LGTM ✅

[fin-review]

LGTM ✅