The issue plan listed qmcgaw/gluetun:3.41.1, but the published tag is
v3.41.1. appVersion is the exact image tag per the style guide, so
appVersion becomes v3.41.1 and the chart version 1.0.0+upv3.41.1
(precedent: matrix-synapse, satisfactory, calibre-web-automated).
Sets seccompProfile.type: RuntimeDefault in the pod security context of
minecraft-router, outline, urlaubsverwaltung, zipline, voucher-vault,
satisfactory, patchmon and calibre-web-automated, so the container
runtime's default syscall filter applies to every container in the pod.
The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.
Five of the eight also get the docker.io/ prefix on their previously
unqualified image references, so the pull no longer depends on the
runtime's default-registry setting: itzg/mc-router,
outlinewiki/outline, urlaubsverwaltung/urlaubsverwaltung,
l4rm4nd/vouchervault (twice, app and init container) and
guacamole/guacd:1.6.0. zipline, satisfactory and calibre-web-automated
were already qualified with ghcr.io.
Verified in a throwaway k3d cluster against real application work, not
just a Running pod, and with Seccomp: 2 (filter mode) read from
/proc/<pid>/status inside each container:
- minecraft-router: a Minecraft handshake for a mapped domain travels
through the router to a backend and the backend's status payload comes
back to the client.
- outline: all migrations apply (45 tables), OIDC discovery succeeds and
the server-rendered page answers 200 with <title>Outline</title>.
- urlaubsverwaltung: Liquibase applies 79 changesets (35 tables), the app
seeds its settings and vacation types, /login answers 200.
- zipline: 27 migrations applied, then a full round trip - first user
created, login, token, upload, and the file downloaded back byte-exact
from the PVC.
- voucher-vault: the init container's collectstatic output is served
(200, 22 KB), Django has its 22 tables and uWSGI answers 200 with
<title>VoucherVault</title>.
- satisfactory: application behavior is NOT proven - the image is
multiple GB and pulls 10 GB+ of game files on first start, which is why
the chart sits in ci/excluded-charts.txt. What is proven is that the
rendered pod securityContext is accepted server-side and yields
Seccomp: 2 with uid/gid 1000 on a substitute image.
- patchmon: both containers run under the pod profile and both report
Seccomp: 2. The server applies 47 migrations (44 tables), connects to
Postgres and Redis and serves its dashboard; guacd answers a real
Guacamole "select rdp" instruction with its full args list, over the
same 127.0.0.1:4822 path the chart wires up.
- calibre-web-automated: the readOnlyRootFilesystem: false deviation is
unaffected - id abc is still uid 1000 (not the 911 the image falls back
to in read-only mode), /config and the Calibre metadata.db are owned by
1000, and both the root s6 init and the uid-1000 application report
Seccomp: 2. calibredb 9.1 runs and adds a book. Its IPC worker prints a
traceback while doing so, but an unconfined control pod on the same
image prints the same class of traceback, so it is not the filter.
trivy config now reports "0 to act on" for all eight; the untouched
samba still shows KSV-0104 and KSV-0030, which confirms these charts are
what closed the findings.
No values.schema.json needed changing: in all eight schemas
securityContext.pod is type ["object", "null"] with no property
restrictions, so the new key validates as it stands. The #99 null paths
still hold - nulling securityContext or securityContext.pod falls back to
the defaults including the new one.
Renovate resolves the prefixed guacd reference: a local dry-run lookup
(renovate 44.40.1, --platform=local --dry-run=lookup) reports depName
docker.io/guacamole/guacd against registryUrl https://index.docker.io
with lookupName guacamole/guacd, currentVersion 1.6.0 and its real
release timestamp, with no warnings. The other four prefixed references
live in templates, which Renovate never reads - they are tracked by the
customManagers via appVersion in Chart.yaml with a depName hardcoded in
renovate.json5, so they are unaffected.
Major bump for all eight: runtime behavior changes.
Refs #84
The rationale called the alpine switch a proposal from the issue text.
A later comment on #84 commissions it as a check with a defined scope
(nginx.conf compatibility, port 8080, uid 101, /tmp redirection) to be
done alongside the seccompProfile PR for this chart. The outcome is open,
the check is not - the constraint has to survive either way.
The anchored form rejected any tag with a suffix. Docker versioning only
offers candidates carrying the current tag's suffix, so the day the
delegation sidecar moves to a slimmer base image (#84, still open) every
candidate would fail the filter and nginx would stop receiving updates -
without an error, a warning, or a red dashboard.
Verified against currentValue 1.28.0-alpine: anchored form returns
"updates": [] and "warnings": [], the suffix-tolerant form proposes
1.30.4-alpine and still refuses the newer 1.31.x mainline.
nginx numbers its release branches by minor: even is stable, odd is
mainline. PR #139 proposed 1.30.4 -> 1.31.4, which would have moved the
Synapse delegation sidecar onto mainline without that ever being a
decision. allowedVersions now permits even minors only; patch updates
inside the stable branch still come through and still automerge.
The two open Renovate PRs (#138 alpine 3.22 -> 3.24, #139 nginx 1.30.4 ->
1.31.4) never automerged because both are minor updates while the rule
only covered patch and digest. Sidecar images barely move in patch steps,
so patch-only would practically never fire.
Automerging a chart update publishes it, so the install-test can no
longer report failures without blocking: continue-on-error is gone and
issue #22's stabilization phase ends here. Majors stay manual.
Renovate only ever rewrites appVersion or an image tag, so every PR it
opened against a chart directory failed the build-chart version check
(#138, #139). ci/renovate-bump-chart.sh recomputes
version: <semver>+up<appVersion> as a postUpgradeTasks hook: chart major
when the app major moves, chart patch otherwise.
Each chart renders its main image as <repo>:{{ .Chart.AppVersion }}, so
repository and version live in different files and Renovate cannot join
them. The mapping is one customManager per chart in renovate.json5,
deliberately not a comment inside each Chart.yaml - that would touch all
20 chart directories and force 20 publishes for a comment change.
Patch and digest updates automerge after a 3-day minimumReleaseAge once
the pipeline is green; majors arrive one line at a time to match the
stepwise app-major procedure. ci/** stays excluded: the install-test
fixtures pin throwaway infrastructure to major lines on purpose.
One step: 2025-08-05 is the immediate successor release, no publication
in between (verified against the project's release list). Tag present on
Docker Hub for amd64 and arm64.
Patch bump, because the changelog review found nothing that touches the
values surface or the chart's behaviour. Checked against the shipped
source of both images rather than against the release notes:
- whitelist.txt format: lib/Configuration.php is byte-identical apart
from its VERSION constant, so the parsing the chart relies on (trim,
split on newline, drop empty entries, "*" wildcard) is unchanged.
- the five production bridges: all present, none renamed. Youtube,
TheHackerNews, ARDMediathek and Reddit are byte-identical; Heise has a
content-level change only (paywalled heise+ items now carry an
archive.is link, two more CSS selectors stripped). The three bridges
removed upstream - Askfm, DansTonChat, FirstLookMediaTech - are none
of ours.
- RSSBRIDGE_* environment mapping: same file, therefore unchanged.
- write paths: re-derived empirically rather than inferred, because the
opcache lock file in /tmp appears in no filesystem diff. The new image
needs exactly the same five, and a control run without /tmp still dies
with "Unable to create lock file: Read-only file system".
- health endpoint: actions/ is identical, /?action=health intact.
- PHP 8.2.28 -> 8.2.29, nginx and Debian unchanged, so the
/run/php/php8.2-fpm.sock path the chart mounts still applies. Measured
fresh-start peak under five concurrent feed fetches: 64.5 MiB on the
new image against 71.1 MiB on the old one under an identical
procedure. Requests and limits stay as they are.
The memory comments in values.yaml are refreshed to the image the chart
now ships, and the older 119 MiB figure is labelled as what it was - a
warm container, not a fresh start.
We stay on the dated release tag. The newest release is itself over
twelve months old and the project now pushes latest and commit-based
sha-* tags continuously, but a sha-* tag is not more released than the
release, only newer, and latest is rolling - both conflict with the
repo's convention of reproducible pinned tags.
Fixes#135
Follow-up to the template-chart hardening fixes in #133, which landed
while this branch was open.
The env block now quotes names, values and keyRef fields. Without it a
value like "5" renders as a YAML number and the API server rejects the
whole manifest. RSS-Bridge takes numeric settings that way
(RSSBRIDGE_http_timeout), so this was reachable with the first env entry
anyone adds.
The port-80 question is settled by measurement rather than by the
"it works in k3d" reasoning #133 warns about. Same pod spec in k3d
(k3s v1.35.5), only ip_unprivileged_port_start changed:
1024, capabilities.drop [ALL] nginx: bind() to 0.0.0.0:80 failed
(13: Permission denied)
1024, plus NET_BIND_SERVICE identical failure - for a non-root
process the capability lands in the
permitted but not the effective
set, so it buys nothing
0 binds, HTTP 200
So the chart cannot buy safety with a capability the way samba does, and
port 80 is not negotiable either: nginx is configured for it inside the
image and the entrypoint's only lever is a sed against a read-only
/etc/nginx. What it can do is stop depending on the node default - the
pod securityContext now pins the sysctl to 0, so the bind no longer
relies on cluster configuration. Verified: the chart-installed pod
reports 0 and answers 200 through the Service.
Worth recording how that failure looks without probes: the entrypoint
backgrounds nginx and then execs php-fpm, so a failed bind leaves a
container reporting Running with no web server at all. Both test pods
above were Running. The probes on /?action=health are what turn it into
a pod that never becomes Ready.
trivy config still reports 0 to act on; the KSV-0117 statement is
updated to the measured reasoning.
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod.
The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.
Verified in k3d against the database path rather than a static page:
under the filter the app opens its connection to Postgres and Prisma
applies all migrations (141 rows in _prisma_migrations, 31 tables
created), and the server-rendered pages answer with HTTP 200. The kernel
reports Seccomp: 2 (filter mode) inside the container.
Major bump: runtime behavior changes.
Refs #84
Two findings from the Trivy config scan that landed on main in #129.
AVD-KSV-0125 is fixed rather than excepted: writing the image as
docker.io/rssbridge/rss-bridge puts a real registry in the registry
position instead of "rssbridge", which is what ci/trivy/data/ksv0125.yaml
asks for. Verified in k3d that the qualified reference resolves to the
same digest (sha256:0eca99b2...) and still runs.
AVD-KSV-0117 (containerPort below 1024) becomes a scoped, documented
exception. nginx listens on 80 inside the image, and the entrypoint's
only way to change that is a sed against /etc/nginx/sites-enabled/default
which a read-only root filesystem rejects - so the alternative to port 80
is giving up readOnlyRootFilesystem. The premise of the check does not
hold here anyway: the container binds 80 as uid 33 with all capabilities
dropped and no NET_BIND_SERVICE.
trivy config now reports 0 to act on for this chart.
Takes over the four loose manifests in cluster-config/rss-bridge/ as a
proper chart, on the current template-chart standard: strict values
schema, null-safe helpers, computed limits, replicas/scaleDown,
checksum/config, NOTES.txt.
Two things deviate from the repo standard on purpose:
- The Ingress models host AND TLS secret name per entry instead of the
single conventional tls-<release>-<chart>-ingress. The installation
this replaces has grown three separate certificates, one per host.
Renaming them would make cert-manager issue three new ones and leave
each host unreachable until it did - a self-inflicted outage on a
deployment that has been up for over a year. Entries sharing a secret
name are grouped into one tls entry, and omitting the name falls back
to the convention, so consolidating later is a values change.
- Requests and limits are decoupled. The old manifest requested 2Gi of
ephemeral storage, identical to its limit, reserving two gigabytes for
a workload measured at 2.2 MB after fetching all five whitelisted
bridges. The request drops to 64Mi; the limit stays at 2Gi.
Hardening was verified rather than assumed. The image ships no USER and
runs as root by default, but runs fully hardened once its writable paths
are provided: uid/gid 33, readOnlyRootFilesystem, all capabilities
dropped, seccompProfile RuntimeDefault. The writable paths were found by
running the image with a writable rootfs, exercising every bridge and
reading its diff layer - /app/cache, /run, /run/php, /var/lib/nginx.
/tmp did not show up that way, because PHP's opcache creates its lock
file there and unlinks it immediately; it only surfaced when the
hardened container died at startup. Stopping at the first writable path
would have shipped a chart that cannot start.
Probes use the app's own /?action=health, which renders fixed JSON
without touching the cache or any remote site, so neither a scraped site
going down nor an unwritable cache can restart the pod.
Fixes#128
Five changes to the scaffold every future chart is copied from:
1. seccompProfile.type: RuntimeDefault in the pod security context, in
line with the rest of the seccomp series (#84). Pod context, because
from there it also covers init containers and any container added
later without being repeated.
2. containerPort 80 -> 8080, clearing AVD-KSV-0117. Note that the usual
justification for this does not hold: a non-root container CAN bind
port 80 on current Kubernetes, because the kubelet sets
net.ipv4.ip_unprivileged_port_start=0 in the pod network namespace.
Measured, not assumed - see the values.yaml comment. The reason to
stay above 1024 is that this is a runtime default rather than a
guarantee, and that every real chart here already does.
3. The ConfigMap placeholder key is renamed from the literal "key" to
"example-setting", clearing AVD-KSV-01010 (secret-scanner patterns
match any key named "key").
4. The image placeholder is fully qualified as ghcr.io/ORG/IMAGE, so the
template stops teaching the unqualified form that produced the
repo's unqualified Docker Hub images.
5. env values are rendered through "quote". Without it a value like
"8080" renders as a YAML number and the API server rejects the whole
manifest ("cannot unmarshal number into Go struct field
EnvVar.value of type string"). Every real chart in the repo already
quotes here; only the template did not. Found by instantiating the
template and installing it, not by rendering it.
Verified by instantiating the scaffold into a working chart per the
README procedure and installing it in k3d: the workload becomes Ready,
the Service routes to the app on 8080 and an ephemeral container added
to the running pod inherits Seccomp: 2 from the pod context.
Refs #84
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod.
The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.
Verified in k3d against real extractions rather than a reachable port:
the -full image loads its parsers dynamically, so a blocked syscall would
surface as HTTP 200 with empty text, not as an error. The PDF parser, the
HTML parser and the detector/metadata path all return the expected
content under the filter, and the kernel reports Seccomp: 2 (filter mode)
inside the container.
Major bump: runtime behavior changes.
Refs #84
The pod runs rootless as uid/gid 1000; only init-run-ownership is root, to
chown the /run emptyDir that s6-overlay requires to be owned by the runtime
uid. Justified in paperless-ngx/values.yaml, so AVD-KSV-0105/-0022/-0106 are
excepted for that chart with the reason, instead of being reported as if the
workload itself ran as root.
Adds a trivy-config job to the PR pipeline that renders each changed chart
with Helm and runs `trivy config` over the rendered manifests. Reporting
only - TRIVY_CONFIG_MODE=report always exits 0, so the job never blocks a PR.
Rendered manifests rather than the chart directory: `trivy config <chart-dir>`
renders with default values, which fails on every chart here because of their
required() values - and Trivy does not fail with it, it logs "Skipping chart"
and prints an empty, green report.
Values come from the install-test fixtures (ci/<chart>/test-values.yaml), the
only committed per-chart values in the repo; none of them touches
securityContext, images or capabilities, so the scan sees the chart's own
hardening. Charts without fixtures get ci/trivy/values/<chart>.yaml.
Exceptions live in ci/trivy/trivyignore.yaml in Trivy's native ignore-file
schema, each with a statement - the script refuses to run without one and
reports suppressed findings with their reason instead of hiding them.
AVD-KSV-0125 is configured instead of excepted: ci/trivy/data/ksv0125.yaml
lists the trusted registries, so the check stays able to flag a genuinely
foreign source.
Refs #84.
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod.
The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.
Gotenberg is the chart where a syscall filter was most likely to bite: it
drives headless Chromium and LibreOffice, and browser sandboxes are the
classic casualty of a restrictive seccomp profile. Verified in k3d that
both engines still work under the filter - Chromium HTML->PDF and
LibreOffice document->PDF both return real, non-empty PDFs, and the
kernel reports Seccomp: 2 (filter mode) inside the container.
Major bump: runtime behavior changes.
Refs #84
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod. Verified in k3d: /proc/1/status reports Seccomp: 2 (filter
mode) with one filter loaded, and nginx keeps serving the app.
The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.
Major bump: runtime behavior changes, even though it stays invisible for
this workload.
Refs #84
The computed limits (limitFactor 3 x request = 1536Mi memory, 30Mi ephemeral
storage) were too small for real documents: a 12 MB HTML already gets the
container OOM-killed, and the caller sees no HTTP error at all, just a dropped
connection and a rising RESTARTS counter.
Rather than raise the requests and reserve conversion-sized capacity on the
node around the clock, requests and limits are decoupled: the requests stay as
they were, and both limits are now set explicitly. The chart already supported
this - an explicit limit wins over the limitFactor computation.
Measured in a throwaway k3d cluster with the official image (HTML via
Chromium), building on the series in the issue:
18 MB HTML, 2Gi -> OOMKilled
18 MB HTML, 2560Mi -> OOMKilled
18 MB HTML, 3Gi -> HTTP 200 in ~22s, 21 MB PDF
12 MB HTML, 1536Mi -> OOMKilled (the old computed limit)
12 MB HTML, 2Gi -> HTTP 200 in ~13s
Memory beyond 3Gi buys nothing: gotenberg's own request timeout is 30s and the
chart passes no flags to change it, so a document needing more memory has
already run out of time (a 25 MB HTML misses the 30s even at 4Gi).
The ephemeral-storage limit is raised in the same change, because raising
memory alone only moves the failure. With 3Gi memory and the old 30Mi limit,
/tmp peaked at 40 MB on a single conversion and at ~125 MB over a short
series, and the pod was evicted:
Pod ephemeral local storage usage exceeds the total limit of containers 30Mi
That failure is worse than the OOM-kill: the pod does not restart, it is
replaced, and the old one is left behind as Evicted.
The defaults in the effectiveResources helper are updated in lockstep with
values.yaml, so an erased "resources:" block (#99) falls back to the new
explicit limits instead of the old computed ones.
NOTES.txt is pulled along. Its numbers came from effectiveResources already,
but the text described a threshold that has moved and advice that no longer
holds: raising the request no longer drags the limit with it now that the
limits are explicit. The warning is kept but no longer claims memory is the
first limit you hit - with these limits, the 30s timeout is.
Major, because the runtime behaviour changes and the pod may occupy more
memory during large conversions than it was allowed to before.
Fixes#106
Closes out the schema programme (#68) by moving what the 18 charts taught
into the reference implementation and the binding guidelines.
template-chart:
- values.schema.json as the reference schema: additionalProperties false
on every chart-owned level, pod-spec passthrough left open, and the
reasoning inline in the descriptions so a copy carries it along.
- defaultedDict and subBlock plus the per-block fallbacks for both
security contexts, the three probes and resources, wired into both the
Deployment and the StatefulSet.
- the reference itself violated guideline 1: its env block reads
ingress.domain, so with the Ingress gated off it rendered an empty
value. That read is now required(), and the comment says why - the
template is what people copy, so it has to teach the guard, not the
hole.
README, new section "Values that must not lie" with the five rules:
1. a value read outside its obvious template needs its own guard
(matrix-synapse published '{"m.server": ":443"}' to federation without
it, rendering cleanly and reporting healthy)
2. probes, contexts and resources through the null-safe helper, never
behind an "if" - a guard removes the probe instead of showing a null
3. no liveness on an external dependency where a dependency-free path
exists, otherwise document why on the helper
4. a fallback reproduces THIS chart's defaults, not the repo standard -
calibre's readOnlyRootFilesystem: false is what keeps the runtime uid
at 1000 instead of 911 and existing volume data readable
5. a probe default carries its context - port name, Host header, exec
command - or the probe vanishes (teamspeak) or gets 403 (patchmon)
Plus the two mechanics that are easiest to lose: null reaches schema
validation only for keys WITHOUT a chart default (which is why the helper
and the ["object","null"] types each cover a case the other cannot), and
schemas must be validated against real bundle values - that step caught a
draft of mine that would have broken three live paperless releases.
CLAUDE.md: the new-chart checklist now names the schema and the
adaptation step, since the copied file is chart-specific and wrong until
it is adapted.
freesailarr is not covered: it is not on main yet (#59).
The deployment renders SMTP_REJECT_UNAUTHORIZED from
rallly.smtp.rejectUnauthorized, but values.yaml never carried the key. With
SMTP enabled the variable therefore reached the app as an empty string --
a certificate check nobody had configured either way.
It now defaults to true, so the mail server's certificate is verified unless
the operator switches the check off deliberately. values.yaml explains when
that is needed (a mail server with a self-signed certificate), because the
symptom otherwise points at the mail server rather than at this value.
The env var is not rendered with "| default true": an explicit false is a
zero value and default would swallow it, silently re-enabling the check the
operator just switched off. A nil falls back to true instead, so the variable
can no longer reach the app empty. The schema now rejects strings.
Operationally inert: the rallly fleet bundle and the deployed release both
have smtp.enabled: false, so the variable is not rendered at all -- the
render with SMTP disabled is byte-identical to before.
Major, because the runtime behaviour of mail sending changes.
Fixes#109
The centrepiece is the secret inventory: the four OnePasswordItem CRs carry
only item paths, while the fields each item must contain are decided in the
deployment. The notes list them per item — including the eight OIDC fields
nobody would guess — because a missing field does not fail the install, it
starts the container with an empty variable and misbehaves later.
The warnings are the ones this chart earns:
- Sign-in is OIDC-only. The chart sets OIDC_DISABLE_LOCAL_AUTH, so a wrong
OIDC item locks everyone out with no local account to fall back on.
- A wrong ingress.domain never becomes Ready: the server answers 403 to any
unknown Host header, the probes send that domain, and the log shows plain
403s rather than anything resembling a configuration error.
- The first 2.x start rebuilds database indexes and may take minutes, so the
notes print the actual startup budget and say a slow boot is not a hang.
- The presence registry is keyed by pod hostname, so replicas do not scale.
The startup budget is read through the null-safe probe helper, and the guacd
sidecar and scaled-down states are reported only when they apply. Refs #43.
Three changes, across both workloads (Synapse StatefulSet and delegation
nginx Deployment).
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, including the whole matrix.delegation block
with its own contexts, probes and resources.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged.
The domain checkpoint found a second reader: the delegation nginx
serves ingress.domain in its /.well-known/matrix/{server,client}
endpoints, and read it without a guard. Gating alone would therefore
have published '{"m.server": ":443"}' and base_url "https://" - a
federation-breaking answer that renders and starts cleanly. Both reads
are now required(), so that case fails loudly. Only clusterIssuer
actually becomes unnecessary when the Ingress is off.
3. Null-safety for hardening, probes and resources (#99) for both
workloads. The rebuilt probes keep each workload's own endpoint:
Synapse /health, delegation /.well-known/matrix/server - the endpoint
that workload exists to serve - including its shorter 3s timeout. The
delegation pod context keeps having no fsGroup, because it mounts no
volume that needs one.
The nginx checksum/config annotation from #82 is untouched.
storage stays deliberately not null-safe: an erased block yields an
invalid PVC, which is the loud class #99 excludes.
Rendering is byte-identical to 6.0.0, both with the CI values (which
enable delegation) and with the production bundle values.
samba.globalConfig has been part of values.yaml since the chart's first
commit but is read by no template. Setting it never had an effect.
Rather than implement it, the key is removed and the strict schema now
rejects it: additionalProperties is already false on the samba object, so
dropping the property turns a silently ignored key into a render-time
error.
Operationally inert: neither the cluster-smb fleet bundle nor the deployed
release's user-supplied values set the key -- it only ever appeared as the
chart's own null default.
Major, because a published value disappears and is now rejected.
Fixes#117
Largest values surface of the programme, and the first chart where the
null-safety covers two workloads.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, including files.barcodes, ocr (with enums
for the 3.x modes), scripts, tikaGotenberg, the oidc provider block
and the SMB CronJob.
2. Null-safety for hardening, probes and resources (#99), for the server
AND the SMB consume-mover CronJob. It reuses the defaultedDict helper
the barcodes block already introduced (#61) instead of adding a second
mechanism - one merge helper, now with more callers.
The server's pod context is consumed twice: as the pod securityContext
and by the /run-ownership init container, which chowns /run to
runAsUser:runAsGroup because s6-overlay refuses to start unless /run is
owned by the runtime uid. Both reads now go through the same helper, so
the chown cannot disagree with the context it has to match. Erasing
that block used to abort rendering with a nil-pointer error; it now
falls back to the defaults like every other chart.
The CronJob has no probes (documented exception), so only its two
contexts and resources are covered.
files.storage stays deliberately not null-safe: an erased value yields an
invalid PVC, which is the loud class #99 excludes.
Rendering is byte-identical to 11.0.0, both with the CI values (which
include the #61 regression guard) and with the production paperless-jk
bundle values.
No ingress gate: this chart has no Ingress at all (clients reach it via a
NodePort), and ingress.domain appears neither in its templates nor in its
values.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, including the entries of the mappings list,
where domain and internalUrl are required.
2. Null-safety for hardening, probes and resources (#99). Two things a
rebuilt default probe must not lose, both verified:
- the API port is addressed by NAME ("api-port"), so the probe keeps
working when server.apiPort is overridden.
- mc-router still has no /health endpoint in 1.46.4, so GET /routes is
the health signal, and the "Accept: application/json" header belongs
to that request.
The pod context keeps pinning uid/gid 10000 even though the image
declares USER 65532 since 1.46.0, so the runtime identity does not
silently change with the base image.
mappings stays deliberately not null-safe: the chart fails loudly on a
missing or empty routing table, which is the loud class #99 excludes - a
router without routes is not operable and has no sensible default.
Rendering with normal values is byte-identical to 2.0.0.
No ingress gate change: this chart already honours ingress.enabled, and
its ingress block keeps the upstream-style host/tls lists that the README
documents as an exception. The schema models that shape as it is instead
of pushing the repo's domain/clusterIssuer pair onto it, and the list
entries stay open because they go verbatim into the Ingress spec.
The domain checkpoint ran over values.yaml and templates and came back
empty: ingress.domain does not exist in this chart at all.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level. Pod-spec passthrough (volumes, volumeMounts,
nodeSelector, tolerations, affinity, ingress hosts/tls) stays open.
2. Null-safety for hardening, probes and resources (#99).
This chart's hardening is a documented deviation and the fallbacks
reproduce it exactly: the pod context is deliberately EMPTY, because
the official image must start as root (s6-overlay does its setup as
uid 0 and the image has no non-root user), and capabilities.add keeps
NET_RAW, without which device discovery (DHCP watcher, ping/arp
integrations) logs "Operation not permitted".
core.storage stays deliberately not null-safe: an erased block yields an
invalid PVC, which is the loud class #99 excludes.
The #82 limitation around the 1Password-backed config Secret is
untouched: Helm never sees the content, so it cannot be hashed, and the
values.yaml note about the manual rollout restart stays as it is.
Rendering with normal values is byte-identical to 5.0.0.
No ingress gate: this chart has no Ingress at all (SMB and NetBIOS are
exposed via NodePort), and ingress.domain appears neither in its
templates nor in its values.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, including the entries of the samba.shares
list.
2. Null-safety for hardening, probes and resources (#99).
This chart's hardening is a documented deviation forced by the
ghcr.io/dockur/samba image, and the fallbacks reproduce it exactly
instead of restoring the repo standard: no runAs* values (the
entrypoint creates Unix users and smbd impersonates the share user per
session, both requiring a root start), readOnlyRootFilesystem stays
false (the entrypoint writes /etc/passwd, /etc/group, the healthcheck
symlink and the Samba TDBs), and capabilities.add keeps the six
entries a multi-user root file server needs. Restoring the standard
here would stop the file server from working.
The probes target the SMB TCP port directly, because SMB is not HTTP.
The users.conf / checksum-config limitation from #82 is untouched: Helm
never sees the Secret content, so it cannot be hashed, and the comment in
values.yaml documenting the manual rollout restart stays as it is.
Rendering with normal values is byte-identical to 5.0.0.
Three changes, all about values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged.
The domain checkpoint from rallly ran over values.yaml and templates
and came back empty here: ingress.domain is read nowhere but in the
Ingress template. Unlike rallly, zipline, voucher-vault and outline,
this gate therefore frees both domain and clusterIssuer, and no extra
required() is needed.
3. Null-safety for hardening, probes and resources (#99).
This chart's hardening is a documented deviation from the repo
standard, and the fallbacks reproduce it exactly instead of restoring
the standard: no runAs* values (s6-overlay boots as root and drops to
PUID/PGID 1000), readOnlyRootFilesystem stays false (read-only mode
disables the PUID/PGID remapping, silently moving the runtime uid from
1000 to 911 and breaking existing volume data), and capabilities.add
keeps its six entries that the s6 init and supervision need. A
"cleaned up" standard default here would not be tidier, it would be an
outage.
cwa.storage stays deliberately not null-safe: an erased value yields an
invalid PVC, which is the loud class #99 excludes.
Rendering with normal values is byte-identical to 4.0.0.
No ingress gate: this chart has no Ingress at all (game and messaging
ports are exposed via NodePort), and ingress.domain appears neither in
its templates nor in its values.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level. Like teamspeak-server, this chart keeps env,
probes and securityContext at the TOP level, and the schema mirrors
that shape.
2. Null-safety for hardening, probes and resources (#99). What a rebuilt
default must not lose here:
- liveness and startup run the image's own healthcheck script via
exec. It queries the server's HTTPS API on SERVERGAMEPORT, so it
survives a port override, which a tcpSocket default could not.
- readiness keeps the named "api" port.
- the resources default keeps limitFactor 2 rather than the repo-wide
3, which is what holds the memory limit at the published 8Gi.
- the pod context keeps fsGroupChangePolicy OnRootMismatch, which is
what avoids a recursive chown of multi-GB game files on every start.
server.storage stays deliberately not null-safe: an erased value yields
an invalid PVC, which is the loud class #99 excludes.
This chart is excluded from the CI install-test, so the local proof is
the only one. Rendering is byte-identical to 4.0.0 with default values
and with the production bundle values, and the rendered manifests were
additionally validated by the cluster's API server via a server-side
dry-run.
No ingress gate: this chart has no Ingress at all (voice/file-transfer
are exposed via NodePort), and ingress.domain appears neither in its
templates nor in its values.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level. Note that this chart keeps replicas,
resources, probes and securityContext at the TOP level rather than
under a chart-named key, so the schema mirrors that shape.
2. Null-safety for hardening, probes and resources (#99). The rebuilt
probes keep the "file-transfer" port name: the voice service is UDP
and cannot be probed, so that TCP port is the only thing a probe can
target - a default probe without it would leave the workload with no
working probe at all.
The container defaults keep capabilities.add as an empty list, exactly
as values.yaml has it, so an erased block restores today's rendering
byte for byte rather than a cleaned-up variant.
storage stays deliberately not null-safe: an erased block yields an
invalid PVC, which is the loud class #99 excludes.
Rendering with normal values is byte-identical to 4.0.0.
No ingress gate: this chart already gates its Ingress correctly. Two
changes plus one guard the existing gate turned out to need.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level.
2. Null-safety for hardening, probes and resources (#99). All three
probes keep /_health when rebuilt: it is Outline's only health
endpoint, and "/" returns 500 as well when the database is down, so
there is no dependency-free path to fall back to.
3. ingress.domain is required() where the StatefulSet reads it. It feeds
the URL env var - Outline's public URL for generated links and the
OIDC redirect URI - and did so without a guard. With the existing gate
and no domain it rendered "https://", breaking logins silently. That
hole predates this change; it now fails loudly.
outline.storage stays deliberately not null-safe: an erased block yields
an invalid PVC, which is the loud class #99 excludes.
Apart from an added comment, the rendered manifest is unchanged.
No ingress gate: this chart already gates its Ingress correctly. Two
changes plus one guard that the existing gate turned out to need.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level. Lists that go verbatim into the pod spec
(ports, storage.volumes, storage.volumeMounts) stay open.
2. Null-safety for hardening, probes and resources (#99). Two specifics
of this chart:
- The probes were wrapped in "if" guards, so an erased probe block did
not render "livenessProbe: null" - it removed the probe entirely and
silently. The guards are gone; an empty block now means chart
defaults, so the workload keeps its probes.
- The rebuilt probes keep the Host: 127.0.0.1 header. Django's
ALLOWED_HOSTS only accepts 127.0.0.1 and the configured DOMAIN, so a
probe without it would get 400 and the pod would never be ready.
3. ingress.domain is required() where it is read. The dependency lives in
values.yaml, not in a template: the DOMAIN env entry is a tpl string
feeding Django's ALLOWED_HOSTS. With the existing gate and no domain
the app rendered DOMAIN: "" and answered 400 to every real request -
silently, and already before this change. It now fails loudly.
Apart from an added comment, the rendered manifest is unchanged.
Three changes, all about values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged.
As in rallly, ingress.domain is not a pure Ingress value: the
StatefulSet also feeds it to CORE_DEFAULT_DOMAIN, the app's default
domain for generated share links, and did so without required(). The
guarantee only came from the ungated Ingress template, so the gate
would have handed out unusable links silently. That read is now
required() as well; only clusterIssuer becomes unnecessary.
3. Null-safety for hardening, probes and resources (#99): an erased block
fell back to "securityContext: null" (unhardened), a vanished probe or
a container without resource accounting. The rebuilt liveness probe
keeps "/" rather than /api/healthcheck, so a database outage still does
not restart the pod.
config stays deliberately not null-safe: storage and storageClass are
required(), which puts an erased block in the loud class #99 excludes.
Apart from an added comment, the rendered manifest is unchanged.
Three changes, all about values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged.
ingress.domain is NOT a pure Ingress value here - it is also the app's
public base URL (NEXT_PUBLIC_BASE_URL). Gating alone would therefore
have introduced a new silent failure: with the Ingress switched off and
no domain, the deployment rendered value: "https://" and every
generated link would be broken. The deployment's read of the value is
now required(), so that case fails loudly. Only clusterIssuer actually
becomes unnecessary when the Ingress is off.
3. Null-safety for hardening, probes and resources (#99): an erased block
fell back to "securityContext: null" (unhardened), a vanished probe or
a container without resource accounting. Restoring the pod context
matters especially here, because its fsGroup is what makes the Next.js
cache emptyDir group-writable for the container.
rallly.cache is deliberately NOT null-safe: cache.path is required(), so
an erased block fails loudly and belongs to the loud class #99 excludes.
Apart from an added comment, the rendered manifest is unchanged.
Records the reasoning inline, matching the comment the gotenberg chart
carries, so the next edit does not quietly switch back to the raw helper and
drop the paragraph whenever a resources: block has been erased.
Tika has no Ingress, so the notes lead with the cluster-internal URL, the
Service-port-80 to container-port-9998 mismatch a consumer has to get right,
and /parsers as the direct answer to "why did this file come back empty".
Two warnings come from measuring the running container rather than from
reading the values file:
- The image tag has to keep its "-full" suffix. That variant is where
Tesseract 5.5.0 and the extra parsers live; the plain image carries no
tesseract binary at all, so dropping the suffix does not fail loudly, it
just stops OCR and returns empty text for scans.
- The JVM never sees the container limit. It starts without -Xmx and derives
its heap from the limit at MaxRAMPercentage=25, so the number worth sizing
against is a quarter of it.
The heap figure is computed from the effective limit through the chart's own
null-safe effectiveResources helper, so an erased resources: block still
prints the defaults the container actually receives instead of dropping the
paragraph. Refs #43.
Retrofit of #99 for a chart that already carries a values.schema.json,
plus the schema type change that goes with it.
An override written without children is YAML null. Where the chart
defines a default, Helm's coalescing deletes the default before schema
validation runs, so the schema never sees the null and cannot reject it:
the container rendered "securityContext: null" - unhardened, healthy,
silent. Where the chart defines no default (resources.limits), the null
survives into validation and a strict "object" type aborted the render.
The defaultedDict helper from #96 handles the first case; widening the
types of exactly these blocks to ["object", "null"] handles the second.
All other keys stay strict, additionalProperties: false is untouched.
The probes address the container port by name, so a rebuilt default probe
needs no further context.
Rendering with normal values is byte-identical to 5.0.0.
Retrofit of #99 for a chart that already carries a values.schema.json,
plus the schema type change that goes with it.
An override written without children is YAML null. Where the chart
defines a default, Helm's coalescing deletes the default before schema
validation runs, so the schema never sees the null and cannot reject it:
the container rendered "securityContext: null" - unhardened, healthy,
silent. Where the chart defines no default (resources.limits), the null
survives into validation and a strict "object" type aborted the render.
The defaultedDict helper from #96 handles the first case; widening the
types of exactly these blocks to ["object", "null"] handles the second.
All other keys stay strict, additionalProperties: false is untouched.
The probes address the container port by name, so a rebuilt default probe
needs no further context.
Rendering with normal values is byte-identical to 8.0.0.
Gotenberg has no Ingress, so the notes lead with the cluster-internal URL and
point out that the Service listens on 80 while the container listens on 3000
— the mismatch a consumer such as paperless-ngx has to get right — plus the
port-forward command for reaching it by hand.
Three findings from measuring the running chart went in as warnings:
- The chart passes no command-line flags, so Gotenberg's basic auth, OIDC,
SSRF guards and request timeout cannot be enabled through values at all.
- Memory, not disk, is the first limit to hit: at the default limit a large
document gets the container OOM-killed, the caller sees the connection
dropped rather than an HTTP error, and the notes give the exact kubectl
command that prints OOMKilled.
- Temp space is an emptyDir counted against ephemeral-storage, where running
out looks different — the pod is evicted and replaced, not restarted.
Both limits are read back through the chart's own resources helper, so the
printed figures follow limitFactor and any override instead of being
hardcoded. Refs #43.
Three changes, all about values that do not do what they promise:
1. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }}. The key already existed in
values.yaml with default true but was never read, so switching it off
did nothing. Both required() calls for domain and clusterIssuer live
inside the Ingress file, so gating also removes the contradiction that
one had to supply a domain and issuer in order to turn off an Ingress
one does not want.
2. Null-safety for hardening, probes and resources (#99): an override
written without children is YAML null and erased the whole default
sub-tree, rendering "securityContext: null" - an unhardened container
that starts and reports healthy.
3. values.schema.json types (#68 + #99): the blocks covered by the
null-safety accept null. This is load-bearing only for keys that have
no chart default (e.g. resources.limits): there Helm has nothing to
delete, so the null survives into schema validation and a strict
"object" type rejected it outright.
Rendering with normal values is byte-identical to 7.0.0.
Prints what an operator would otherwise have to look up after installing:
the rendered Ingress URL, the cert-manager Certificate to watch while the
browser still warns, and the fact that the chart needs no secrets and no
volumes.
Adds three warnings that the values alone do not tell: CyberChef ships no
authentication, so everything that reaches the URL can use it; the app is
static and holds no server-side state, so upgrades and rollbacks need no
migration; and cyberchef.env reaches nginx but never the served bundle.
Scaled-down installations are called out conditionally, naming whichever of
scaleDown / cyberchef.replicas caused it, via the chart's own replicas
helper so the notice cannot drift from the rendered Deployment.
The URL is only ever rendered from .Values.ingress.domain, so no domain is
stored in the chart. Refs #43.
Third change of the same class (#99): an override written without
children is YAML null and replaced the whole default sub-tree, rendering
"securityContext: null" (unhardened container), a vanished probe or a
container without resource accounting - silently, while the workload
reports healthy.
The defaultedDict helper from #96 is adopted for both workloads, so an
empty block means "chart defaults apply" while an explicitly set value
still wins, including false and 0.
The server probes rebuild their Host header from ingress.domain via the
passed-in root context, because the 2.x server rejects requests whose
Host is neither loopback nor a CORS_ORIGIN host.
The schema types allow null for exactly these blocks, so schema and
helper agree instead of the schema rejecting what the helper absorbs.
Rendering with normal values is byte-identical to the previous version,
with and without the guacd sidecar.
Two changes, both about values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored.
2. Null-safety for hardening, probes and resources (#99): an override
written without children is YAML null and replaced the whole default
sub-tree, rendering "securityContext: null" (unhardened container), a
vanished probe or a container without resource accounting - silently.
The defaultedDict helper from #96 is adopted so an empty block means
"chart defaults apply", while an explicitly set value still wins,
including false and 0.
The schema types allow null for exactly these blocks, so the two changes
agree instead of the schema rejecting what the helper is meant to absorb.
No ingress gate here: this chart already gates its Ingress correctly.
Rendering with normal values is byte-identical to the previous version.
Major bump: a schema can break existing deployments that carry dead keys.
Two changes of the same class - values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored. Objects passed
verbatim into the pod spec (probes, securityContext, global) stay open.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged. Without the gate the
value did not exist at all and could not switch the Ingress off.
Major bump: a schema can break existing deployments that carry dead keys.
The chart mounted no volumes at all while running with
readOnlyRootFilesystem: true, so every Next.js write to
/app/apps/web/.next/cache failed. The image optimizer's failure even
surfaced as an unhandledRejection, so this was more than log noise.
The cache path is now a writable emptyDir; path and an optional
sizeLimit are configurable under rallly.cache. The hardening is
untouched — the pod's existing fsGroup (1000) is what makes the mounted
volume writable for uid 20000.
Verified in a throwaway k3d cluster which paths the app actually writes:
with a fully writable root filesystem and the cache mounted, the only
path the container touches is the cache directory itself. /tmp, $HOME
(=/app) and the rest of the root filesystem stay untouched, so no second
mount is needed.
Also drops the vestigial "capabilities.add: []": Trivy's AVD-KSV-0022 for
rallly (#84) comes from the older chart version deployed in the cluster,
which rendered a null list entry under add:. Reproduced with trivy config
against both renderings; the app needs no capabilities.
Major bump: runtime behavior changes, a volume is added.
Fixes#60
A "barcodes:" key left without children (e.g. after deleting the last
remaining sub-key, PAPERLESS_CONSUMER_BARCODE_SCANNER, which paperless-ngx
3.0 removed) is YAML null and replaced the whole default sub-tree on merge.
Rendering then failed on the nil pointer, so the release simply stopped
updating.
An empty or null block now means "the chart defaults apply". The merge runs
through a new paperless-ngx.defaultedDict helper: nulls never delete, nested
maps merge recursively, and explicitly set values win - including false and 0,
which "default" and "mergeOverwrite" would swallow. A scalar where the
defaults define a map is rejected with the values path in the message.
Major bump: the meaning of a values override changes.
Fixes#61
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
Home Assistant reads configuration.yaml, http-config.yaml and
recorder-config.yaml from a 1Password-backed Secret, mounted with subPath.
Two different gaps hide behind that, and only one of them can be closed.
Repointing secrets.configSecretRef at a different vault item used to leave the
running pod on the old configuration. That is now covered: the pod template
carries checksum/secret-ref over the rendered OnePasswordItem. The annotation
is named apart from checksum/config on purpose - it only promises that the
config source changed, not the config itself - matching the pattern
minecraft-server introduced.
Changing the CONTENT of the item in the vault still does not restart anything,
and cannot: Helm never sees the content, so there is nothing to hash. The
operator's own auto-restart annotation is no way out either - onepassword-
operator 1.12.0 enumerates exactly one workload type in its secret-update
handler (appsv1.DeploymentList) and this workload is a StatefulSet, so the
annotation would be a silent no-op advertising a guarantee it cannot keep. It
is deliberately not set. values.yaml states the limitation and the manual
rollout restart it requires; the README guideline records the operator finding,
the annotation precedence trap, and the checksum/secret-ref pattern so neither
is rediscovered the hard way.
Major bump: runtime behavior changes - changing the secret reference now costs
a restart. For this release the effect is preventive, since it currently runs
at zero replicas via scaleDown.
Last of the three publishes that carry the checksum annotations from
3.0.0+up2026.8.2.java8, leaving main on the line of the only running server.
Same chart content as the java8 and java17 publishes, only the published Java
line changes: appVersion moves to the dated tag 2026.8.2-java21 and the
minecraft.version default moves to 1.21.1, the version ftb-skies-2 actually
runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need
Java 21).
Against the state before this series (2.0.0+up2026.8.2.java21) the only
replaced line in Chart.yaml and values.yaml is the chart version; appVersion
and the minecraft.version default are byte-identical, everything else is
additive.
Refs #82.
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
Second of the three publishes that carry the checksum annotations from
3.0.0+up2026.8.2.java8. Same chart content, only the published Java line
changes: appVersion moves to the dated tag 2026.8.2-java17 and the
minecraft.version default moves to 1.20.1, the line's matching Minecraft
version (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need
Java 21).
Refs #82.
smb.conf is rendered from samba.shares and mounted with subPath, so adding,
renaming or re-scoping a share rewrote the ConfigMap while the running smbd
kept its old share list: the pod template was unchanged, nothing restarted,
and the kubelet does not refresh subPath mounts. The share simply did not
exist for clients while the release looked healthy - the failure mode from #82.
The pod template now carries checksum/config over the rendered ConfigMap.
users.conf cannot be covered the same way: it comes from a 1Password-backed
Secret whose content Helm never sees, and the operator's auto-restart only
handles Deployments, not this StatefulSet. values.yaml now documents that
limitation and the manual rollout restart it requires.
Major bump: runtime behavior changes - a share change now costs a restart of
the samba pod, which drops open SMB sessions (share data lives on PVCs and is
unaffected).
The StatefulSet now carries two annotations over its two configuration
sources, so a change to either produces a new pod template and a controlled
restart:
checksum/config the rendered ConfigMap (init.sh) - complete, Helm sees
the whole content
checksum/secret-ref the rendered OnePasswordItem - the op:// item path only,
because the Secret's content is materialized by the
operator and is unknown to Helm at render time
Two separate annotations rather than one combined hash: they carry different
guarantees, and a single number would blur "covers everything" and "covers the
path but not the content" into one value that nobody can interpret in a
kubectl describe.
The operator's own operator.1password.io/auto-restart is deliberately NOT set:
it restarts Deployments only. Verified in the operator source (main, 9c3b1b9):
restartWorkloadsWithUpdatedSecrets lists nothing but appsv1.DeploymentList and
getPodTemplate has a single case for *appsv1.Deployment. On this StatefulSet
the annotation would be inert while suggesting the opposite, so the remaining
gap - a rotated value inside the vault item - is documented in values.yaml
instead.
First of the three stage-3-style publishes, so the java8 line goes first and
main ends up on java21. Only the published Java line differs between them:
appVersion 2026.8.2-java8 and the matching minecraft.version default 1.12.2.
Major bump: runtime behaviour changes. A configuration change now costs a full
server restart - 124 s measured for ftb-skies on Longhorn.
Refs #82.
The delegation nginx serves the .well-known documents from an nginx.conf that
is rendered from ingress.domain and mounted with subPath. Changing the domain
rewrote the ConfigMap but left the running pod untouched: the pod template was
unchanged, so nothing rolled, and the kubelet never refreshes a subPath mount.
The pod kept serving the old delegation while looking perfectly healthy - the
failure mode from #82.
The pod template now carries checksum/config over the rendered delegation
ConfigMap, so a changed nginx.conf rolls the deployment.
Also documents the limit that remains for homeserver.yaml: it comes from a
1Password-backed Secret, whose content Helm never sees, and the operator's own
auto-restart only ever covers Deployments - not this StatefulSet. That case
needs a manual rollout restart, which the values.yaml now says out loud.
Major bump: runtime behavior changes - a delegation config change now costs a
restart of the nginx pod (a few seconds, no persistent state).
The deployment now carries a checksum/config annotation over the rendered
ConfigMap, so a changed routing table produces a new pod template and a
controlled rollout.
Without it a mapping change was inert but looked successful: the file is
mounted with subPath (kubelet never refreshes those in a running container)
and mc-router reads ROUTES_CONFIG only at startup. That combination caused the
minecraft-server stage-3 outage - the ConfigMap pointed at the renamed
services, the running router kept proxying to the old ones, and the pod stayed
Ready throughout.
Major bump: runtime behaviour changes. A mapping change now costs a router
restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which
clients cannot connect. That restart is what makes the change take effect at
all.
Refs #82.
A changed ConfigMap did not restart any pod in this repo: no chart carries
a checksum/config annotation, so the pod template stays identical and the
running container keeps its old config. With subPath mounts (the usual form
here) the kubelet never refreshes the file either, so the change is silently
ineffective - see #82, where this caused a real outage while every bundle was
green and the pod Ready.
template-chart is the reference implementation, so it gets the annotation on
both pod templates (Deployment and StatefulSet), and the README style guide
gets a new binding section 9 covering the rule, the reason, and the limit for
1Password-backed Secrets.
Major bump: runtime behavior changes - a config change now costs a restart.
Last of the three stage-3 publishes, leaving main on the line of the only
running server. Same chart content as 2.0.0+up2026.8.2.java8 and .java17, only
the published Java line changes: appVersion moves to the dated tag
2026.8.2-java21 and the minecraft.version default moves to 1.21.1, the version
ftb-skies-2 actually runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17,
1.20.5+ need Java 21).
Second of the three stage-3 publishes. Same chart content as
2.0.0+up2026.8.2.java8, only the published Java line changes: appVersion moves
to the dated tag 2026.8.2-java17 and the minecraft.version default moves to
1.20.1, which is the line's matching Minecraft version (Java 8 runs up to
1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21).
Stage 3 of the Fleet migration. Two changes, both breaking, hence the major
bump from 1.0.0 to 2.0.0.
Dated image tags: appVersion moves from the rolling line tag "java8" to the
immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt
continuously, so a pod restart could pull a different image than the previous
start without that being recorded anywhere. 2026.8.2 is the newest upstream
release (published 2026-08-23) and exists for all three Java lines.
Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST)
in both positions, so minecraft.whitelist.enabled: false actually switches the
whitelist off. Previously the chart only emitted whitelist variables while
enabled was true and had no way to express "off" - and because server.properties
lives on the PVC, a release that had once written white-list=true kept it
forever. players stays guarded by enabled, since a non-empty WHITELIST enables
the whitelist in the image regardless of ENABLE_WHITELIST.
The default flips from enabled: true to enabled: false. Under the corrected
semantics the old default (enabled with an empty player list) would mean a
server nobody can join; false matches both the image and vanilla Minecraft.
PR C of three, and the last of the stage-2 sequence. Same chart as
1.0.0+upjava8 and 1.0.0+upjava17, published for the third Java line, so
main comes to rest on the line of the only server that is actually
running.
minecraft.version moves with it (1.20.1 -> 1.21.1): a Minecraft version
only runs on a matching JVM, and 1.20.5+ needs Java 21. This default now
equals what ftb-skies-2 sets in its own values file, so the install-test
boots the production version rather than an arbitrary Java-21-capable one.
The CI values deliberately do not override minecraft.version, so this
default is what the install-test exercises.
PR B of three. Same chart as 1.0.0+upjava8, published for the second Java
line: appVersion selects the image tag, so the JVM is fixed per published
chart version.
minecraft.version moves with it (1.12.2 -> 1.20.1), because a Minecraft
version only runs on a matching JVM: Java 8 goes up to 1.16.5, 1.18-1.20.4
need Java 17. Since 1.0.0 this default is no longer overridden in the CI
values, so the install-test boots exactly this version and a mismatched
default would fail CI instead of passing on a CI-only override.
Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime
behaviour changes (probes, hardening) and the values interface breaks
(resource renames, strict schema).
Two real bugs first:
- The container declared port 35565 while the Service targeted 25565. It
only worked because targetPort was numeric. Both are now server.port
(25565) and the Service targets the named port.
- The download-serverpack init container was guarded by the map
.Values.curseforgeServerpack instead of .enabled, so it rendered for
every release and silently no-opped on an empty wget URL.
Conventions:
- Resources renamed to <release>-<chart>-<kind>, templates to
<app>.<kind>.yaml. The PVC deliberately keeps its historical name -
renaming it would provision a new, empty volume and orphan the worlds.
- Probes (liveness/readiness/startup) via the image's own mc-health, so
Ready means the server answers a server-list ping. Startup budget 20 min.
- Hardened, values-configurable security contexts: non-root uid 1000,
read-only root filesystem with an emptyDir at /tmp, all caps dropped.
- Resources from values with the limitFactor helper; an unset memory
request is derived from the JVM heap so the two cannot drift apart.
- Additive env block rendered through tpl, pinned init image, storage
class as a value, RCON wiring only when actually enabled.
- curseforge/ftb/curseforgeServerpack are now mutually exclusive.
- minecraft.version is pinned to the Java line instead of LATEST.
- The mc-router auto-discovery annotation is gone; the service type it
implicitly switched is now the explicit value server.service.type.
Schema pilot (#68): values.schema.json with additionalProperties false on
every chart-owned level, rejecting all three known dead keys.
Last of the three Java-line publishes; main comes to rest on java21, the line
of the only running server, and the registry holds all three tags.
Only the two version lines in Chart.yaml change. Because the source chart in
cluster-config is itself on java21, this final state renders byte-identical to
it for mc-ftb-skies-2 with its real values file - the published end state is
exactly what cluster-config runs today.
The CI install values move along with the appVersion, as in the java17 PR:
the JVM is fixed per published chart version and no single Minecraft version
boots on all three lines. Since the chart has no probes, a version the JVM
cannot load would crash after the rollout returned and still leave a green
install-test behind. minecraft.version therefore moves 1.20.1 -> 1.21.1, which
is also what ftb-skies-2 sets in its real values file, so CI exercises the
production version. ci/ is outside the chart directory and is neither packaged
nor published.
Second of the three Java-line publishes. Only the two version lines in
Chart.yaml change; the rendered output differs from the published java8 chart
in exactly one line, the image tag.
The CI install values move along with the appVersion: the image tag is the
Java line, so the JVM is fixed per published chart version and the Minecraft
version has to match it (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17).
No single Minecraft version boots on all three lines, and because the chart
has no probes a version the JVM cannot load would still leave a green
install-test behind. minecraft.version therefore moves 1.12.2 -> 1.20.1.
ci/ is outside the chart directory and is neither packaged nor published.
Imports the chart from cluster-config functionally unchanged, wires it into
the publish/validate/install-test pipelines and publishes it as the first of
three Java lines (0.4.0+upjava8).
The only deviation from the source chart is the chart-global scaleDown flag
plus a server.replicas value, following the satisfactory pattern: two of the
three servers stand at 0 replicas in the cluster, which the chart could not
express, and Fleet would otherwise start them on reconcile. The default
(scaleDown: false) still renders replicas: 1, so the rendering of the running
server is unchanged - verified byte-identical against the three real values
files for all three Java lines.
Known deficiencies (hardening, probes, naming scheme, hardcoded values,
missing icon, the misleading mc-router auto-discovery annotations) are left
untouched on purpose and are scheduled for stage 2.
Chart 1.0.0+up1.25.1 -> 1.0.1+up1.46.4 (patch: plain app-version update,
no values-schema and no chart-side behavior change). appVersion is the
image tag; itzg/mc-router publishes Docker tags without the "v" prefix
that the git tags carry since 1.35.0, so "1.46.4" is correct.
Verified against the upstream sources at v1.46.4 rather than the release
titles alone:
- --api-binding and --port are unchanged, so the chart's args still
apply.
- The ROUTES_CONFIG env var and the routes config schema
({"default-server": ..., "mappings": {addr: "host:port"}}) are
byte-for-byte identical to 1.25.1. Confirmed in a cluster: both
mappings, including a per-mapping port override, are loaded.
- There is still no /health endpoint, so the probes keep using
GET /routes. The "Accept: application/json" matcher that made the
header mandatory in 1.25.1 was dropped in 1.32.2; the header is kept
because it is harmless and correct.
- The image moved from scratch to cgr.dev/chainguard/static in 1.46.0
and now declares USER 65532. The chart keeps pinning uid/gid 10000, so
the runtime identity does not change.
Only the values comments that the update made inaccurate are touched; no
value, default or template changes. The comments now also record that
every unmodelled mc-router flag is reachable through server.env, which
is why the new 1.26-1.46 options need no new chart values.
Stage 2 of the Fleet migration for minecraft-router: bring the chart up to the
repo style guidelines. Chart 0.1.1+up1.25.1 -> 1.0.0+up1.25.1 (major: resource
renames, mappings becomes required, probes and security hardening change the
runtime behavior; appVersion unchanged).
- Resources renamed to {{ .Release.Name }}-{{ .Chart.Name }}-<kind>, templates
to <chart>.<kind>.yaml; the deployment label now matches its own selector.
- mappings is required and must not be empty (the old default rendered
"<nil>": "<nil>:25565"); every entry needs domain and internalUrl.
- Ports come from values: server.port (router listen port, also passed as
--port), server.backendPort (default backend port, overridable per mapping),
server.apiPort (--api-binding, used by the probes). Defaults stay 25565 /
25565 / 8080, server.outwardPort keeps its 25565 default and comment.
- _helpers.tpl added (resources/limitFactor and replicas/scaleDown helpers),
resources come from values, no CPU limit.
- replicas value plus the chart-global scaleDown flag.
- Additive env block rendered through tpl (value / secretKeyRef /
configMapKeyRef).
- Values-configurable securityContext.pod / .container with hardened defaults:
non-root uid/gid 10000, readOnlyRootFilesystem, no privilege escalation, all
capabilities dropped.
- Liveness, readiness and startup probes on the mc-router API: GET /routes with
an "Accept: application/json" header (the API router matches on that header
and answers 404 without it).
- icon added to Chart.yaml.
- CI fixture supplies mappings; README chart table entry updated.
Takes the existing mc-router chart over from cluster-config as-is so the
deployment can move to Fleet without any change to the rolled-out state.
Convention alignment follows in stage 2, the app update in stage 3.
The only deviation from "unchanged": Chart.yaml carried name:
minecraft-server (copy-paste from the sister chart). The publish job pushes
by the glob <directory>-*.tgz while helm package names the archive after the
Chart.yaml name, so without this correction the push finds no file.
Version 0.1.1+up1.25.1 - chart semver stays at 0.1.1, the +up suffix is repo
policy and does not affect rendering.
Also wires up CI: publish workflow, change-app-version choice list,
install-test values (CI-only node-port override, since 25565 is outside the
k3d default range) and the README chart table.
README.md gains a comprehensive 'Chart style guidelines' section - the
binding end state of the conventions overhaul (#32, batches 0-4) for all
current and future charts: naming (incl. the PVC-name exception and the
StatefulSet migration pattern), versioning scheme and semver rules,
image pinning, the ingress standard (domain + clusterIssuer strictly
required without defaults, className default nginx, annotations merge,
TLS secret name, homeassistant exception), security hardening with
mandatory documentation of deviations, probes, the auto-limits scheme,
the secrets.<name>SecretRef convention, tpl-rendered env blocks,
scaling, and the icon/lint/CI-fixture/no-dependencies rules.
The Versioning section now points there and documents that app-version
updates go through PRs. CLAUDE.md's conventions section is aligned as a
compact summary referencing the README guide.
Per the maintainer decision (option a: ingress.clusterIssuer strictly
required in ALL charts) the two remaining defaults are removed as well:
- cyberchef: drop the letsencrypt default; bump raised from minor to
major (6.0.0+up11.4.0) as this is a breaking values change.
- urlaubsverwaltung: drop the letsencrypt-issuer default; major bump
to 6.0.0+up6.7.0.
- CI test-values for both charts now set clusterIssuer explicitly.
A repo-wide grep confirms no chart carries a clusterIssuer default
anymore.
- apache-tika, gotenberg, cyberchef, homeassistant, patchmon: additive env
value blocks rendered through tpl (value, secretKeyRef and configMapKeyRef
forms), following the template-chart/outline pattern; patchmon gets separate
blocks for the server container and the guacd sidecar.
- homeassistant: ingress.className now defaults to nginx; an empty className
omits ingressClassName from the rendered Ingress, so the flexible upstream
ingress style stays intact.
- outline, paperless-ngx: remove the ingress.clusterIssuer defaults
(letsencrypt / letsencrypt-issuer) - the value is now strictly required,
consistent with the repo-wide ingress standard; CI test-values set it
explicitly.
Chart bumps: apache-tika 7.2.0, gotenberg 4.2.0, cyberchef 5.2.0,
patchmon 5.2.0, homeassistant 4.2.0 (minor); outline 5.0.0,
paperless-ngx 10.0.0 (major).
Batch-3 major PR for paperless-ngx (issue #32):
- secrets.redisRef/databaseRef/paperlessRef -> redisSecretRef/
databaseSecretRef/paperlessSecretRef (consistent with the other
SecretRef values in the same block); CI fixtures updated
- TLS secret renamed to the standard tls-<release>-<chart>-ingress
(domain no longer part of the name)
- busybox init/cronjob image pinned via paperless.busybox.image
values, default bumped 1.28 -> 1.38.0
- probes values-configurable (defaults unchanged, incl. the 600s
startup budget); consume CronJob deliberately stays probe-less
- ingress standard: ingress.className (default nginx) and
ingress.annotations merge; domain/clusterIssuer stay required
- additive paperless.env block rendered through tpl (value,
secretKeyRef, configMapKeyRef forms)
- disabled scripts ConfigMap renamed to ...-configmap; PVC names kept
as documented naming-scheme exception (comments in the templates)
- chart 8.0.1+up3.0.5 -> 9.0.0+up3.0.5 (breaking values changes)
- Rename all resources from <chart>-<release>-uv-<kind> to the repo
standard <release>-<chart>-<kind> (deployment, service, ingress, both
OnePasswordItem secrets); drop the uv infix. No PVCs in this chart, so
no storage migration is needed.
- TLS secret renamed to the standard tls-<release>-<chart>-ingress
(was tls-<chart>-<release>-ingress).
- Probes lifted into values (urlaubsverwaltung.livenessProbe/
readinessProbe/startupProbe); defaults are exactly the previously
hardcoded, issue-#9-calibrated settings.
- Repo-standard flexible ingress: ingress.className (default nginx),
ingress.annotations merged with the cert-manager annotation,
ingress.enabled flag; domain/clusterIssuer stay required.
- Additive urlaubsverwaltung.env block rendered through tpl with
value/secretKeyRef/configMapKeyRef forms.
- CI fixtures updated to the new secret names.
Major bump 4.1.2+up6.7.0 -> 5.0.0+up6.7.0 (resource renames).
- Values-driven securityContext for the Synapse pod/container with hardened
defaults: runAsNonRoot as uid/gid 1000 (matching the image's previous gosu
drop target), readOnlyRootFilesystem, allowPrivilegeEscalation false, all
capabilities dropped; /tmp mounted as emptyDir. The now-ineffective UID/GID
env vars are removed (the securityContext controls the user).
- Naming scheme: delegation Deployment renamed to ...-delegation-nginx-deployment,
ConfigMap to ...-delegation-nginx-configmap (references and service selector
updated).
- matrix.configSecretRef moved to secrets.configSecretRef (repo standard).
- Probes for Synapse and the delegation nginx are values-configurable;
defaults are the previous hardcoded settings.
- Flexible ingress standard: ingress.className (default nginx) and
ingress.annotations merged with the cert-manager annotation.
- Additive matrix.env block rendered through tpl (value/secretKeyRef/
configMapKeyRef forms).
- CI fixtures: secret ref moved, seed job image synced to appVersion.
- Chart 4.2.1+upv1.159.0 -> 5.0.0+upv1.159.0 (major; app version unchanged).
Repo-standard flexible ingress (required clusterIssuer instead of the
hardcoded letsencrypt-issuer, domain moved from config.domain to
ingress.domain, className value, annotations merge, standard TLS secret
name), secrets.<name>SecretRef structure, core secret renamed to the
standard -secret name, additive tpl-rendered env block, documented PVC
naming exception. Major bump 4.1.2+up4.7.0 -> 5.0.0+up4.7.0.
All audit findings for the calibre-web-automated chart (#32) in one major
bump, 3.1.1+upv4.0.6 -> 4.0.0+upv4.0.6:
- Rename StatefulSet, Service, OnePasswordItem secret and Ingress from the
inverted <chart>-<release>-cwa-<kind> scheme to
<release>-<chart>-<kind>; spec.serviceName and all references follow.
Both PVCs deliberately keep their historical names (documented naming
exception; renaming would orphan the data).
- TLS secret renamed to the standard tls-<release>-<chart>-ingress.
- Ingress on the repo standard: ingress.className (default nginx),
ingress.annotations merged with the chart-managed annotations,
ingress.clusterIssuer now required (was silently defaulted to
"letsencrypt-issuer").
- Security hardening, values-configurable via securityContext.pod /
securityContext.container: allowPrivilegeEscalation false, all
capabilities dropped except the minimal set the s6-overlay init needs
(CHOWN, DAC_OVERRIDE, FOWNER, KILL, SETGID, SETUID). Documented
deviations: the image must start as root (s6 drops to PUID 1000) and
readOnlyRootFilesystem stays false (read-only mode disables PUID/PGID
remapping upstream and breaks the ImageMagick policy setup).
- Additive env value rendered through tpl (value / secretKeyRef /
configMapKeyRef forms).
- CI fixtures: secret renamed to the new scheme, clusterIssuer added to
test-values.
Part of #32.
Enable readOnlyRootFilesystem and drop all capabilities by default. The
paths the image writes at runtime are covered by emptyDirs (/tmp,
/opt/app/logs and STATIC_ROOT /opt/app/myapp/static); an init container
seeds the static volume with the assets shipped in the image because the
directory doubles as the app's static source. The ephemeral-storage
request covers the ~90Mi static emptyDir.
Move the Ingress to the repo-standard flexible style: ingress.className
value (default nginx) instead of a hardcoded ingressClassName, and
ingress.annotations merged with the cert-manager annotation. domain and
clusterIssuer stay required; the TLS secret name was already standard.
Major bump 3.1.2+up1.30.1 -> 4.0.0+up1.30.1 (hardening changes runtime
behavior). App version unchanged. Part of #32.
All audit findings from #32 for the satisfactory chart in one major PR:
- StatefulSet renamed to {{ .Release.Name }}-{{ .Chart.Name }}-sfs, service
to ...-service (standard scheme); template file satisfactory-server.sfs.yaml
renamed to satisfactory.sfs.yaml. The PVC keeps its historical -vc name
(documented naming exception; renaming would orphan the data).
- Hardened, values-configurable security contexts (securityContext.pod /
securityContext.container): runAsNonRoot with the image's steam user
(uid/gid 1000), readOnlyRootFilesystem, all capabilities dropped. emptyDirs
mounted at /tmp and the steam user's ~/.steam, ~/.config and ~/.local make
the read-only root filesystem work; all other writes go to the PVC.
- Probes are now values (livenessProbe/readinessProbe/startupProbe), defaults
exactly the previously hardcoded values.
- Additive env value rendered through tpl with value/secretKeyRef/
configMapKeyRef forms (template-chart pattern).
Chart 3.1.1+upv1.9.10 -> 4.0.0+upv1.9.10 (major: resource renames +
hardening); appVersion unchanged.
- Rename the Deployment (and its labels/selector/pod template/container)
to {{ .Release.Name }}-{{ .Chart.Name }}-deployment per the naming
scheme; the Service selector follows.
- Move the hardcoded pod/container security contexts into values
(rallly.securityContext.pod / .container), defaults unchanged; the
bogus null entry under capabilities.add becomes an empty list.
- Ingress standard: ingress.className value (default nginx) and
ingress.annotations merged with the cert-manager annotation;
domain/clusterIssuer stay required, TLS secret name already conformed.
- Add the tpl-rendered rallly.env value (value/secretKeyRef/
configMapKeyRef forms), appended to the built-in env.
- Major bump 3.1.2+up4.12.3 -> 4.0.0+up4.12.3 (deployment rename
replaces the Deployment on upgrade: selector is immutable).
Batch-3 major PR for teamspeak-server (issue #32):
- Rename service and StatefulSet to the repo naming scheme
({{ .Release.Name }}-{{ .Chart.Name }}-service / -sfs); the PVC keeps
its historical name (documented naming exception, data preservation).
- NodePorts configurable via server.voicePort / server.fileTransferPort
(defaults 30987/30033, satisfactory pattern); ports are also passed to
the server via TSSERVER_DEFAULT_PORT / TSSERVER_FILE_TRANSFER_PORT.
- Hardened, values-configurable security contexts
(securityContext.pod/container): non-root uid/gid 9987,
readOnlyRootFilesystem, all capabilities dropped.
- Probes values-configurable (defaults unchanged).
- Additive env value rendered through tpl (value/secretKeyRef/
configMapKeyRef forms).
- Chart 3.1.2 -> 4.0.0 (+up6.0.0.beta12.1).
- Add securityContext.pod/container values with hardened defaults; the
dockur/samba image requires root and a writable root filesystem, so the
remaining deviations from the baseline are documented in values.yaml
(caps reduced to CHOWN, DAC_OVERRIDE, FOWNER, NET_BIND_SERVICE, SETGID,
SETUID; allowPrivilegeEscalation: false)
- Make the NodePorts configurable (samba.smbNodePort/netbiosNodePort,
defaults 30445/30139 as published before)
- Rename secrets.sambaUsersRef to secrets.sambaUsersSecretRef (breaking)
- Rename the ConfigMap from -config-cfm to -configmap
- Add the tpl-rendered env value convention (value, secretKeyRef,
configMapKeyRef forms)
- Fix the CI users.conf fixture to the username:uid:groupname:gid:password
format the pinned image actually parses
- Bump chart to 4.0.0+up4.23.10
Part of #32
- Pod and container securityContext are now values-configurable
(outline.securityContext.pod/container) with hardened defaults:
runAsNonRoot (uid/gid 1001, the upstream image's nodejs user),
readOnlyRootFilesystem, allowPrivilegeEscalation false, all
capabilities dropped. /tmp is mounted as an emptyDir for Outline's
import/export scratch files.
- Probes moved to values (outline.livenessProbe/readinessProbe/
startupProbe); defaults are exactly the previously hardcoded ones.
- Ingress raised to the repo standard: ingress.className (default
nginx), ingress.annotations merged with the always-set annotations,
ingress.enabled flag; domain/clusterIssuer stay required and the
TLS secret name was already conform.
- Additive outline.env block rendered through tpl with value/
secretKeyRef/configMapKeyRef forms; chart-managed env stays in the
template.
Major bump 3.1.1+up1.9.2 -> 4.0.0+up1.9.2 (runtime behavior changes
through hardening).
Part of #32
Establish the flexible ingress standard from #32 in template-chart and
document it in README/CLAUDE.md: ingress.domain and ingress.clusterIssuer
stay required, new ingress.className value (default nginx) replaces the
hardcoded ingressClassName, new optional ingress.annotations are merged
with the cert-manager cluster-issuer annotation, TLS secret name
unchanged (tls-<release>-<chart>-ingress).
Apply the standard to cyberchef and patchmon (the two charts without an
own batch-3 major PR) and make the patchmon probes values-configurable
(server + guacd, rendered through tpl so the default Host header keeps
following ingress.domain). Defaults render semantically identical to the
previous hardcoded output.
cyberchef 5.0.1 -> 5.1.0, patchmon 5.0.1 -> 5.1.0 (minor, additive).
- Add icon: to all 17 Chart.yaml (official project icons); removes the
last helm lint --strict INFO finding across the repo
- Rename template files to the <app>.<kind>.yaml scheme (apache-tika,
gotenberg, teamspeak-server PVC, paperless-ngx configmap) - pure
git mv, no content changes
- template-chart: fix missing space in {{ .Chart.Name}} and rename the
ConfigMap resource -config-map -> -configmap (chart is never published)
- rallly: fix typos in required messages (rallySecret -> ralllySecret,
databseSecret -> databaseSecret)
- README: document the deliberate PVC-name exception from the naming
scheme (renames would provision new empty volumes)
- Patch-bump all 16 published charts
Rendered resources are byte-identical for all published charts (only
helm's '# Source:' comments change for the renamed files); the only
render change is the template-chart ConfigMap name.
Part of #32
The delegation nginx image was hardcoded as nginx:1.28.3 in the
deployment template. It is now rendered from the new values
matrix.delegation.image.repository / matrix.delegation.image.tag,
defaulting to nginx:1.30.4 (current stable line, tag verified against
Docker Hub). README documents that auxiliary/sidecar images are pinned
via values and reviewed with every app-version update round.
Chart version: 4.1.1+upv1.159.0 -> 4.2.0+upv1.159.0 (minor: additive
values change).
Chart rewrite for the 2.x single-server architecture: one stateless
server deployment (frontend embedded, /api served by the same process),
no PVC, single service and ingress path, optional guacd sidecar
(disabled by default), 2.x env vocabulary (TRUST_PROXY, readonly role),
probes send the public hostname as Host header.
Fixes#29: all three reported spots (PVC storageClass guard, RWX assets
PVC, frontend nginx 'backend' hostname) are removed by this rewrite.
Major app jump 2.20.15 -> 3.0.5. Chart major bump (7.1.1 -> 8.0.0):
the paperless.files.barcodes.scanner value is removed (pyzbar and
PAPERLESS_CONSUMER_BARCODE_SCANNER were removed upstream), the
paperless.ocr.mode default changes from the removed "skip" to "auto",
and the startup probe budget is raised to 600s for the one-time
Whoosh -> Tantivy index rebuild. New optional values:
paperless.ocr.archiveFileGeneration, paperless.files.deleteDuplicates,
oidc.provider.tokenAuthMethod.
Major jump 10.22.1 -> 11.4.0: the upstream image switched to
nginxinc/nginx-unprivileged (serving port 80 -> 8080, pid/temp dirs
under /tmp). Adjust container port, writable-volume mounts and the
pod security context (sysctl net.ipv4.ip_unprivileged_port_start no
longer needed). Chart major bump 4.1.0 -> 5.0.0 accordingly.
Nine non-critical app-version bumps, each with a chart patch bump:
- apache-tika 3.2.3.0-full -> 3.3.1.0-full
- gotenberg 8.26.0 -> 8.36.0
- matrix-synapse v1.149.1 -> v1.159.0
- rallly 4.8.1 -> 4.12.3
- samba 4.23.5 -> 4.23.10
- urlaubsverwaltung 6.5.0 -> 6.7.0
- voucher-vault 1.27.4 -> 1.30.1
- zipline 4.6.4 -> 4.7.0
- teamspeak-server v6.0.0-beta8 -> 6.0.0-beta12.1 (new tag format has no v prefix)
Release notes of every chart were checked for environment-variable
changes; none of the charts needs an env adjustment.
The teamspeak-server install-test is reactivated: beta12.1 ships a
valid default license, so the exclusion is removed, CI fixtures are
added under ci/teamspeak-server/, and the install-test was verified
in a local k3d cluster. README list of excluded charts updated.
Every Deployment/StatefulSet now takes its replica count from a replicas
value (default 1, explicit 0 allowed) via a new per-chart <chart>.replicas
helper; the helper uses a kindIs "invalid" nil check so an explicit 0 is
not swallowed by Helm's default function. A chart-global scaleDown flag
(default false) takes precedence: it renders every workload with
replicas: 0 and suspends the paperless-ngx consume CronJob, stopping the
app without uninstalling it (PVCs, Secrets, Services and Ingress remain).
Defaults leave the rendered manifests byte-identical to main, so all
published charts get a minor version bump; the template-chart carries the
reference helper implementation and stays unversioned.
Fixes#25
Every chart now renders its container resources through a duplicated
_helpers.tpl helper (reference implementation in template-chart): requests
ship as chart defaults, missing memory and ephemeral-storage limits are
computed as resources.limitFactor x the request (default 3, satisfactory
keeps 2 to preserve its previously published 8Gi limit), an explicitly set
limit always wins, and a CPU limit is only rendered when set explicitly.
Fixed limit defaults are removed from all values.yaml files; teamspeak-server
gains a values-driven resources block instead of hardcoded template values.
Major version bump for all published charts.
- validation happens via strict lint, PR pipeline and install-test stage
- new charts need ci/ fixtures or an exclusion entry
- codify semver conventions (patch/minor/major)
- app updates via PRs with stepped major upgrades
The StatefulSet spec lacked the mandatory serviceName field, causing
permanent drift in Fleet (spec.serviceName reported as modified).
Points to the chart's existing cwa-service. Bumps chart to 2.0.1.
jklein