CI: publish faalt — wheel sha256 mismatch voor reeds gepubliceerde 0.2.0 #70

Open
opened 2026-06-27 14:57:26 +00:00 by Latte · 0 comments
Owner

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:

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.

## 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._
Latte added the Kind/BugKind/ChorePriority/High labels 2026-06-27 14:57:31 +00:00
Sign in to join this conversation.