jklein
b39f36ff5c
A JMAP webmail client for the stalwart chart (Gitea #65): StatefulSet, one PVC at /app/data, Service plus headless Service, Ingress at a host root, two OnePasswordItems, three probes, computed limits, replicas plus scaleDown, strict values.schema.json. Everything below was measured against the source at tag 1.12.0 rather than read out of the documentation, which was wrong about three of them. THE DEFINING PROPERTY: THE VOLUME BEATS THE CHART, FOR EVERY VALUE, SILENTLY. configManager.get resolves "admin override > env var > default", the admin dashboard may write any key of CONFIG_ENV_MAP, and nothing reports that it just disconnected the chart - so a helm upgrade can succeed and change nothing. Upstream documents this for the server URL only; it is true of everything. Exactly three values escape it (SESSION_SECRET(_FILE), ADMIN_PASSWORD, BULWARK_TELEMETRY). The value that closes it, bulwark.adminConfigReadOnly, defaults to false because its price is threefold: it freezes the settings policy (and with it the only way to move Web Push off the vendor relay), it freezes an override that ALREADY exists instead of removing it, and on a fresh install it stops admin.json from being written at all - so the admin dashboard never comes up and its login answers HTTP 500 while the pod stays Ready. OIDC-only sign-in, with the real way back out of a lockout: not helm upgrade with OAUTH_ONLY=false (oauthOnly goes through the same precedence chain) but removing the override in the admin dashboard. That is why ADMIN_PASSWORD is set - the dashboard is the door. It generates no random password and logs nothing, so the #65 analogy does not apply. SESSION_SECRET_FILE and OAUTH_CLIENT_SECRET_FILE are both used - the better path garage (#81) and keycloak (#83) did not have - in one projected volume mounted WITHOUT subPath, because both are re-read on every use and a subPath mount is never refreshed, and at mode 0440 because secret files are owned by root and fsGroup only supplies the group. Two backup statements, both at the value: without the session secret the synchronized settings are unreadable out of an intact volume, and if the dashboard's OAuth setup was ever used the client secret sits in config.json on that volume in cleartext. Probes: all three a plain GET on /api/health, with the limit written at the readiness value - it carries process, HTTP acceptance, a free event loop and Next.js routing, and nothing about the reported state or about Stalwart. No ConfigMap, so the checksum/config rule (#82) has nothing to attach to, and values.yaml says so explicitly; the op:// paths are covered by checksum/secret-ref. Renovate: no versioningTemplate, measured rather than assumed. 315 tags in eight shapes (releases, a second v-prefixed family of the same images, an -always flavour, floating minors and names, commit SHAs, betas, attestations) and plain docker versioning excludes all six unwanted ones. Dry runs at 1.12.0, 1.11.0 and 1.10.0 are recorded in the block. Part of #89 - deliberately not "Fixes", because one binding decision of the issue was changed out of necessity and wants ratification rather than an automatic close: the plan specifies HEAD /api/health for all three probes, and a Kubernetes probe cannot send HEAD at all (HTTPGetAction has no method field; the kubelet always issues GET). The alternative, an exec probe, would mean starting a Node process every few seconds in an image that carries no curl and no wget. GET is used instead and is marginally more capable than HEAD, so every limit the issue argues is unchanged - but the decision is the maintainer's to confirm.
37 lines
1.8 KiB
YAML
37 lines
1.8 KiB
YAML
apiVersion: v2
|
|
name: bulwark
|
|
description: A Helm chart to deploy Bulwark Webmail, a JMAP webmail client (mail, calendar, contacts, files) for a Stalwart mail server
|
|
icon: https://avatars.githubusercontent.com/u/266882946
|
|
|
|
type: application
|
|
|
|
# appVersion is the exact image tag of ghcr.io/bulwarkmail/webmail.
|
|
#
|
|
# THE SUFFIX-FREE FORM, AND THAT IS A CHOICE RATHER THAN THE ONLY OPTION. This
|
|
# registry publishes every release TWICE - 1.12.0 and v1.12.0 are the same image
|
|
# under two names (counted 2026-10-05 against the ghcr.io tags API: 315 tags, and
|
|
# both families run the whole way back to 1.3.9). So unlike stalwart, garage,
|
|
# matrix-synapse and calibre-web-automated, where the "v" IS the tag and
|
|
# therefore part of appVersion and of the "+up" suffix, here it is optional and
|
|
# this chart pins the form without it. Do not "normalize" it to v1.12.0 later:
|
|
# that would rewrite appVersion and the chart version for an identical image.
|
|
#
|
|
# The tag census, Renovate's handling of each shape and the three dry-run
|
|
# fixtures that prove it are in renovate.json5's bulwark block rather than
|
|
# duplicated here. The short version: eight tag shapes, six of them things
|
|
# nobody should pin, and plain `docker` versioning excludes all six - so that
|
|
# block deliberately carries NO versioningTemplate.
|
|
version: 1.0.0+up1.12.0
|
|
appVersion: "1.12.0"
|
|
|
|
maintainers:
|
|
- name: jklein
|
|
|
|
# NO DEPENDENCIES, and nothing here wants one. Bulwark is a client: it holds no
|
|
# mail, has no database, no cache and no broker. The mail server it talks to is
|
|
# the `stalwart` chart (Gitea #65), a SEPARATE RELEASE reached over the network
|
|
# by the URL in bulwark.jmapServerUrl - not a subchart, because the two are
|
|
# installed, scaled, upgraded and backed up independently and a JMAP endpoint is
|
|
# an address rather than a bundled component. README, "Chart dependencies", for
|
|
# the bar a dependency has to clear.
|