Auto-refresh uv/trivy sha256 pins via a Renovate postUpgradeTask #156

Merged

robbertbos merged 1 commit from renovate-auto-refresh-release-sha into main 2026-07-21 21:30:20 +00:00

Conversation 0 Commits 1 Files changed 4 +71 -2

robbertbos commented 2026-07-21 21:00:48 +00:00

Owner

Copy link

Probleem

Renovate's github-releases-customManager bumpt UV_VERSION (ci.yml) en TRIVY_BIN_VERSION (security-scan.yaml), maar niet de bijbehorende hardcoded sha256 die de install-stap verifieert. Elke uv/trivy-bump faalde CI daardoor closed tot iemand de pin handmatig ververste (zie #148).

De image-aanpak kan niet: de gewone CI-jobs draaien op ubuntu-latest zonder container-daemon, container: <uv-image> breekt actions/checkout (geen Node in de image), en third-party actions zijn op deze runner niet gegarandeerd. Daarom bestaat de curl+sha-aanpak - en dit lost het echte gat op: de sha automatiseren.

Oplossing

.forgejo/scripts/refresh-release-sha.sh <depName> <newVersion> haalt de officiële checksum op (uv: per-artefact .sha256; trivy: checksums.txt) en herschrijft UV_SHA256 / TRIVY_BIN_SHA256. Gewired als postUpgradeTask op de uv+trivy github-releases-regel, zodat renovate de gewijzigde pin in dezelfde PR commit. renovate.yaml staat via RENOVATE_ALLOWED_COMMANDS precies dit ene commando toe.

Best-effort: bij een fetch-fout laat het de pin ongemoeid en exit 0, dus het kan een renovate-PR nooit blokkeren (hooguit dezelfde situatie als nu).

Getest (lokaal)

• uv 0.11.30 / trivy 0.72.0 → "already current" (geen wijziging).
• Pin gecorrumpeerd → script herstelt exact de officiële sha.
• Onbekende dep → no-op, exit 0.

Trust-model gelijk aan hoe docker-digests al gepind worden (vertrouw de release-host op pin-moment).

## Probleem Renovate's `github-releases`-customManager bumpt `UV_VERSION` (ci.yml) en `TRIVY_BIN_VERSION` (security-scan.yaml), maar **niet** de bijbehorende hardcoded `sha256` die de install-stap verifieert. Elke uv/trivy-bump faalde CI daardoor closed tot iemand de pin handmatig ververste (zie #148). De image-aanpak kan niet: de gewone CI-jobs draaien op `ubuntu-latest` zonder container-daemon, `container: <uv-image>` breekt `actions/checkout` (geen Node in de image), en third-party actions zijn op deze runner niet gegarandeerd. Daarom bestaat de curl+sha-aanpak - en dit lost het echte gat op: de sha automatiseren. ## Oplossing `.forgejo/scripts/refresh-release-sha.sh <depName> <newVersion>` haalt de officiële checksum op (uv: per-artefact `.sha256`; trivy: `checksums.txt`) en herschrijft `UV_SHA256` / `TRIVY_BIN_SHA256`. Gewired als `postUpgradeTask` op de uv+trivy github-releases-regel, zodat renovate de gewijzigde pin in dezelfde PR commit. `renovate.yaml` staat via `RENOVATE_ALLOWED_COMMANDS` precies dit ene commando toe. Best-effort: bij een fetch-fout laat het de pin ongemoeid en exit 0, dus het kan een renovate-PR nooit blokkeren (hooguit dezelfde situatie als nu). ## Getest (lokaal) - uv 0.11.30 / trivy 0.72.0 → "already current" (geen wijziging). - Pin gecorrumpeerd → script herstelt exact de officiële sha. - Onbekende dep → no-op, exit 0. Trust-model gelijk aan hoe docker-digests al gepind worden (vertrouw de release-host op pin-moment).

robbertbos added 1 commit 2026-07-21 21:00:49 +00:00

Auto-refresh uv/trivy sha256 pins via a Renovate postUpgradeTask ... fbfaa5e4a2

Renovate's github-releases customManager bumps UV_VERSION / TRIVY_BIN_VERSION
but never the companion sha256 the install step verifies against, so every uv
or trivy bump broke CI closed until a maintainer refreshed the pin by hand.

Add .forgejo/scripts/refresh-release-sha.sh, wired as a postUpgradeTask on the
uv + trivy github-releases rule: it fetches the official checksum and rewrites
UV_SHA256 / TRIVY_BIN_SHA256 into the same PR. renovate.yaml allows just this
command via RENOVATE_ALLOWED_COMMANDS. Best-effort - on a fetch failure it
leaves the pin unchanged and exits 0, so it can never abort a Renovate PR.

robbertbos merged commit c9c9ef4e98 into main 2026-07-21 21:30:20 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

robbertbos/waggle!156

No description provided.