sure: new chart for the we-promise Sure app (1.0.0+up0.7.4)

One StatefulSet with two containers - the Puma web process and a Sidekiq
worker - sharing one ReadWriteOnce PVC at /rails/storage. That shared
volume is the reason they live in one pod: splitting them would need an
RWX volume. Only the web container migrates, because the image entrypoint
runs db:prepare solely for the './bin/rails server' command; the worker is
started through args: so the entrypoint (and its jemalloc preload) stays
in place and the two can never race.

Probes are chosen for what they prove: liveness and startup use Rails'
/up, which is a boot check and touches no database, while readiness uses
'/', which runs User.count through authenticate_user! in self-hosted mode
and therefore fails while Postgres is unreachable. The worker speaks no
HTTP, so all three of its probes ask sidekiqmon whether this pod still
holds a Sidekiq heartbeat in Redis.

Three OnePasswordItem CRs (app, database, redis), ingress.domain kept
required outside the Ingress because APP_DOMAIN and the WebAuthn relying
party read it, strict values.schema.json, CI fixtures with throwaway
Postgres 16 and Redis, and a Renovate manager on semver so the
-alpha/-rc/-hotfix channel and the moving tags are never selected.

ci/sure/fixtures.yaml

@@ -0,0 +1,124 @@
+# Fixtures for the sure install-test: throwaway PostgreSQL 16 (the version
+# upstream's compose file uses) and Redis, plus the secrets the 1Password
+# operator would otherwise materialize (release name: ci).
+#
+# Both are mandatory for this chart, and for different reasons: the web
+# container migrates the schema at start and its readiness probe runs a query,
+# while all three probes of the worker container ask Redis whether the Sidekiq
+# process still has a heartbeat. A missing Redis therefore does not show up as
+# "a background job is late" but as a pod that never turns Ready.
+apiVersion: v1
+kind: Secret
+metadata:
+  name: ci-sure-secret
+stringData:
+  # 64 bytes hex, as upstream's "openssl rand -hex 64" produces. Any value
+  # works for a throwaway database - it is the key the app derives its Active
+  # Record encryption keys from, and nothing here survives the run.
+  secret-key-base: 3f786850e387550fdab836ed7e6dc881de23001b3f786850e387550fdab836ed7e6dc881de23001b3f786850e387550fdab836ed7e6dc881de23001b3f786850
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: ci-sure-db-secret
+stringData:
+  host: postgres
+  port: "5432"
+  database: sure
+  username: ci
+  password: ci
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: ci-sure-redis-secret
+stringData:
+  connection-url: redis://:cipass@redis:6379/0
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: postgres
+  labels:
+    app: postgres
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: postgres
+  template:
+    metadata:
+      labels:
+        app: postgres
+    spec:
+      containers:
+        - name: postgres
+          image: public.ecr.aws/docker/library/postgres:16-alpine
+          env:
+            - name: POSTGRES_USER
+              value: ci
+            - name: POSTGRES_PASSWORD
+              value: ci
+            - name: POSTGRES_DB
+              value: sure
+          ports:
+            - containerPort: 5432
+          readinessProbe:
+            exec:
+              command: ["pg_isready", "-U", "ci"]
+            periodSeconds: 5
+          volumeMounts:
+            - name: data
+              mountPath: /var/lib/postgresql/data
+      volumes:
+        - name: data
+          emptyDir: {}
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: postgres
+spec:
+  selector:
+    app: postgres
+  ports:
+    - port: 5432
+      targetPort: 5432
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: redis
+  labels:
+    app: redis
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: redis
+  template:
+    metadata:
+      labels:
+        app: redis
+    spec:
+      containers:
+        - name: redis
+          image: public.ecr.aws/docker/library/redis:7-alpine
+          args: ["redis-server", "--requirepass", "cipass"]
+          ports:
+            - containerPort: 6379
+          readinessProbe:
+            tcpSocket:
+              port: 6379
+            periodSeconds: 5
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis
+spec:
+  selector:
+    app: redis
+  ports:
+    - port: 6379
+      targetPort: 6379

ci/sure/settings.env

@@ -0,0 +1,6 @@
+# The first start of the web container creates and migrates the whole Rails
+# schema ("./bin/rails db:prepare", run by the image entrypoint) before Puma
+# binds its port, and the worker container only registers with Sidekiq once
+# that schema exists. Both startup probes budget 600s for it, so the rollout
+# wait has to be longer than a single startup budget, not shorter.
+INSTALL_TIMEOUT=900

ci/sure/test-values.yaml

@@ -0,0 +1,10 @@
+secrets:
+  appSecretRef: op://ci/sure-app
+  dbSecretRef: op://ci/sure-db
+  redisSecretRef: op://ci/sure-redis
+
+ingress:
+  domain: sure.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

ci/trivy/trivyignore.yaml

@@ -24,7 +24,7 @@ misconfigurations:
     statement: "No CPU limits, on purpose: CPU is compressible, so a limit throttles where the missing limit merely shares - see README 'Resources (auto-limits)'. The chart helper renders a CPU limit only when one is set explicitly."
 
   - id: AVD-KSV-0020
-    statement: "UIDs are pinned to the value the image expects, not raised above 10000: minecraft-server 1000 (gosu default), teamspeak-server 9987, voucher-vault 33, the matrix-synapse delegation nginx 101. calibre-web-automated shows the risk - a runtime uid moving from 1000 to 911 makes existing volume data inaccessible, and every chart with a PVC carries that same risk class."
+    statement: "UIDs are pinned to the value the image expects, not raised above 10000: minecraft-server 1000 (gosu default), teamspeak-server 9987, voucher-vault 33, the matrix-synapse delegation nginx 101, sure 1000 (its Dockerfile declares USER 1000:1000). calibre-web-automated shows the risk - a runtime uid moving from 1000 to 911 makes existing volume data inaccessible, and every chart with a PVC carries that same risk class."
 
   - id: AVD-KSV-0021
     statement: "GIDs follow the pinned UIDs above; the same image expectation and the same PVC ownership risk apply."