Skip to content

releasing.md

Latest commit

 

History

History
84 lines (68 loc) · 5.11 KB

releasing.md

File metadata and controls

84 lines (68 loc) · 5.11 KB
Raw

Publicación de versiones

La publicación en npm está automatizada con Changesets y GitHub Actions. En el flujo normal nadie publica desde su máquina; hacerlo a mano queda sólo para la recuperación descrita más abajo.

Flujo normal

  1. Trabaja en una rama y abre un PR.

  2. Antes de pedir revisión, declara el cambio de versión:

    yarn changeset

Elige patch, minor o major y escribe el resumen en español (ese texto acaba tal cual en el CHANGELOG.md). Se crea un archivo en .changeset/; commitéalo junto con tu código.

  1. Mergea el PR a main.
  2. El workflow Release corre CI y, si hay changesets pendientes, abre o actualiza un PR llamado chore: version packages. Ese PR sube la versión en package.json y escribe el CHANGELOG.md. No lo edites a mano.
  3. Cuando quieras liberar, mergea el PR chore: version packages. Ese merge dispara la publicación: npm publish con provenance, tag de git y GitHub Release.

Varios PRs mergeados antes del paso 5 se acumulan en el mismo PR de versión y salen en una sola release.

Merges sin changeset

Un PR sin archivo en .changeset/ no publica nada y no abre PR de versión. Es el caso esperado para docs, tests o cambios de CI.

Requisitos de configuración

  • Secret NPM_TOKEN: token de npm con permiso de escritura sobre @insoutt/datafast-react (granular o automation; un token clásico con 2FA obligatorio falla con EOTP).
  • Ajuste del repositorio: Settings → Actions → General → Allow GitHub Actions to create and approve pull requests debe estar activado, si no el PR de versión no se puede crear.
  • Provenance requiere que el repositorio siga siendo público y que el job release mantenga id-token: write; si el repositorio pasa a privado, la publicación falla.

Detalles que sorprenden

  • El PR chore: version packages lo crea GITHUB_TOKEN, y GitHub no dispara workflows sobre PRs creados por ese token. Por eso ese PR aparece sin checks: la validación real ocurre al mergearlo, porque Release ejecuta CI antes de publicar.

  • .changeset/config.json tiene commit: false: yarn changeset ya no commitea solo, lo haces tú.

  • No mergees otros PRs mientras el merge de chore: version packages está publicando. GitHub guarda una sola ejecución pendiente por grupo de concurrencia, así que un tercer merge expulsa de la cola a la que iba a publicar y esa publicación nunca llega a correr. Cómo recuperar depende de si el merge que la expulsó traía changeset:

    • Sin changeset: relanza Release a mano desde la pestaña Actions (workflow_dispatch sobre main). Esa ejecución no ve changesets pendientes, va directa a publicar y recupera la versión saltada.
    • Con changeset: relanzar no arregla nada. La ejecución manual ve los changesets pendientes, vuelve a la rama de versionado y abre otro PR chore: version packages que sube la versión otra vez. La versión saltada conserva su sección en el CHANGELOG.md pero se queda sin publicar en npm, sin tag y sin Release. Dos salidas: publicarla a mano desde el commit de su merge (git checkout <sha> && yarn release, que publica sin provenance; después crea el tag y la Release desde la UI), o darla por perdida y mergear el nuevo PR de versión, que publica el siguiente número.

    Un merge queue en main cierra esta ventana del todo.

Si falla

Síntoma Causa Arreglo
EOTP al publicar Token clásico con 2FA Genera un token granular y gh secret set NPM_TOKEN
ENEEDAUTH Falta registry-url o el secret Revisa .github/workflows/release.yml
No aparece el PR de versión Falta el permiso de crear PRs Activa el ajuste de Actions descrito arriba
check-format falla tras versionar CHANGELOG sin formatear yarn version-packages ya corre Prettier; ejecútalo de nuevo
publicado en npm pero sin tag ni GitHub Release El re-run no lo repara: changeset publish omite la versión ya publicada Crear el tag a mano (git tag vX.Y.Z <sha> -m vX.Y.Z && git push origin vX.Y.Z) y publicar la Release desde la UI