De publish-workflow faalt in de stap "Publish to Gitea PyPI registry" met een sha256-mismatch op een versie die al in de registry staat:
error: Local file and index file do not match for aegis_gitea_mcp-0.2.0-py3-none-any.whl.
Local: sha256=c818fe4350dfa8184452942a893f8dd12bbb1c052752055424cf3be860a6d56c
Remote: sha256=07191db20b845345814ca562881b79c51c42cf1cb36996f92a33c3009295645e
exitcode '2': failure
(De stap "Upload build artifacts" daarvoor faalt ook, maar die staat op continue-on-error: true en is dus niet de oorzaak van de job-failure — de echte failure is de publish-stap.)
Root cause
In .gitea/workflows/publish.yml gebruikt de publish-stap:
De bedoeling (zie comment): --check-url laat uv bestanden die al in de registry staan overslaan, zodat een main-push zónder versie-bump een schone no-op is i.p.v. een 409.
Maar --check-url slaat een bestand alleen over als het byte-identiek is. Versie 0.2.0 is al een keer gepubliceerd, en deze run heeft 0.2.0 opnieuw gebouwd met een andere sha256. Python-wheels zijn standaard niet reproduceerbaar (o.a. zip-timestamps/metadata-volgorde), dus een rebuild van dezelfde versie levert een ander artifact op. uv ziet "zelfde bestandsnaam, andere hash" → weigert te skippen én weigert te overschrijven → exit 2.
Kortom: zodra main opnieuw wordt gepusht zonder versie-bump, faalt de release gegarandeerd zolang de build niet reproduceerbaar is.
Mogelijke fixes (in volgorde van voorkeur)
Versie bumpen per stable release. Publiceer nooit dezelfde X.Y.Z opnieuw. Eventueel een guard toevoegen die de publish-stap faalt/skipt als de versie al in de registry bestaat (expliciete check vóór uv build), met een duidelijke melding "bump de versie".
Pre-publish guard i.p.v. te leunen op --check-url. Query de simple-index op aegis-gitea-mcp/0.2.0; bestaat die al → skip de publish als clean no-op (exit 0), in plaats van uv op de hash te laten klappen.
Reproduceerbare builds.SOURCE_DATE_EPOCH zetten (+ deterministische wheel-build) zodat een rebuild van dezelfde versie wél byte-identiek is en --check-url z'n werk kan doen. Lost de directe symptoom op maar is fragieler dan optie 1/2.
Acceptatiecriteria
Een main-push zonder versie-bump resulteert in een groene run (clean no-op), niet in een sha-mismatch-failure.
Een main-push mét versie-bump publiceert netjes de nieuwe versie.
Aangemaakt via de aegis-gitea MCP.
## Samenvatting
De `publish`-workflow faalt in de stap **"Publish to Gitea PyPI registry"** met een sha256-mismatch op een versie die al in de registry staat:
```
error: Local file and index file do not match for aegis_gitea_mcp-0.2.0-py3-none-any.whl.
Local: sha256=c818fe4350dfa8184452942a893f8dd12bbb1c052752055424cf3be860a6d56c
Remote: sha256=07191db20b845345814ca562881b79c51c42cf1cb36996f92a33c3009295645e
exitcode '2': failure
```
(De stap "Upload build artifacts" daarvoor faalt ook, maar die staat op `continue-on-error: true` en is dus niet de oorzaak van de job-failure — de echte failure is de publish-stap.)
## Root cause
In `.gitea/workflows/publish.yml` gebruikt de publish-stap:
```bash
uv publish \
--publish-url https://git.hiddenden.cafe/api/packages/Hiddenden/pypi \
--check-url https://git.hiddenden.cafe/api/packages/Hiddenden/pypi/simple/ \
...
```
De bedoeling (zie comment): `--check-url` laat uv bestanden die al in de registry staan overslaan, zodat een main-push zónder versie-bump een schone no-op is i.p.v. een 409.
Maar `--check-url` slaat een bestand alleen over als het **byte-identiek** is. Versie `0.2.0` is al een keer gepubliceerd, en deze run heeft `0.2.0` opnieuw gebouwd met een **andere sha256**. Python-wheels zijn standaard **niet reproduceerbaar** (o.a. zip-timestamps/metadata-volgorde), dus een rebuild van dezelfde versie levert een ander artifact op. uv ziet "zelfde bestandsnaam, andere hash" → weigert te skippen én weigert te overschrijven → exit 2.
Kortom: zodra `main` opnieuw wordt gepusht zonder versie-bump, faalt de release gegarandeerd zolang de build niet reproduceerbaar is.
## Mogelijke fixes (in volgorde van voorkeur)
1. **Versie bumpen per stable release.** Publiceer nooit dezelfde `X.Y.Z` opnieuw. Eventueel een guard toevoegen die de publish-stap faalt/skipt als de versie al in de registry bestaat (expliciete check vóór `uv build`), met een duidelijke melding "bump de versie".
2. **Pre-publish guard i.p.v. te leunen op `--check-url`.** Query de simple-index op `aegis-gitea-mcp/0.2.0`; bestaat die al → skip de publish als clean no-op (`exit 0`), in plaats van uv op de hash te laten klappen.
3. **Reproduceerbare builds.** `SOURCE_DATE_EPOCH` zetten (+ deterministische wheel-build) zodat een rebuild van dezelfde versie wél byte-identiek is en `--check-url` z'n werk kan doen. Lost de directe symptoom op maar is fragieler dan optie 1/2.
## Acceptatiecriteria
- Een main-push zonder versie-bump resulteert in een **groene** run (clean no-op), niet in een sha-mismatch-failure.
- Een main-push mét versie-bump publiceert netjes de nieuwe versie.
_Aangemaakt via de aegis-gitea MCP._
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Samenvatting
De
publish-workflow faalt in de stap "Publish to Gitea PyPI registry" met een sha256-mismatch op een versie die al in de registry staat:(De stap "Upload build artifacts" daarvoor faalt ook, maar die staat op
continue-on-error: trueen is dus niet de oorzaak van de job-failure — de echte failure is de publish-stap.)Root cause
In
.gitea/workflows/publish.ymlgebruikt de publish-stap:De bedoeling (zie comment):
--check-urllaat uv bestanden die al in de registry staan overslaan, zodat een main-push zónder versie-bump een schone no-op is i.p.v. een 409.Maar
--check-urlslaat een bestand alleen over als het byte-identiek is. Versie0.2.0is al een keer gepubliceerd, en deze run heeft0.2.0opnieuw gebouwd met een andere sha256. Python-wheels zijn standaard niet reproduceerbaar (o.a. zip-timestamps/metadata-volgorde), dus een rebuild van dezelfde versie levert een ander artifact op. uv ziet "zelfde bestandsnaam, andere hash" → weigert te skippen én weigert te overschrijven → exit 2.Kortom: zodra
mainopnieuw wordt gepusht zonder versie-bump, faalt de release gegarandeerd zolang de build niet reproduceerbaar is.Mogelijke fixes (in volgorde van voorkeur)
X.Y.Zopnieuw. Eventueel een guard toevoegen die de publish-stap faalt/skipt als de versie al in de registry bestaat (expliciete check vóóruv build), met een duidelijke melding "bump de versie".--check-url. Query de simple-index opaegis-gitea-mcp/0.2.0; bestaat die al → skip de publish als clean no-op (exit 0), in plaats van uv op de hash te laten klappen.SOURCE_DATE_EPOCHzetten (+ deterministische wheel-build) zodat een rebuild van dezelfde versie wél byte-identiek is en--check-urlz'n werk kan doen. Lost de directe symptoom op maar is fragieler dan optie 1/2.Acceptatiecriteria
Aangemaakt via de aegis-gitea MCP.