31 Commits

Include renames

Author	SHA1	Message	Date
jklein	e1adcef71f	feat!: NetworkPolicy in nine more charts, on by default ... bulwark, calibre-web-automated, patchmon, rallly, urlaubsverwaltung, voucher-vault, zipline, sure, homeassistant. One major each. These are the charts with real outbound dependencies, and they all share one limitation that is now written into every one of them: THE EGRESS PORTS ARE THE STANDARD ONES, NOT THE CONFIGURED ONES. Databases, caches and OIDC issuers arrive as connection URLs or as fields inside 1Password items that the charts never parse, so a chart cannot know where its dependency listens and cannot validate a guess. A dependency somewhere else is blocked, and networkPolicy.egress.extraPorts is the escape hatch. That is the upgrade risk of this rollout, stated per chart instead of discovered per release. Four of them differ in ways that mattered: HOMEASSISTANT gets policyTypes: [Ingress] and NO egress section at all, and that is the decision in the file rather than an omission. Its outbound traffic is the union of every integration an operator enables - mDNS and SSDP discovery, MQTT, a Zigbee or Z-Wave bridge on whatever port its firmware chose, ESPHome, printers, speakers, inverters, cloud APIs, NTP - which no chart can know. A cap would protect little, since the devices sit on the node's own LAN, and would break integrations one at a time, months apart, each looking like a flaky device rather than like a policy. So valkey's rule applies in the other direction: policyTypes names only what there is something to restrict. URLAUBSVERWALTUNG allows BOTH 5432 and 3306, deliberately. It is handed a full JDBC URL inside a 1Password item and never parses it, so it cannot tell PostgreSQL from MariaDB - and this cluster runs both. Allowing one would break half the possible deployments on upgrade, with the symptom buried in a Java stack trace. A small widening against a large and silent failure. RALLLY derives its SMTP rule from rallly.smtp.enabled rather than always rendering it: with mail switched off there is nothing to permit, and a rule that permits nothing makes the object look stricter than it is. BULWARK is the chart where the cap can fail most quietly. Its probes test its own port and say nothing about the JMAP server, so a jmapServerUrl on a port the policy does not allow yields a Ready pod serving an empty webmail. 443 is allowed, Stalwart's in-cluster 8080 is not, and both halves of that are in values.yaml and NOTES.txt. PATCHMON and HOMEASSISTANT select their pods by the BARE release-and-chart label, with no -deployment or -sfs suffix. Copying a selector from a neighbouring chart would have matched nothing and left a policy that filters nothing - which is precisely the first assertion of the render test. Five CI fixtures gain networkPolicy.egress.extraPorts, and they are the only place in the repository where the cap's cost is actually exercised: the CI dex runs on 5556 rather than 443 (patchmon, rallly, urlaubsverwaltung, voucher-vault) and the CI JMAP server on plain 8080 (bulwark). Part of #5	2026-10-14 14:26:25 +00:00
jlab-renovate-bot	6517643cd6	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.17.0	2026-10-13 09:38:25 +00:00
jklein	33d7cedbab	feat: Gateway-API as an alternative to the Ingress in eight charts ... Group 1 of the #114 sweep: the charts that render exactly one Ingress object and set no behaviour-bearing nginx annotation - bentopdf, garage, patchmon, rallly, searxng, sure, urlaubsverwaltung, voucher-vault. Each gets the form the pilot (cyberchef, PR #115) fixed and template-chart carries: an httpRoute block (enabled/parentRefs/hostnames, off by default), a template rendering ONLY an HTTPRoute with parentRefs - no Gateway, no gatewayClassName, no Certificate, no implementation-specific policy object - render aborts on both modes at once (naming both value paths), on an empty parentRefs and on a missing hostname, empty hostnames meaning [ingress.domain], a schema entry closed against unknown keys with an open parentRef definition, and a NOTES.txt that names the active mode and what the mode costs. Minor, additive, defaults unchanged: `helm template` with each chart's CI values is byte-identical to origin/main for seven of the eight, and for sure identical in every rendered value (the diff is two YAML comment lines). Three findings that were not in the plan, each argued in the file it changes: sure derived RAILS_ASSUME_SSL/RAILS_FORCE_SSL from ingress.enabled alone. Gateway mode sets that false by construction while TLS is still terminated at the Gateway, so both flags would have gone false: insecure cookies, no HSTS, http:// links, with a Ready pod and a working UI as the only symptom. They now read sure.publishedOverTls (ingress.enabled OR httpRoute.enabled), which is ingress.enabled while httpRoute.enabled is false - hence still Minor. garage claimed, in its Ingress template and its schema, that nothing outside that template reads ingress.domain. The HTTPRoute reads it, so the claim now holds only while both modes are off. Corrected rather than left standing. garage also depends on an upload limit it does not set: its annotations comment tells the operator to set proxy-body-size: "0" because ingress-nginx truncates S3 uploads at 1 MB. proxy-body-size has no Gateway-API counterpart, so its Gateway-mode NOTES prints that the limit is the Gateway's. README's list of affected charts named five and now names garage as a sixth. clusterIssuer needed no change in any of the eight: its only required() sits inside the Ingress template behind ingress.enabled, the same no-op the pilot found. Annotation guidance that stops applying in Gateway mode moved into the Gateway branch of NOTES.txt for bentopdf (X-Robots-Tag) and searxng (forward-auth). CI: one render overlay per chart under ci/httproute/, so the assertion is not vacuum-green - ci/run-httproute-match-test.sh goes from 4 held assertions over 2 charts to 20 over 10. The install-test fixtures stay in Ingress mode: the install runs one configuration per chart, cyberchef already pays that price against the real Gateway-API CRDs, and for garage the Ingress is the only place its Service port is referenced by NAME. Not proven, by construction: that traffic flows. No Gateway controller runs in CI. Not run locally either: k3d, Docker, Trivy. Part of #114	2026-10-12 16:06:18 +00:00
jlab-renovate-bot	a23d4977c5	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.15.0	2026-10-04 15:40:59 +00:00
jlab-renovate-bot	f3ad3a9844	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.14.0	2026-09-30 18:57:54 +00:00
jklein	e0b552d93e	Replace the obsolete no-dependencies rationale in every chart helper ... 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() ... 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	2026-09-26 20:41:42 +00:00
jlab-renovate-bot	1edcf6fb9c	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.13.0	2026-09-23 01:02:41 +00:00
jlab-renovate-bot	ddbf82e0d4	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.12.1	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