-
released this
2026-04-29 09:38:58 +02:00 | 0 commits to 1.4.23-ew since this releasev1.4.23-ew-4
Patch-Release auf v1.4.23-ew-3.
Bugfix: WhitelistedRoutes-Bypass fürs Governance-Plugin landete nie im Image
In
v1.4.23-ew-3haben wir den VK-Pflicht-Bypass im Governance-Plugin (Commit55515ff37) committet, aber das gebaute Docker-Image hat den Bypass NIE ausgeliefert.Ursache: Der Dockerfile-Build erstellt einen
go.workmit nurcore/undframework/. Alle Plugins — auchgovernance— werden übertransports/go.modaus dem Module-Cache (Upstream-Versionen, z. B.governance v1.4.39) gezogen. Lokale Plugin-Änderungen waren also unsichtbar für den Build.Folge:
/v1/modelslieferte trotzWhitelistedRoutes-Eintrag weiter401 virtual key is required— die VK-Pflicht im Plugin lief gegen die alte Upstream-Version.Fix: Alle 8 lokalen Plugins (
governance,litellmcompat,logging,maxim,mocker,otel,semanticcache,telemetry) werden ins Build-Image kopiert und in den Workspace aufgenommen. Damit bautgo buildjeden Plugin aus lokalem Source statt aus der pinned Module-Cache-Version.Was geändert wurde
transports/Dockerfile:COPY plugins/ /plugins/ergänzt.- Workspace-Generation um alle 8 Plugin-Pfade erweitert:
use ( . /core /framework /plugins/governance /plugins/litellmcompat /plugins/logging /plugins/maxim /plugins/mocker /plugins/otel /plugins/semanticcache /plugins/telemetry )
Warum betraf das nicht alle Änderungen?
Frühere Patch-Releases haben funktioniert, weil ihre Änderungen in
core/,framework/odertransports/lagen — diese drei Module sind seit jeher Teil der Workspace. Erst55515ff37(Bypass im Governance-Plugin) musste überplugins/governance/deployed werden — und genau da hatte der Build die Lücke.Upgrade
Nach diesem Image-Push: einmal pullen + neu starten. Die UI-Konfiguration bleibt unverändert (Whitelist-Eintrag z. B.
/v1/models).Vollständiger Changelog
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads