7 Commits

Include renames

Author	SHA1	Message	Date
jlab-renovate-bot	1ca22c4238	Update docker.io/searxng/searxng Docker tag to v2026.9.13-96479fff6	2026-09-16 10:01:39 +00:00
jlab-renovate[bot]	1fa5179813	Update docker.io/searxng/searxng Docker tag to v2026.9.11-ffe96f8a6	2026-09-14 07:02:09 +00:00
jlab-renovate[bot]	b9a2e3daa3	Update docker.io/searxng/searxng Docker tag to v2026.9.6-8b01679e8	2026-09-08 18:02:03 +00:00
jlab-renovate[bot]	a1e10a3928	Update docker.io/searxng/searxng Docker tag to v2026.8.29-d226b78bc	2026-09-01 09:01:16 +00:00
jklein	5bffc3237a	searxng: render byte counts as plain decimals (1.0.1+up2026.8.22.9fea41204) ... multiplyQuantity turned its input into a string with printf "%v". The null-safe fallback helpers from #99 pass values through fromYaml, which parses every number as float64, and Go's "%v" switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 therefore arrived as "1.048576e+06", the suffix check rejected "e+06" and the render aborted. The same printf sat on the second output path, for a non-integer product (a fractional limitFactor - typed "number", not "integer", in this chart's values.schema.json, so ordinary values reach it). That one never passes the suffix check, so it produced an invalid quantity silently and only the API server would have rejected the manifest on apply. Both are now routed through a formatNumber helper that forces decimal notation and trims the padding zeros. Strings ("512Mi") pass through untouched, so the default render is unchanged - including the checksum/config annotation over the settings.yml ConfigMap, which stays at 619e1ac4 for the CI values and 25bd1479 for the chart defaults, so no pod is rolled without reason. Part of #157. The helper is a verbatim copy of the fix already merged for template-chart, zipline, cyberchef and bentopdf - multiplyQuantity is the same duplicated code in every chart.	2026-08-29 01:13:12 +02:00
jklein	cf43d90beb	searxng: state the limiter probe measurement instead of hedging it ... The comment on the probe block said a probe on "/" would "risk" a 429 once the limiter is on. It was measured against a reachable Valkey in k3d and it does not risk it, it collects one: "/" answered 429 while /healthz answered 200. Comment only, no rendered change.	2026-08-27 21:13:08 +02:00
jklein	46942db53a	searxng: new chart (1.0.0+up2026.8.22.9fea41204) ... SearXNG as a stateless Deployment plus a settings ConfigMap, with the four CI steps a new chart needs: publish workflow, change-app-version choice list, ci/searxng/ fixtures and a renovate.json5 block. Three points where the chart is not a cyberchef with another name: * The image entrypoint writes settings.yml into /etc/searxng only when the file is missing. The chart always mounts one by subPath, so the copy and the random-secret sed never run and the container needs no write access there - which is what allows readOnlyRootFilesystem: true. * The signing key is a required OnePasswordItem, not a ConfigMap key. It signs the settings cookie and the image-proxy URLs, and the entrypoint's self-generating fallback cannot fire here, so without it the instance would run on the literal "ultrasecretkey" - which webapp.py refuses with exit 1. * All three probes use /healthz, the only path the bot detection lets through unconditionally. Measured: with the limiter active, "/" answers 429 while /healthz still answers 200. ingress.domain is read a second time outside the Ingress template, for SEARXNG_BASE_URL, and carries its own required() there - so it stays mandatory with the Ingress switched off. The Renovate versioning regex deviates from the plan on the issue and matches the commit hash WITHOUT capturing it. Renovate parses a "build" group with Number.parseInt, so a hash becomes the digits leading it; measured on renovate 41.173.1 and 44.48.0, the planned form reports an image pushed earlier the same day as an update to a newer one. Reasoning in the block and in README.	2026-08-27 21:09:59 +02:00