Repository navigation
[ONB-4205] [Compose] [Compose] Agregar actualización de organizations - #137
Merged
Merged
Conversation
Co-authored-by: fin-compose[bot] <255610621+fin-compose[bot]@users.noreply.github.com>
Contributor
Author
|
fin review |
![fin-review[bot]](https://avatars.githubusercontent.com/u/62265373?s=60&v=4){kind=small}
FranciscaOtero
marked this pull request as ready for review
November 6, 2026 12:06
12 tasks done
pibahamondesw
added a commit
that referenced
this pull request
Nov 6, 2026
…:* (#138) ## Description **Contexto.** Hoy el SDK solo se publica disparando a mano el workflow `release` (`workflow_dispatch`). Queremos que los SDK se publiquen solos al mergear, sin darle a Compose `actions: write` para disparar el workflow. Se acordó que el release salga de GitHub Actions al mergear a la rama principal, con la misma convención en fintoc-ruby, fintoc-node y fintoc-cli. Issue: [DX-3325](https://linear.app/fintoc/issue/DX-3325/release-automatico-de-fintoc-python-al-mergear-prs-con-label-release). **¿Qué hay de nuevo?** - [x] `release` también corre en push a `master`. El `workflow_dispatch` queda igual, como respaldo manual. - [x] Un job `resolve` decide `bump` y notas: - En push busca el PR mergeado cuyo `merge_commit_sha` es el commit pusheado (`commits/{sha}/pulls`, con hasta 3 intentos cada 10 s si GitHub todavía no lo asocia). El bump sale de su label `release:patch|minor|major`. - Sin PR o sin label `release:*` no se publica: el job `release` queda *skipped*, no falla. Esto cubre también el commit de versión que empuja `prepare`, que no tiene PR. - Más de un label `release:*` (o uno desconocido) hace fallar el workflow con un mensaje claro. - Las notas son la sección `## Release notes` del body del PR, hasta el siguiente `## `, sin comentarios HTML. - [x] Si las notas quedan vacías, se usan las notas autogeneradas de GitHub (`releases/generate-notes` con el tag de `prepare`). Aplica también al `workflow_dispatch` sin notas. - [x] El job `release` tiene `concurrency: release` sin `cancel-in-progress`, para que nunca corran dos releases a la vez. Está a nivel de job para que los pushes sin release (que solo corren `resolve`) no ocupen el grupo ni desplacen un release pendiente. - [x] Los jobs corren en `blacksmith-2vcpu-ubuntu-2404`. PyPI se publica con `PYPI_API_TOKEN` y no con trusted publishing, así que `release` puede correr en Blacksmith. - [x] `release` parte de `master` y, en push, aborta antes de publicar si `master` tiene otros commits después del PR mergeado (ver Consideraciones). - [x] El PR template tiene una sección `## Release notes`, justo después de *Description*, que explica la convención. `RELEASING.md` documenta el flujo nuevo. **Tests** - [x] `.github/scripts/resolve-release.test.sh` (corre en CI, job `release-scripts` de `tests`) cubre: sección al final con comentarios, sección seguida de otra (con `\r\n`), solo comentario, sin sección, sin label, dos labels, label desconocido, PR no mergeado, `workflow_dispatch` con y sin notas. - [x] El script corrido contra el payload real de #137 (merge commit de Compose): sin label se salta, y con label y sección las notas se cortan antes del footer de Compose. - [x] La consulta de `compare` del chequeo, probada contra este repo: con el mismo SHA no lista nada, un commit `release: v2.29.0` posterior se ignora, y commits de otro PR se listan. - [x] `generate-notes` probado contra este repo con un tag inexistente y el SHA completo de `master`. - [x] `actionlint` y `shellcheck`: lo nuevo no tiene hallazgos. Solo quedan los que ya existían en `master` (actions `@v3`, el typo `steps.poetry-cache`, `$HOME` sin comillas), que no toqué. ## Release notes <!-- Sin release: cambio de CI. --> ## Requirements Ver *Consideraciones*: hay que crear los labels antes de mergear. ## Additional changes None. ## Consideraciones - **Antes de mergear:** crear los labels `release:patch`, `release:minor` y `release:major` en el repo. Sin ellos, los PRs nunca van a publicar. - El lado de Compose (poner el label y llenar `## Release notes` en sus PRs) lo ve Francisca. - El body y el título del PR son input no confiable: solo llegan a los scripts por `env:` o por archivo, nunca interpolados con `${{ }}` en un `run:`. `resolve` tiene permisos mínimos (`contents: read`, `pull-requests: read`). - `generate-notes` corre justo después de `prepare` y antes de publicar en PyPI, así que si falla no queda nada publicado. - Para el PR template uso `.github/pull_request_template.md`, que es el que GitHub usa por defecto. `PULL_REQUEST_TEMPLATE/release.md` solo se aplica con `?template=release.md` y es un template antiguo de descripción de versión, así que no lo toqué. El template está en inglés, así que la sección nueva también. - `## Release notes` va justo después de *Description* y no al final. Así la sección siguiente la cierra y no se cuela en las notas públicas lo que venga después, como el footer de Compose (`🤖🐙 Created with Compose · [View session](…)`). Compose sigue el orden del template, así que esto le sirve si mantiene ese orden. - **Releases encadenados (igual que fintoc-cli#62):** el job `release` hace checkout de `master` y no de `github.sha`. Así un release que quedó en cola parte del commit de versión del anterior y no calcula un tag que ya existe. A cambio, en push verifica antes de publicar que `master` no tenga commits posteriores a `github.sha` aparte de commits `release: ...`. Si los tiene, aborta sin publicar, para no sacar cambios de otro PR con el bump y las notas de este. El siguiente release los incluye, o se usa el dispatch si hace falta un bump mayor. - `concurrency` deja un solo run pendiente por grupo. Con tres merges con label seguidos, el del medio se cancela y su cambio sale en el siguiente release (o se rescata con el dispatch). - Riesgo que ya existía con el dispatch y ahora es más probable: si alguien mergea a `master` mientras corre el release, el push de `finalize` falla después de publicar en PyPI (el recovery está en `RELEASING.md`). La solución de raíz (rebase antes del push) va en `release-action`. - `resolve-release.sh` y su test son los mismos de fintoc-ruby (fintoc-com/fintoc-ruby#47), para mantener una sola implementación en los 4 SDKs. - 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
La API pública sumó
PATCH /v1/organizations/{id}, para que un partner corrija el email del fundador de una organización que refirió. El SDK solo exponíacreate.client.organizations.update(id, previous_founder_email=..., founder_email=...), que devuelve unOrganization. También funcionaorganization.update(...)sobre una instancia.update, y se saca que la creación exige JWS y es sololive(ahora no pide firma y entestdevuelve una organización ficticia).Fuente: fintoc-com/fintoc-rails#20103, fintoc-com/fintoc-rails#20327 y fintoc-com/fintoc-rails#20044.
POST /v1/organizationsya estaba en el SDK (fintoc-com/fintoc-rails#19988, #20074).Quedó fuera (ya calza, el SDK acepta campos y valores nuevos de forma dinámica):
spliten requests de payment intents v1/v2, invoices v2 y subscriptions v2, ysplit/split_applieden sus respuestas (fintoc-com/fintoc-rails#19791, #20011, #20107, #20108, #20177, #19997).inconsistenty camporeasonen invoices y subscriptions v2 (fintoc-com/fintoc-rails#19896, #19906).invoice.finalization_failed(fintoc-com/fintoc-rails#19922).payment_method_typeydocumentation_upload_deadlinenullable en disputes (fintoc-com/fintoc-rails#18922).tax_id.typecustomen customers (fintoc-com/fintoc-rails#19834).max_completed_sessionsen payment links (fintoc-com/fintoc-rails#19886).error_reasonen payment methodsmx_direct_debit(fintoc-com/fintoc-rails#20009, #19971).holder_nameen Chile (fintoc-com/pacioli#4063).PATCH /v1/organizations/{id}aceptaIdempotency-Key, pero el SDK solo la manda enPOST. Es opcional, así que no lo toqué acá.Requirements
None.
Additional changes
None.
🤖🐙 Created with Compose · View session