From 53b2b3c95e7a9a99277a684d3725f4cecc187103 Mon Sep 17 00:00:00 2001 From: BertMarti <107127310+BertMarti@users.noreply.github.com> Date: Thu, 5 Nov 2026 13:10:15 +0100 Subject: [PATCH] docs: lo que es cierto tras publicar la v1.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fuera los avisos «la 1.2.0 aún no está publicada» (README, docs/USO.md y la sección «Binarios verificables» de la web), ejemplos de versión exacta @v1.2.0 y release/checksums.txt fuera de main (va en la etiqueta v1.2.0; la plantilla embebida cambia y @main vuelve a compilar con Go). Se fusiona después de publicar la v1.2.0 y mover v1. Hecho por Claude. Co-Authored-By: Claude Opus 5.5 --- CHANGELOG.md | 5 +++++ README.md | 4 +--- SECURITY.md | 2 +- docs/DESARROLLO.md | 2 +- docs/USO.md | 6 +++--- internal/gallery/index.html.tmpl | 1 - internal/gallery/page_test.go | 2 +- release/checksums.txt | 6 ------ 8 files changed, 12 insertions(+), 16 deletions(-) delete mode 100644 release/checksums.txt diff --git a/CHANGELOG.md b/CHANGELOG.md index dfb9e1f..452bbfc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,11 @@ El formato sigue [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/) y e ## [Sin publicar] +### Cambiado + +- Con la v1.2.0 publicada y `v1` apuntando a ella, el README, la guía de uso y la web dejan de avisar de que las atestaciones llegan con una versión aún sin publicar, y los ejemplos de versión exacta pasan a `@v1.2.0`. +- `release/checksums.txt` sale de `main`: describe los binarios de la v1.2.0 ya publicada (va en su etiqueta) y no los de `main`, que ha cambiado. La próxima versión lo vuelve a generar en su commit. + ## [1.2.0] - 2026-11-02 Binarios que se pueden verificar y una galería más fácil de recorrer. **La interfaz de `action.yml` no cambia** (mismas entradas, misma salida `path`, mismos archivos) y todas las tarjetas SVG son byte a byte las de la v1.1.0: con `@v1` no hay que hacer nada. diff --git a/README.md b/README.md index 1a3a117..c1b61aa 100644 --- a/README.md +++ b/README.md @@ -271,13 +271,11 @@ gh attestation verify commitling_1.2.0_linux_amd64 --repo BertMarti/commitling ``` Si dice «Verification succeeded», el archivo no ha cambiado ni un byte desde que lo compiló y firmó un workflow de `BertMarti/commitling`. Para exigir además que fuera el workflow «Release» (el que publica los binarios), añade `--signer-workflow BertMarti/commitling/.github/workflows/release.yml`. Hace falta `gh` 2.49 o posterior. - -> La 1.2.0 aún no está publicada: hasta entonces, las releases no tienen atestación.
¿Qué versión uso? -Usa `BertMarti/commitling@v1` para recibir mejoras compatibles. Si quieres fijar una versión concreta, usa una etiqueta exacta (por ejemplo `@v1.1.0`) o el SHA de un commit. Evita `@main`: es la rama de desarrollo. +Usa `BertMarti/commitling@v1` para recibir mejoras compatibles. Si quieres fijar una versión concreta, usa una etiqueta exacta (por ejemplo `@v1.2.0`) o el SHA de un commit. Evita `@main`: es la rama de desarrollo.
## Lo que tienes que hacer tú (mantenedor) diff --git a/SECURITY.md b/SECURITY.md index 73756aa..aff9e71 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -23,6 +23,6 @@ Respondo en cuanto pueda (proyecto personal, sin plazos garantizados). ## Buenas prácticas para quien usa la Action -- Fíjala a `@v1`, a una versión exacta (por ejemplo `@v1.1.0`) o a un SHA, nunca a `@main`. +- Fíjala a `@v1`, a una versión exacta (por ejemplo `@v1.2.0`) o a un SHA, nunca a `@main`. - Da a tu workflow solo `permissions: contents: write` (lo necesita para guardar el SVG) y nada más. - No hace falta ningún token personal: basta el `GITHUB_TOKEN` del propio workflow. diff --git a/docs/DESARROLLO.md b/docs/DESARROLLO.md index fd9e63b..bf31043 100644 --- a/docs/DESARROLLO.md +++ b/docs/DESARROLLO.md @@ -105,7 +105,7 @@ La entrada de la Action `keep-on-error` está activa por defecto. Si la caída e ## Versiones y GitHub Marketplace - `BertMarti/commitling@v1` sigue la versión mayor 1: la etiqueta móvil `v1` apunta a la última versión compatible y la mueve Alberto al publicar. -- Una etiqueta exacta (`@v1.1.0`) o el SHA de un commit es lo más reproducible. +- Una etiqueta exacta (`@v1.2.0`) o el SHA de un commit es lo más reproducible. - `@main` funciona, pero es la rama de desarrollo; los ejemplos nunca la usan (`TestExamplesUseV1`). - La Action declara nombre, descripción y `branding` (icono `feather`, color `green`) en `action.yml`, que es lo que muestra el Marketplace. **La interfaz de `action.yml` (entradas, salida `path`, archivos y formato del SVG) no se rompe**: hay perfiles que la usan a diario. diff --git a/docs/USO.md b/docs/USO.md index 8e3d0bd..f6075c2 100644 --- a/docs/USO.md +++ b/docs/USO.md @@ -113,7 +113,7 @@ Qué hace este archivo, en cristiano: - `schedule` / `cron`: lo ejecuta solo cada día a las 05:23 UTC (07:23 en el horario de verano de la España peninsular, 06:23 en invierno). GitHub puede retrasar unos minutos las ejecuciones programadas. - `workflow_dispatch`: añade el botón **Run workflow** para lanzarlo a mano. - `permissions: contents: write`: le permite guardar la imagen en tu repositorio. Sin esto fallaría al guardar. -- `BertMarti/commitling@v1`: es la Action de commitling, que crea el archivo `commitling.svg`. `@v1` significa «la versión 1»: recibes las mejoras compatibles sin tocar nada. Si prefieres fijar una versión exacta, usa una etiqueta exacta de las [releases](https://github.com/BertMarti/commitling/releases), por ejemplo `@v1.1.0`. +- `BertMarti/commitling@v1`: es la Action de commitling, que crea el archivo `commitling.svg`. `@v1` significa «la versión 1»: recibes las mejoras compatibles sin tocar nada. Si prefieres fijar una versión exacta, usa una etiqueta exacta de las [releases](https://github.com/BertMarti/commitling/releases), por ejemplo `@v1.2.0`. - El último paso guarda `commitling.svg` en tu repositorio solo si ha cambiado, con un commit «chore: actualiza commitling». ### Paso 3. Añade la imagen a tu README @@ -328,7 +328,7 @@ En el workflow, la línea `uses: BertMarti/commitling@...` decide qué versión | Escribes | Qué significa | Cuándo usarla | |---|---|---| | `@v1` | La versión mayor 1: la etiqueta `v1` se mueve con cada versión 1.x compatible, así que recibes mejoras y correcciones sin tocar nada | Lo recomendado | -| `@v1.1.0` (o la última de las releases) | Una versión exacta, que nunca cambia | Si quieres controlar tú cuándo actualizas | +| `@v1.2.0` (o la última de las releases) | Una versión exacta, que nunca cambia | Si quieres controlar tú cuándo actualizas | | `@` (huella de un commit) | Una copia exacta del código, la opción más reproducible | Si te importa la máxima seguridad | | `@main` | La rama de desarrollo, que puede cambiar en cualquier momento (y romper tu workflow) | Solo para probar cambios | @@ -362,7 +362,7 @@ gh attestation verify commitling_1.2.0_linux_amd64 --repo BertMarti/commitling - Hace falta `gh` 2.49 o posterior (`gh --version`); las versiones anteriores no tienen `gh attestation`. -> La 1.2.0 aún no está publicada: hasta entonces, las releases (1.1.0 y anteriores) no tienen atestación. +Las releases anteriores a la 1.2.0 no tienen atestación (la Action las verifica igual, con la huella SHA-256). ## 7. Desde la línea de órdenes y la imagen de vista previa diff --git a/internal/gallery/index.html.tmpl b/internal/gallery/index.html.tmpl index cf97fc0..9a1b567 100644 --- a/internal/gallery/index.html.tmpl +++ b/internal/gallery/index.html.tmpl @@ -315,7 +315,6 @@

Binarios verificables

La Action usa un binario ya compilado de cada versión y, antes de ejecutarlo, comprueba su huella SHA-256 con la lista que viaja dentro de la propia Action: si no coincide, lo descarta y compila el código con Go. A partir de la 1.2.0, cada binario de las releases lleva además una atestación de procedencia firmada por GitHub que dice de qué commit y de qué workflow salió. Si te bajas uno a mano, compruébalo con la CLI de GitHub (con la sesión iniciada: gh auth login):

gh attestation verify commitling_{{.Version}}_linux_amd64 --repo BertMarti/commitling

-

La 1.2.0 aún no está publicada: hasta entonces, las releases no tienen atestación (la Action sigue verificando la huella como siempre).

Cambia el nombre del archivo por el que te hayas bajado (por ejemplo commitling_{{.Version}}_windows_amd64.exe). Si la orden dice «Verification succeeded», el archivo no ha cambiado ni un byte desde que lo compiló y firmó un workflow de este repositorio. Para exigir además que fuera el workflow «Release» (el que publica los binarios), añade --signer-workflow BertMarti/commitling/.github/workflows/release.yml. Hace falta gh 2.49 o posterior.

diff --git a/internal/gallery/page_test.go b/internal/gallery/page_test.go index 46159b7..2a5723f 100644 --- a/internal/gallery/page_test.go +++ b/internal/gallery/page_test.go @@ -64,7 +64,7 @@ func TestGalleryHasSpeciesFilter(t *testing.T) { func TestPageExplainsAttestations(t *testing.T) { page := buildPageWithVersion(t, "1.2.0-test") - for _, want := range []string{`id="verificar"`, `id="verificar-aviso"`, `gh attestation verify commitling_1.2.0-test_linux_amd64 --repo BertMarti/commitling`, `commitling_1.2.0-test_windows_amd64.exe`} { + for _, want := range []string{`id="verificar"`, `gh attestation verify commitling_1.2.0-test_linux_amd64 --repo BertMarti/commitling`, `commitling_1.2.0-test_windows_amd64.exe`} { if !strings.Contains(page, want) { t.Errorf("page lacks %q", want) } diff --git a/release/checksums.txt b/release/checksums.txt deleted file mode 100644 index fa79418..0000000 --- a/release/checksums.txt +++ /dev/null @@ -1,6 +0,0 @@ -ee2457ff105c71d34141581292f903ff1d9993149c38438564d204011df759f4 commitling_1.2.0_darwin_amd64 -ea69d8ea86e501f03b4890184e9300a48fb60078c857502a683121b1120ebefd commitling_1.2.0_darwin_arm64 -aacfd29aa9cb2cfadd83333782f8d80c4470d96ac8de51d0424583ceeb2c03d2 commitling_1.2.0_linux_amd64 -837801a145e0f72853a0e66827fddf11915e13f6af1fec6d7227b733c4c8a51b commitling_1.2.0_linux_arm64 -aef00980879e20ca646d434cc0637935591f1b9cc647dcf2118a42ef3db3b891 commitling_1.2.0_windows_amd64.exe -eb6f505923c7bb9f045f68d7235806789dc1a106e3e367dedc3cce51fa88fdb0 commitling_1.2.0_windows_arm64.exe