jklein
a9ca5302de
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Build paperless-ngx (pull_request) Successful in 6s
Validate Helm Charts / Trivy config paperless-ngx (pull_request) Successful in 22s
Install-test / Install-test paperless-ngx (pull_request) Successful in 3m31s
Validate Helm Charts / Install-test (pull_request) Successful in 3m31s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 10s
Publish Paperless-NGX Helm Chart / Publish Paperless-NGX Helm Chart (push) Successful in 10s
SonarQube Analysis / SonarQube Analysis (push) Successful in 33s
paperless-ngx cannot run without a Redis - PAPERLESS_REDIS is the Celery broker - so every installation needed a second Helm release whose address lived in a 1Password item and in neither chart. This adds our own published valkey chart as an optional dependency, off by default and gated on valkeySubchart.enabled (not valkey.enabled, which the subchart's strict schema rejects and which Helm would only have complained about for whoever first switched it on). Additive, default behaviour unchanged: minor, 12.1.3+up3.2.1 -> 12.2.0+up3.2.1. Configured as a QUEUE (PVC + noeviction, the subchart's defaults), unlike stalwart's cache. Read off the 3.2.1 source rather than assumed: one PAPERLESS_REDIS url serves five consumers - the Celery broker, the result backend (Redis in 3.x, the database before), the channels pub/sub layer and two Django caches. allkeys-lru would not be a trade here but actively wrong, because LRU evicts typeless across the whole keyspace and a backlog of waiting consume tasks is exactly what it reads as cold; a dropped task is a document silently never processed. The price, named in values.yaml rather than smoothed over: two of the five consumers are caches, so a full instance refuses writes - new tasks included - and the answer is memory sizing, not a policy change. All three cache-like consumers are TTL-bounded, which is what keeps that price small. The password comes from the SAME item as the Redis connection, in a third field auth-conf holding the complete line "requirepass <password>". It cannot DEFAULT to secrets.redisSecretRef, and that is a property of Helm, not an omission: a values.yaml is never templated and a parent cannot compute a subchart's value. Measured - a template expression there lands verbatim in the subchart's itemPath and fails as a YAML parse error naming neither the value nor the cause. Forgetting it is therefore caught in values.schema.json, by a conditional rule rather than a fail() in a template. Also measured, and the reason: Helm renders a subchart's templates BEFORE the parent's, so a guard in this chart loses the race to the subchart's own required(), which reports "secrets.authSecretRef" and cannot know the path belongs to the redis item. A check that cannot fire is the mistake found while testing #77, so the first draft of that guard was removed rather than shipped. The schema runs before any rendering and names /valkey/secrets/authSecretRef. One trap found while testing and closed here: "valkeySubchart: null" DELETES the key, Helm then cannot resolve the condition path and treats the dependency as ENABLED - so erasing the switch turned the subchart on with no password set. Unlike every other block in this chart (issue #99), that one is rejected by the schema instead of defaulting. The install-test now runs with the subchart ON and the throwaway redis Deployment removed: the url in the fixtures names ci-valkey-service, so the bundled Valkey is the broker the release actually uses. #65 covered this path by a render only - deliberately, since an unused Valkey would have made that test look like it covered clustering. This is the first real installation of the valkey-subchart path. Documented, not glossed: the password now sits in that item twice and a rotation has to touch both fields; with the subchart on the vault url is a mandatory step, not a hint; and a OnePasswordItem materializes every field of its item, so both Secrets carry all three keys - untidy, harmless, and written down so nobody "tidies it up". Fixes #78
90 lines
4.2 KiB
YAML
90 lines
4.2 KiB
YAML
# CI values for the paperless-ngx install-test.
|
|
#
|
|
# THE SUBCHART IS ON, AND THAT IS THE POINT OF THIS FILE. Gitea #65 added the
|
|
# same valkey dependency to stalwart but covered it by a local RENDER only -
|
|
# deliberately, because Stalwart's in-memory store is an object in its database,
|
|
# so a Valkey in that namespace would have been reachable and unused and the
|
|
# test would have looked like it covered the clustering path while covering
|
|
# nothing of it. Here it is the opposite: paperless-ngx reads PAPERLESS_REDIS
|
|
# from the vault item, so pointing that url at the subchart's Service makes the
|
|
# bundled Valkey the broker this release actually uses. So this is the first
|
|
# install of the valkey-subchart path anywhere, and what it proves is:
|
|
#
|
|
# 1. The dependency resolves from the published index on a real runner with no
|
|
# credentials, and lint/package/render/install all survive it.
|
|
# 2. The subchart's objects are accepted inside a parent release: its
|
|
# StatefulSet becomes Ready, which means its init container found a
|
|
# "requirepass " line in the mounted auth file and its three exec probes
|
|
# authenticated and got PONG back.
|
|
# 3. The PVC path of the subchart works under a parent release name
|
|
# (ci-valkey-*), i.e. the names really are <release>-valkey-<kind>.
|
|
# 4. paperless-ngx talks to it: the url in the fixture Secret names
|
|
# ci-valkey-service, so a wrong Service name or a password mismatch between
|
|
# the two fields of the "item" shows up as a failing run instead of as a
|
|
# quietly idle Valkey.
|
|
#
|
|
# What it still CANNOT prove is that documents are processed - that needs a real
|
|
# consume run and is out of scope here, as before.
|
|
secrets:
|
|
# One item for both, which is the configuration the chart is designed around:
|
|
# redis-connection-url, key-prefix AND auth-conf live in the same 1Password
|
|
# item. In CI the operator does not exist, so ci/paperless-ngx/fixtures.yaml
|
|
# stands in for it - and it stands in TWICE, because a OnePasswordItem
|
|
# materializes every field of the item it names. See the fixture.
|
|
redisSecretRef: op://ci/paperless-redis
|
|
databaseSecretRef: op://ci/paperless-db
|
|
paperlessSecretRef: op://ci/paperless
|
|
|
|
ingress:
|
|
domain: paperless.ci.local
|
|
# clusterIssuer is strictly required (no default); the Ingress just has to
|
|
# apply - there is no cert-manager in the CI cluster.
|
|
clusterIssuer: ci
|
|
|
|
paperless:
|
|
files:
|
|
# Regression guard for issue #61: a childless "barcodes:" key is YAML null.
|
|
# It must fall back to the chart defaults (barcodes enabled, "PATCHT") and
|
|
# neither erase them nor break rendering.
|
|
barcodes:
|
|
|
|
valkeySubchart:
|
|
enabled: true
|
|
|
|
valkey:
|
|
secrets:
|
|
# The SAME op:// path as secrets.redisSecretRef above, typed out again
|
|
# because Helm cannot default one value from another (Gitea #78). Typing it
|
|
# here is also what exercises the parent's guard in the "satisfied"
|
|
# direction; the failing direction is covered by a local render, since the
|
|
# harness installs one configuration per chart.
|
|
authSecretRef: op://ci/paperless-redis
|
|
|
|
persistence:
|
|
# QUEUE, the chart's and the subchart's default - and the risky half, which
|
|
# is why it is not switched off here: a provisioned PVC, the pod's fsGroup
|
|
# against a volume it did not create, and an append-only file written and
|
|
# replayed on it.
|
|
enabled: true
|
|
appendonly: true
|
|
# k3d's dynamic provisioner. The subchart's default, longhorn-encrypted-ns,
|
|
# does not exist on the runner, and the no-provisioner "longhorn" class the
|
|
# paperless fixtures define is pre-bound to hostPath PVs for paperless' own
|
|
# claims - a hostPath volume gets no fsGroup from the kubelet at all, so
|
|
# reusing it here would silently stop testing the ownership path.
|
|
storageClass: local-path
|
|
size: 128Mi
|
|
|
|
valkey:
|
|
resources:
|
|
# Small, to stay inside the runner's budget, while still exercising the
|
|
# subchart's derivation: 64Mi x limitFactor 3 = 192Mi limit, maxmemory =
|
|
# 0.75 x that = 144Mi.
|
|
requests:
|
|
cpu: 50m
|
|
memory: 64Mi
|
|
ephemeral-storage: 32Mi
|
|
|
|
# smbConnection and oidc stay disabled (defaults): the SMB CSI driver and a
|
|
# real OIDC login flow are out of scope for the CI install-test.
|