The publish step no longer speaks OCI. "helm registry login", "helm push"
and "helm registry logout" are replaced by a single HTTP POST of the
packaged .tgz to <charts-url>/api/charts, with Basic auth per request.
Credentials and the target URL come from a new 1Password item
op://GitHub-Actions/jlab-registry-access (username, password, charts-url).
The old item is left untouched, so a revert of this commit restores the
previous pipeline without any further work. No registry address enters
the repository.
The three properties of the old step survive:
- values are read via steps.<id>.outputs.* into the step's own env block
and used as quoted shell variables, each guarded with ":?"
- credentials stay out of argv: "curl --config -" instead of "--user"
- a failed upload fails the job: "--fail-with-body", because curl exits 0
on HTTP 401/403/409 without it and the publish would go green with
nothing uploaded
The "<chart>-*.tgz" glob is replaced by the file name built from the
chart name and the version already read from Chart.yaml; --upload-file
takes exactly one file. Two small additions fall out of measuring the
new step: the registry host is masked, because a curl connection error
prints only "<host>:<port>" and the mask on the full URL does not cover
that, and whitespace in the credentials is rejected up front, because an
unquoted curl config value ends at the first space.
No chart is touched and no chart version is bumped.
Minecraft 26.2 requires Java 25, so the chart's default minecraft.version can
only be raised on a java25 image. appVersion becomes 2026.8.2-java25 - the same
dated upstream release the java21 line ships, so the only variables that change
are the JVM and the Minecraft version.
The chart version stays at 4.1.0: the Java lines are siblings of one chart
generation, not successors, and are told apart by the +up suffix.
The Java boundaries in the values.yaml / NOTES.txt comments are read off
Mojang's version manifest (javaVersion.majorVersion per release), not
estimated: 1.21.11 is the last release asking for Java 21, every release from
26.1 on asks for Java 25.
Deploys matszwe02/ytdlp_web_player, a Flask app that fetches videos with
yt-dlp, transcodes them with ffmpeg and serves them as HLS. It ships no
authentication of any kind, so the chart carries a preconfigured oauth2-proxy
as an optional subchart, in the data path in front of the app.
This is the first chart in the repo with a dependency, so the rule "charts
have no dependencies" falls here. It is replaced in CLAUDE.md and README.md by
a bar: a dependency has to be optional and off by default, upstream's chart is
consumed as it comes (documented where it falls short of our conventions,
never patched), and the price is written down - above all that a subchart is
invisible to everything downstream watching Helm release versions, so a new
proxy release only reaches a cluster when this chart is republished.
CI learns the dependency in five places, not the three the plan expected:
helm lint, package, template and install all exit 1 while charts/ is unfilled,
so ci/helm-dependencies.sh runs before lint and package in validate-charts.yml,
before package in publish-helm-chart.yml, and inside run-install-test.sh,
run-trivy-config.sh and run-quantity-render-test.sh - the last of which renders
every chart on every PR and would have gone red first.
Notable chart decisions, each measured rather than assumed:
- The image has no USER and runs as root by default, but not by necessity: it
runs under an arbitrary uid with readOnlyRootFilesystem and the full
hardening baseline. Only the pinned uid is a deviation, and it is documented.
- Two emptyDirs, each justified separately. /data holds the video cache
(DATA_PATH). /tmp is NOT mounted - measured across metadata extraction, HLS
transcoding, sprite generation and audio extraction, the image never writes
there. What it does write is $HOME/.cache, so /cache is mounted with HOME and
XDG_CACHE_HOME pointed at it; without it yt-dlp re-downloads its JavaScript
challenge-solver from github.com on every extraction.
- The proxy is wired through config.configFile, the only value the subchart
passes through tpl - config.upstreams is emitted with toJson and would carry
a literal {{ .Release.Name }} into the manifest.
- Rendering aborts when this chart's Ingress and the proxy's claim the same
host: ingress-nginx rejects the second one and a Fleet bundle then sits in
ErrApplied until forceSyncGeneration is bumped.
Fixes#214
The NOTES.txt bullet still said the file was "planned (#43)" and named nine
charts as the ones shipping one. Both halves are now wrong: 23 of 23 charts
carry a templates/NOTES.txt, template-chart included. The count was also
wrong when it was written — the very commit that raised it to "nine" added
template-chart/templates/NOTES.txt, making it ten, and the enumeration was
never maintained. Replaced with a statement and no list, so the next new
chart cannot make it stale again; the quality bar the programme settled on
(rendered URL, which fields the 1Password item must carry, the options
actually active, the chart's traps — conditional on the values really set)
is kept and now reads as a requirement for new charts.
Two further statements corrected against origin/main:
- The chart table listed 22 of 23 charts; `bentopdf` was missing entirely
although it ships (bentopdf/Chart.yaml, 1.0.1+up2.8.7) and has CI fixtures.
- The homeassistant row advertised "has NOTES.txt and Helm tests". The
NOTES.txt half stopped being a distinguishing property once every chart
got one. The Helm tests half holds and is now stated as what it is:
homeassistant/templates/tests/test-connection.yaml is the only such file
in the repo.
Documentation only — no chart directory, no version bump, no publish.
Part of #43.
Adds ci/run-quantity-render-test.sh and a validate-charts job that runs it
over every chart on every PR.
The bug behind #157 has a loud and a silent half. Loud: a bare integer request
of 1048576 is reformatted by printf "%v" to "1.048576e+06", the helper rejects
the suffix it produced itself and the render aborts. Silent: with a fractional
limitFactor the *product* is reformatted after the suffix check, the render
succeeds, and the manifest carries memory: "1.4999985e+06" - rejected by
nothing until the API server sees it at apply time.
So the test renders each chart twice and, for the silent case, searches the
rendered text rather than the exit code. It runs over all charts, not the
changed ones: the resources helper is copied into every chart's _helpers.tpl,
so the regression arrives by copy, in a PR whose diff shows a new chart and not
the bug inside it. The resources paths come from values.schema.json (JSON, so
python3 reads it without pyyaml), which also means a new chart is enrolled
automatically and there is no list to maintain.
Charts that pin every computable limit in their fallback defaults never reach
the helper (gotenberg, rss-bridge). They are reported as "not exercised"
instead of counted as passing.
Part of #43. This chart was cited throughout that issue as the one that already has a NOTES.txt and therefore serves as the style reference for the whole programme. The file contained the single line "Hello :)". It is replaced here by the real thing, built on the pattern the later charts (zipline, voucher-vault, urlaubsverwaltung) established in the meantime.
It prints what an operator would otherwise have to read out of the templates: the access URL assembled from the chart's upstream-style ingress block (hosts x tls, so the scheme is derived per host rather than assumed) or the port-forward command; the three fields the 1Password item must carry (config, http-config, recorder-config) and how configuration.yaml has to include the other two itself; and the traps of this particular chart - onboarding hands the instance to the first visitor, use_x_forwarded_for/trusted_proxies decides between 400 Bad Request and one client IP for everyone, the three config files are read-only subPath mounts that the kubelet never refreshes, safe mode lets a broken configuration pass the probes, and helm uninstall deletes the PVC that holds all of the state.
Conditional sections cover scaleDown/replicas 0, replicas > 1 on a single ReadWriteOnce claim, a NET_RAW override that silently kills device discovery, a non-empty env block, the chart placeholder host chart-example.local, and the case where ingress.tls names a Secret while no cert-manager annotation is set - this chart adds none by itself, unlike the rest of the repo.
No domain appears in the file: hosts come from the values, examples use example.com. Minor bump, appVersion unchanged; a NOTES.txt changes no rendered object, verified by diffing helm template before and after.
Part of #157. The null-safe fallback helpers from #99 pass values through fromYaml, which parses every number as float64; Go's "%v" switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 therefore reached multiplyQuantity as "1.048576e+06" and the render aborted on the suffix check.
This is the canonical correction already merged into the other charts, adopted verbatim with this chart's define prefix: multiplyQuantity formats its input and its non-integer product through a new formatNumber helper. The fromYaml round-trip itself is not touched - it is not the cause, and it has just been unified across all charts.
Measured against ci/homeassistant/test-values.yaml: resources.requests.memory=1048576 aborted before and now yields request 1048576 / limit "3145728"; 65536 still yields 196608. The silent variant matters here too - values.schema.json types resources.limitFactor as "number" with exclusiveMinimum 0, so a fractional factor is allowed and rendered an invalid quantity without any error (limitFactor 1.5 with memory 999999 produced memory: "1.4999985e+06"); it now produces 1499998.5.
Teil von #157.
The null-safe fallback helpers from #99 pass values through fromYaml, which
goes over JSON and therefore parses every number as float64. Go's "%v"
switches float64 to exponential notation from about 1e6 upwards, so a bare
byte count like 1048576 turned into "1.048576e+06" - not a valid Kubernetes
quantity. The suffix check in multiplyQuantity then aborted the render with
unsupported resource quantity suffix "e+06" in "1.048576e+06"
The second "%v" - the one printing a non-integer product - never reaches that
check and failed silently instead: with a fractional limitFactor it rendered
"1.4999985e+06" into the manifest, which only the API server rejects on apply.
Both call sites now go through a new rss-bridge.formatNumber helper that
forces decimal notation via printf "%.10f" and trims the padding zeros again;
the leading dot in the regex protects "100.0000000000" from collapsing to
"1". Strings such as "512Mi" pass through untouched.
This is the canonical fix from #157, applied verbatim with this chart's
prefix; the round-trip itself is not touched.
Note on this chart specifically: rss-bridge sets explicit memory and
ephemeral-storage limits as chart defaults, and an explicit limit always
wins, so multiplyQuantity is not reachable through this chart's values at
all - the bug was reproduced and the fix verified on a throwaway copy with
those default limits removed. The rendered output for the chart defaults and
for ci/rss-bridge/test-values.yaml is byte-identical to main.
Patch bump: no behavior and no values-schema change.
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.
The null-safe fallback helpers from #99 pass values through fromYaml, which
parses every number as float64. Go's "%v" switches float64 to exponential
notation from about 1e6 upwards, so a bare byte count like 1048576 reached
multiplyQuantity as "1.048576e+06" and the render aborted with
unsupported resource quantity suffix "e+06" in "1.048576e+06"
The same "%v" sits a second time on the output of a non-integral product,
where it never passes the suffix check — a fractional limitFactor together
with a bare number rendered a silently invalid quantity ("1.4999985e+06")
that only the API server rejects on apply.
Both call sites now go through a new patchmon.formatNumber helper, which
forces decimal notation for float64 and passes strings ("512Mi") through
untouched. This is the canonical fix agreed in #157, taken over verbatim
from template-chart with this chart's define prefix, so multiplyQuantity
stays the same copy in every chart.
Teil von #157.
The null-safe fallback helpers from #99 route values through fromYaml, which
parses every number as float64. Go's "%v" switches float64 to exponential
notation from about 1e6 upwards, so a bare byte count like 1048576 reached the
suffix check inside multiplyQuantity as "1.048576e+06" and the render aborted
with `unsupported resource quantity suffix "e+06"`.
Both printf "%v" sites in multiplyQuantity now go through a new formatNumber
helper that forces plain decimal notation and trims the padded zeros. The
second site is the quiet half of the bug: a fractional limitFactor together
with a bare number produced no error at all, just an invalid quantity such as
"1.4999985e+06" that only the API server rejects on apply. limitFactor is
typed "number" in this chart's values.schema.json, so a fractional factor is
an ordinary, schema-valid input.
All ten resource paths of the stack are affected and were verified one by one
(gluetun, qbittorrent and its configInit init container, prowlarr,
flaresolverr, radarr, recyclarr, sonarr, seerr, bazarr). The VPN, firewall and
container structure is untouched: rendering the chart with its default values
is byte-identical to main.
Teil von #157
The null-safe fallback helpers from #99 pass values through fromYaml, which
parses every number as float64. Go's "%v" switches float64 to exponential
notation from about 1e6 upwards, so a bare byte count like 1048576 turned into
"1.048576e+06" - not a valid Kubernetes quantity. multiplyQuantity then aborted
the render on its own suffix check. The second "%v", the one printing a
non-integer product, never reaches that check and rendered an invalid quantity
silently; only the API server rejects it on apply.
Both call sites now go through a new formatNumber helper that forces plain
decimal notation and passes strings ("512Mi") through untouched. The
fromYaml/toYaml round-trip is not touched: it was just unified across all
charts and it is not the cause.
gotenberg reaches multiplyQuantity from two places - the Deployment's
resources block and NOTES.txt, which reports the effective limits. With the
chart's default values both non-CPU resources carry an explicit limit, so no
limit is computed and neither site was affected in the default configuration.
Teil von #157
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.
Part of #157. The helper is a verbatim copy of the fix already merged
for template-chart, zipline, voucher-vault and outline - multiplyQuantity
is the same duplicated code in every chart.
multiplyQuantity turned its input into a string with printf "%v". The null-safe fallback helpers from #99 route values through fromYaml, which parses every number as float64, and Go switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 became "1.048576e+06" and the suffix check aborted the render.
The non-integer product used the same printf "%v" on output. That path never reaches the suffix check, so it rendered an invalid quantity silently, which only the API server rejects on apply. cyberchef types limitFactor as "number", so a fractional factor is allowed by the schema and that path is reachable with ordinary values.
Both call sites now go through a new formatNumber helper that forces decimal notation and trims the padding zeros; strings such as "512Mi" pass through untouched. Round-trip and resources helper are unchanged. The wording matches the canonical fix already merged for template-chart and the other charts, so the shared copy stays free of drift.
jklein
jlab-renovate[bot]