Merge pull request 'docs: cleanup pipeline steps' (#57) from docs/update-readme into main

Reviewed-on: #57

.gitea/workflows/bump-build-publish.yaml

@@ -13,20 +13,11 @@ jobs:
         with:
           fetch-depth: 10
 
-      - name: Configure git
-        run: |
-          git config --global user.name "gitea-actions"
-          git config --global user.email "actions@git.jonathanteran.dev"
-          git config --global --add safe.directory "$GITHUB_WORKSPACE"
-
       - name: Set up Python
         uses: actions/setup-python@v6
         with:
           python-version-file: ".python-version"
 
-      - name: Install uv
-        uses: astral-sh/setup-uv@v8.3.2
-
       - name: Install git-flow and bump version
         id: version
         run: |
@@ -42,8 +33,11 @@ jobs:
             echo "should_build=false" >> $GITHUB_OUTPUT
           fi
 
+      - name: Install uv
+        uses: astral-sh/setup-uv@v8.3.2
+
       - name: Build and publish
         if: steps.version.outputs.should_build == 'true'
         run: |
           uv build
-          uv publish --token="${{ secrets.PYPI_TOKEN }}"
+          uv publish --token="${{ secrets.PYPI_TOKEN }}"

README.md

@@ -67,7 +67,7 @@ más información):
 - `new`: Crea una nueva rama siguiendo CB.
 - `commit`: Crea un commit siguiendo CC.
 - `merge`: Mergea la rama actual a una de las ramas principales.
-- `tag`: Crea un tag sobre el ultimo merge siguiendo SemVer.
+- `tag`: Crea un tag sobre el ultimo merge siguiendo SemVer (ver [Tag](#tag)).
 - `release`: Prepara la rama actual para pasarse al siguiente entorno configurado.
 - `branch`: Lista las ramas del repositorio, agrupadas por entorno objetivo.
 
@@ -91,6 +91,27 @@ El workflow para el cual se penso la herramienta es el siguiente:
 En cualquier momento se puede usar `git-flow branch` para ver en qué entorno está cada rama, y cuáles
 están todavía en progreso (`wip/`) o descartadas (`trash/`).
 
+### Tag
+
+`git-flow tag [--target=<RAMA>] [--token=<TOKEN>] [--update-changelog]`
+
+- `--target`: rama principal sobre la que se taggea. Por defecto, la rama actual. Debe ser una de las
+  ramas principales configuradas.
+- `--token`: Access Token del remoto. Si se pasa, se asume que corre en un pipeline: los commits y el
+  último tag se obtienen por API del remoto y el tag se crea en el remoto (y también localmente). Si
+  no, se usa `.repository-token` y todo se resuelve localmente.
+- `--update-changelog`: genera la entrada correspondiente en `CHANGELOG.md` y la commitea antes de
+  taggear (en un pipeline, además hace push del commit).
+
+Comportamiento:
+
+- El tag se crea sobre el último merge (first-parent) de la rama. Si ese merge ya tiene un tag, no se
+  hace nada.
+- La versión se calcula a partir de los tipos de commit (CC) del último merge. Si ningún commit
+  implica un salto de versión, se avisa y el comando termina con código de salida 1.
+- Con más de un entorno configurado, cada rama versiona por separado con el nombre del entorno como
+  sufijo (por ejemplo, `v1.2.0-prod`). Con un solo entorno no se agrega sufijo.
+
 ## Remotos soportados
 
 Cada remoto necesita un Access Token con permisos para crear Pull/Merge Requests y tags. El token se