From 561816d79d222eaefffc0993029f41490dc74c47 Mon Sep 17 00:00:00 2001 From: noroot Date: Wed, 2 Sep 2026 16:46:12 +0200 Subject: [PATCH] =?UTF-8?q?fix(release):=20bun=20statt=20npm-Fallback=20f?= =?UTF-8?q?=C3=BCr=20Release-Builds=20erzwingen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit make ui fällt ohne bun still auf npm install zurück — löst Dependencies gegen package.json neu auf statt gegen das gepinnte management-ui/ bun.lock und hinterlässt eine dazu inkonsistente package-lock.json. Der gelockerte Dirty-Check (--untracked-files=no, letzter Commit) ignoriert genau dieses Artefakt, weil es zusammen mit anderer fremder unversionierter Arbeit im Repo liegt — beide Fixes zusammen hätten also einen Release mit abweichender Dependency-Auflösung klaglos durchgelassen. release.sh bricht jetzt hart ab wenn bun fehlt, statt sich auf den Fallback zu verlassen — Release-Builds (Testing UND Stable) müssen reproduzierbar aus dem gepinnten Lockfile bauen. Co-Authored-By: Claude Sonnet 5 --- scripts/release.sh | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/scripts/release.sh b/scripts/release.sh index de0883a..073cea0 100755 --- a/scripts/release.sh +++ b/scripts/release.sh @@ -50,6 +50,15 @@ if [ -z "${GITEA_TOKEN:-}" ]; then fi export GITEA_TOKEN +# `make ui` fällt bei fehlendem bun auf `npm install` zurück (Convenience +# für schnelle lokale Builds) — das löst Dependencies gegen package.json +# neu auf statt gegen das gepinnte management-ui/bun.lock, und hinterlässt +# eine package-lock.json die nichts mit dem committeten Lockfile zu tun +# hat. Für einen Release (Testing ODER Stable) ist das nicht akzeptabel — +# beide Kanäle müssen reproduzierbar aus dem gepinnten Lockfile bauen. +command -v bun >/dev/null 2>&1 || \ + abort "bun fehlt — Release-Builds müssen aus management-ui/bun.lock bauen, nicht aus dem npm-Fallback. Installieren: https://bun.sh/install" + # ─── Testing-Version: datumsbasiert YYYY.MM.DD.NN ────────────────────── # NN = laufende Nummer für den Tag, ermittelt aus den bereits im Registry # vorhandenen Versionen des Meta-Pakets (edgeguard) mit dem heutigen