Commit Graph
27 Commits
Author SHA1 Message Date
jlab-renovate-bot f3ad3a9844 Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.14.0
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 8s
2026-09-30 18:57:54 +00:00
jklein e0b552d93e Replace the obsolete no-dependencies rationale in every chart helper
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 31s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 1m34s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 15m49s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Apache Tika Helm Chart / Publish Apache Tika Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish BentoPDF Helm Chart / Publish BentoPDF Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Calibre Web Automated Helm Chart / Publish Calibre Web Automated Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Cyberchef Helm Chart / Publish Cyberchef Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Freesailarr Helm Chart / Publish Freesailarr Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Gotenberg Helm Chart / Publish Gotenberg Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Homeassistant Helm Chart / Publish Homeassistant Helm Chart (push) Successful in 8s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Matrix Synapse Helm Chart / Publish Matrix Synapse Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Minecraft-Router Helm Chart / Publish Minecraft-Router Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Minecraft-Server Helm Chart / Publish Minecraft-Server Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Outline Helm Chart / Publish Outline Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Patchmon Helm Chart / Publish Patchmon Helm Chart (push) Successful in 6s
Publish Paperless-NGX Helm Chart / Publish Paperless-NGX Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Rallly Helm Chart / Publish Rallly Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Samba Helm Chart / Publish Samba Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Satisfactory Helm Chart / Publish Satisfactory Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish TeamSpeak Server Helm Chart / Publish TeamSpeak Server Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish VoucherVault Helm Chart / Publish VoucherVault Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Zipline Helm Chart / Publish Zipline Helm Chart (push) Successful in 6s
The doc comments on the resources and defaultedDict helpers justified the
copy-per-chart with "charts in this repo deliberately have no dependencies".
That rule fell with #214: a dependency is admissible now, just expensive, and
it sits in the README as guideline 14, not 13. The justification still holds,
but its reason is a different one - sharing the helper would mean a library
chart, a second artefact to publish, version and pull for something that
changes about once a year. searxng got that wording in PR #38; this carries it
to 21 further charts, 40 occurrences in all.

rss-bridge is deliberately left out. Its install-test fails on the Gitea
runner for a reason that predates this branch, and touching the chart would
keep it in the install-test matrix and the check red. Its copy of the sentence
is carried by #51, which has to open the chart anyway.

Comments only: every touched chart renders byte-identical against its
ci/<chart>/test-values.yaml. Each published chart takes a patch bump,
appVersion and +up suffix untouched; template-chart is never published and
takes none, but is corrected because every new chart inherits from it.

Two repo files carried the same claim at no version cost:
validate-charts.yml explained the all-charts quantity render test with it, and
change-app-version.yml still counted nine images for freesailarr - MediathekArr
made it ten.
2026-09-27 10:27:57 +00:00
jklein 8074ed14a5 Guard the four unguarded OnePasswordItem references with required()
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 3m11s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Calibre Web Automated Helm Chart / Publish Calibre Web Automated Helm Chart (push) Successful in 7s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Minecraft-Server Helm Chart / Publish Minecraft-Server Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish SearXNG Helm Chart / Publish SearXNG Helm Chart (push) Successful in 6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 7s
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 6s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 19s
calibre-web-automated 7.0.0, minecraft-server 6.0.0 and urlaubsverwaltung
10.0.0 each majors: an installation that renders today with an empty itemPath
stops rendering. searxng 1.0.6 is documentation only - its valkey reference is
correctly optional and stays gated by {{- if }}.

Every message names the values path. values.yaml now says per key why it is
required, reusing the wording the charts' NOTES.txt already carry. The
hand-rolled "cwaSecretRef IS UNSET" block in calibre-web-automated's NOTES.txt
is gone: after the guard the render aborts first and that block is
unreachable. minecraft-server's note stays true and now points at the guard.

No "required" array in the schemas, and README guideline 12 now says why. The
plan called for one; measuring it showed it could never fire: the key ships as
null, so it is present at validation time, and JSON Schema's required tests
presence, not null-ness. Making it fire means either dropping the null default
or narrowing the type to "string", and both turn helm lint --strict red on the
chart's own defaults. The schema therefore describes the key as required and
required() enforces it. The README bullet on how null reaches the schema was
also wrong in the case it was being applied to - a null chart default is not
coalesced away - and now distinguishes the three cases.

searxng: the claim "charts in this repo have no dependencies (README,
guideline 13)" in the valkey template, in values.yaml and twice in _helpers.tpl
has been false since #214 and cited the wrong guideline; dependencies are
admissible and are guideline 14. The same sentence survives in other charts'
helpers and needs its own round.
2026-09-26 21:15:30 +00:00
jlab-renovate-bot 819d7b2cf7 Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.13.1
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 14s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 16s
2026-09-26 20:41:42 +00:00
jlab-renovate-bot 1edcf6fb9c Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.13.0
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 1m38s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 7s
renovate/stability-days Updates have met minimum release age requirement
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 7s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 3s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 10s
2026-09-23 01:02:41 +00:00
jlab-renovate-bot ddbf82e0d4 Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.12.1
renovate/stability-days Updates have met minimum release age requirement
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 7s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 4s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 1m44s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 10s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 6s
Publish Urlaubsverwaltung Helm Chart / Publish Urlaubsverwaltung Helm Chart (push) Successful in 6s
2026-09-18 16:02:15 +00:00
jlab-renovate[bot] eb6e40d9a0 Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.12.0 2026-09-13 14:02:39 +00:00
jlab-renovate[bot] e0c2de883c Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.10.0 2026-09-08 21:34:41 +00:00
jklein f761767630 urlaubsverwaltung: correct the env-collision claim, answer the recovery question
The chart told operators that adding a duplicate env name to an installed
release makes the next upgrade fail in the API server, quoting "The order in
patch list ... doesn't match $setElementOrder list". Measured against helm
3.19.0 and Kubernetes 1.35, it does not fail: the upgrade succeeds, helm prints
"Release has been upgraded", and Kubernetes merges the env list by name, so the
duplicate pair collapses to the chart's own entry and the operator's override is
discarded without a word. At install time the same values behave differently -
both entries reach the pod, the later one wins, and the API server says so with
"hides previous definition of ..., which may be dropped when using apply".

The advice that followed from the old claim survives - such a switch only takes
at install time - but the stated reason was wrong in the dangerous direction. A
reader who expects a loud failure treats a green upgrade as proof the override
took effect, and green is exactly what a silently dropped override looks like.
The text now names the real failure mode and tells the reader to read the value
back off the Deployment. README carries the same correction, because every chart
in this repo offers the same additive env block.

Also records what the earlier measurement left open. With the database scaled
back up the pod returns to Ready on its own after about five seconds, restart
count still 0, so leaving the liveness group untouched costs no manual recovery.
And the limit of that signal belongs next to it: the db indicator validates a
connection, not the schema, so a database that came back empty still put the pod
back to Ready with /actuator/health at 200.
2026-09-02 13:22:58 +02:00
jklein f8acdfdfe1 urlaubsverwaltung: readiness must see the database, health must not lie (9.0.0+up6.7.0)
MANAGEMENT_ENDPOINT_HEALTH_GROUP_READINESS_INCLUDE=readinessState,db puts the datasource into Spring Boot's readiness group, which shipped with readinessState alone: a total database outage left the pod 1/1 Ready while every request failed. Naming the members replaces the default, so readinessState is repeated. The liveness group stays untouched on purpose, because an outage has to keep traffic away rather than add a crash loop to it.

MANAGEMENT_HEALTH_MAIL_ENABLED=false removes the mail indicator, which pinned the aggregate /actuator/health at 503 for the whole life of a healthy release, because the chart's mail wiring points at localhost:1025 where nothing listens. values.yaml and NOTES.txt document what that costs and when it has to be switched back on.
2026-09-02 13:01:54 +02:00
jklein 021df7d024 urlaubsverwaltung: NOTES.txt and the exponential-quantity fix (8.1.0+up6.7.0)
Teil von #157 und Teil von #43.

#157: multiplyQuantity turned a bare byte count into exponential notation.
Values pass through fromYaml, which parses every number as float64, and Go's
"%v" switches float64 to exponential notation from about 1e6 upwards. Both
places that stringify a number now go through the new formatNumber helper -
the input of multiplyQuantity, which aborted the render with an unsupported
suffix "e+06", and the output of a non-integer product, which did not abort
at all but rendered an invalid quantity that only the API server rejects.

Measured on this chart against ci/urlaubsverwaltung/test-values.yaml:

  requests.memory=1048576              before: abort, suffix "e+06"
                                       after:  request 1048576, limit "3145728"
  requests.ephemeralStorage=2097152    before: abort, suffix "e+06"
                                       after:  limit "6291456"
  memory=999999, limitFactor=1.5       before: limit "1.4999985e+06", no abort
                                       after:  limit "1499998.5"
  requests.memory=65536 (regression)   196608 before and after

The correction is the canonical one, word for word as merged into
template-chart, voucher-vault and zipline; only the helper prefix differs.
urlaubsverwaltung has a single resources path and a single render site
(the Deployment), and both were verified.

#43: adds a NOTES.txt. Its content was verified against a running release in
a throwaway k3d cluster rather than taken from upstream documentation - the
identity provider being resolved at boot (a bad issuer-uri crashlooops the
pod instead of breaking the login), the buildpack sizing the JVM heap from
the computed memory limit, /actuator/health answering 503 for the lifetime of
the release because the chart points the mail sender at localhost:1025, the
probe groups not reacting to a database outage, and a name collision in
urlaubsverwaltung.env making the next helm upgrade fail on the patch order.

README.md is deliberately untouched: the line listing the charts that ship a
NOTES.txt collides with every parallel NOTES PR and is pulled up once at the
end of the programme.

Minor bump: a NOTES.txt renders no Kubernetes object and the quantity fix
changes no default. appVersion unchanged.
2026-08-29 00:50:17 +02:00
jklein 6c73ef874b Eight charts: seccompProfile RuntimeDefault and qualified images
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
2026-08-24 13:17:14 +02:00
jklein 4976c67ce3 Add strict values.schema.json and null-safe hardening to urlaubsverwaltung
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.
2026-08-23 20:14:27 +02:00
jklein 22fdb58396 Strict clusterIssuer also for cyberchef and urlaubsverwaltung
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.
2026-08-22 23:13:23 +02:00
jklein 9d22b3b921 urlaubsverwaltung chart: naming scheme, configurable probes, flexible ingress
- 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).
2026-08-22 19:27:14 +02:00
jklein a69542383e Conventions batch 1: icons, template file names, cosmetics
- 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
2026-08-22 15:21:52 +02:00
jklein ea68a69a3e Update app versions (batch): tika, gotenberg, synapse, rallly, samba, urlaubsverwaltung, voucher-vault, zipline, teamspeak
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.
2026-08-22 08:44:00 +02:00
jklein 6779e49355 Add per-workload replicas values and a chart-global scaleDown flag
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
2026-08-22 08:12:40 +02:00
jklein 91a2fbcb05 Compute memory/ephemeral-storage limits from requests, drop default CPU limits
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.
2026-08-21 23:34:09 +02:00
jklein b5eba4cbf1 Harden pod and container security contexts across all workloads
Add securityContext hardening (runAsNonRoot, readOnlyRootFilesystem,
capabilities drop ALL, allowPrivilegeEscalation false) to the 10 workloads
that lacked it: apache-tika, cyberchef, gotenberg, homeassistant,
matrix-delegation-nginx, paperless-server, paperless-consume cronjob
(plus automountServiceAccountToken false), patchmon-frontend,
urlaubsverwaltung and zipline. All contexts are configurable via
securityContext.pod / securityContext.container in values.yaml; writable
paths are provided as emptyDirs. Image-forced deviations (Home Assistant
root start for s6-overlay + NET_RAW for discovery, paperless root init
container for /run ownership) are documented in the charts' values.yaml.
Major version bump for every changed published chart.
2026-08-21 21:49:05 +02:00
jklein 78d78973c5 Ensure liveness, readiness and startup probes on all workloads
Every container in every Deployment/StatefulSet now defines all three
probes. The paperless-ngx consume CronJob intentionally has none (batch
workload).

- Add probes: apache-tika, calibre-web-automated, cyberchef, gotenberg,
  homeassistant, patchmon-backend, samba (tcp/445), teamspeak-server
  (tcp/30033), zipline (/api/healthcheck)
- Fix voucher-vault null probe values with real defaults
- Fix startup-probe semantics in template-chart and rallly (no
  initialDelaySeconds, generous failureThreshold)
- Switch outline probes to its /_health endpoint
- Add readiness/startup probes to satisfactory
- Add startup probes to matrix-synapse, matrix-delegation-nginx,
  paperless-server, patchmon-frontend, urlaubsverwaltung
- Major version bump for all published charts
2026-08-21 17:36:53 +02:00
jk-cluster-bot 807bd7bff4 Updated urlaubsverwaltung application version to 6.5.0 2026-07-26 20:57:10 +00:00
jk-cluster-bot b023b98158 Updated urlaubsverwaltung application version to 6.1.0 2026-07-02 08:20:58 +00:00
jk-cluster-bot 9bf90be897 Updated urlaubsverwaltung application version to 5.38.0 2026-03-24 09:34:18 +00:00
jklein 3ff932dc1f feat(charts): moved to other chart-version format 2026-03-09 23:15:16 +01:00
jk-cluster-bot 2b3404f5cc Updated urlaubsverwaltung application version to 5.34.5 2026-02-22 13:23:02 +00:00
jklein 95d42b7d03 feat(urlaubsverwaltung): added initial chart 2026-02-22 13:23:51 +01:00