fix: keep release bump commits on protected main

[giscebot]

Summary

• Keep the semantic-release version bump commit on main so setup.py advances in repository history.
• Keep the version tag attached to that release commit, matching the existing v0.10.0 pattern and other GISCE release workflows.
• Use GH_PAT when configured, falling back to github.token, and document that protected main needs a controlled release bypass for this push.

Context

Issue #34 failed because python-semantic-release tried to push the release bump commit directly to protected main using the default GitHub Actions token.

The previous attempt in this PR avoided that by disabling release commits, but that changed the release model: the tag would point to the merge commit, while the setup.py bump would only exist inside the runner and published artifacts. That is not the desired model here.

The intended model is now explicit: semantic-release creates the release commit, pushes it to main, tags that commit, creates the GitHub Release, uploads the binary/Python distribution assets, and publishes to PyPI when a PyPI token is configured. Operationally, the repo must configure GH_PAT with permission or branch-protection bypass for the release push.

Validation

• python3 YAML parse of .github/workflows/release.yml -> OK
• /home/openclaw/.local/share/py-gisce-client/venv/bin/python -m pytest tests/ -v --tb=short -> 49 passed

Refs #34

[ecarreras]

@giscebot si però si no fa commit ni push no hi haurà ni tag ni release....

[giscebot]

Tens raó: deixar només commit: "false" feia mala pinta perquè no quedava explícit si encara hi hauria tag/release.

He actualitzat la PR amb el flux clar:

• no es crea ni es puja release commit a main
• sí es manté tag: "true", push: "true" i vcs_release: "true"
• el tag queda sobre el commit de merge que ha disparat el workflow
• README actualitzat perquè no digui que es crea un release commit

Validació feta:

• YAML parse OK
• tests locals: 49 passed
• smoke local amb python-semantic-release==10.5.3: --no-commit --tag --no-push --no-vcs-release estampa versió, genera dist/ i crea tag local sense release commit
• CI de PR fix: keep release bump commits on protected main #35 verd en Python 2 i Python 3

PR actualitzada: #35

[giscebot]

He fet una verificació extra sobre la font primària de python-semantic-release@v10.5.3:

• action.yml defineix explícitament els inputs commit, tag, push i vcs_release.
• src/gh_action/action.sh tradueix aquests inputs a semantic-release version --no-commit --tag --push --vcs-release.
• Al codi de version, amb commit=false, tag=true i push=true, el push no queda desactivat: el branch commit no es crea ni es puja, però el tag sí es pot empènyer i la release VCS queda habilitada.

Per tant, la PR queda amb el comportament que volíem: cap release commit a main, però tag + GitHub Release preservats. Checks de PR verds en Python 2 i Python 3.

[ecarreras]

@giscebot joder no entenc qui pujarà el tag i farà el commit de la release???

[giscebot]

No hi ha ningú que faci el commit de release: aquesta PR precisament l'elimina.

El flux queda així:

1. Es mergeja un commit normal a main.
2. El workflow de GitHub Actions arrenca sobre aquest SHA de main.
3. python-semantic-release corre dins el runner amb:
   semantic-release version --no-commit --tag --push --vcs-release
4. Això estampa la versió només al checkout temporal del runner per construir dist/*.
5. El mateix job, amb GITHUB_TOKEN i contents: write, crea i puja el tag vX.Y.Z apuntant al commit de merge de main i crea la GitHub Release.
6. Després publish-action puja els assets a aquesta release.

Per tant:

• Qui puja el tag? El job de GitHub Actions, via python-semantic-release, amb GITHUB_TOKEN.
• Qui fa el commit de release? Ningú. No existeix commit chore(release): X.Y.Z a main.
• On queda el bump de setup.py? Només dins el runner i dins l'sdist/publicació d'aquella release, no com a commit al repo.

Si volem que setup.py quedi versionat a main, llavors aquesta solució no serveix sola: caldria canviar d'estratègia i fer que el bot obri una PR de bump de versió, o bé permetre explícitament un bypass controlat. Jo mantindria aquesta PR tal com està si acceptem tags com a font de veritat de releases; és la via més compatible amb protected branch.

[ecarreras]

@giscebot hi ha alguna cosa que em perdo... la idea és que es fa la versió del projecte, el tag, la release de github on es puja el binari i es puja el paquet a pypi?? com queda tot això no ho veig clar

[giscebot]

Sí: la idea completa queda així, amb el matís important que no hi ha commit de release a main.

El flux real després de merge és:

1. Es mergeja una PR normal a main.
2. El workflow Release arrenca sobre aquell SHA.
3. python-semantic-release calcula la versió nova, estampa setup.py només dins el checkout temporal del runner i construeix dist/*.
4. El mateix workflow, amb GITHUB_TOKEN, puja el tag vX.Y.Z i crea la GitHub Release.
5. Es construeix el binari pygisceclient-linux-x86_64 i el checksum.
6. publish-action puja a la GitHub Release tant dist/* com release-assets/*.
7. El pas final fa twine upload dist/* a PyPI si hi ha PYPI_TOKEN o PYPI_MASTER_TOKEN; si no hi ha token, ho salta explícitament.

Per tant:

• versió del projecte: tag + artefactes publicats
• GitHub Release: sí
• binari a GitHub Release: sí
• paquet Python a PyPI: sí, si el secret de PyPI està configurat
• commit chore(release): ... a main: no

He afegit el commit d685f55 per deixar aquest flux escrit al README i he actualitzat el cos del PR. Checks del nou SHA verds: test-python2 i test-python3.

PR: #35

[ecarreras]

@giscebot doncs no ho entenc, si no es fa push amb el canvi de versió com carai anirem pujant de versió???? i el tag ha d'anar vinculat al commit del canvi de versió! Com carai està a altres projectes? Si s'ha de canviar la protecció de la branca ho fem...

[giscebot]

Tens raó. He revisat l'històric i altres repos GISCE, i la meva proposta anterior de commit: false canviava massa el model de release.

El criteri correcte per aquest repo és:

• el bump de setup.py ha de quedar en un commit de release a main
• el tag vX.Y.Z ha d'apuntar a aquest commit de release, com ja passa amb v0.10.0 (Bump to v0.10.0)
• GitHub Release, binari i PyPI surten d'aquest commit/tag

He actualitzat la PR amb el commit 4b253a8:

• he tret commit: "false"
• python-semantic-release torna a fer release commit + tag
• el token del pas passa a GH_PAT amb fallback a github.token
• README documenta que, amb main protegida, cal configurar GH_PAT amb permís/bypass per poder empènyer aquest release commit i el tag

També he comprovat patrons similars:

• destral, apply_pr i libFacturacioATR fan bump commit + tag i després publiquen en rebre el tag
• webclient usa GH_PAT per releases amb semantic-release

Validació del nou SHA:

• YAML OK
• tests locals: 49 passed
• checks PR verds: test-python2 i test-python3

PR actualitzada: #35

La part que no puc tancar només amb codi és la configuració operativa: si GH_PAT no existeix o no té bypass sobre la protecció de main, el release tornarà a fallar en el push del commit de bump. Aquí sí que toca canviar protecció/secret, no esquivar el commit.