authup chart: provisioning mount breaks when the authup image moves its writable directory

[tada5hi]

authup/authup#3474 moves the authup image's writable directory from /usr/src/app/writable to /var/lib/authup (FHS location for mutable application state). Only the Dockerfile's WRITABLE_DIRECTORY_PATH moves; authup's code default is unchanged.

charts/third-party/authup pins image.tag: "latest" with pullPolicy: "Always", so this lands as soon as the image is published — no chart change required to trigger it.

Impact

charts/third-party/authup/values.yaml L31:

provisioning:
    mountPath: "/usr/src/app/writable/provisioning"

The deployment mounts the provisioning ConfigMap there (templates/deployment.yaml L149) and sets no WRITABLE_DIRECTORY_PATH, so it inherits the image default. After the image change the server scans /var/lib/authup/provisioning, which nothing is mounted at.

File-based provisioning silently stops being applied. The pod starts healthy, the ConfigMap is still mounted and still projected, and nothing in the log says the scanned directory was empty. It reads as a provisioning-content bug rather than a path bug, which is what makes it worth fixing ahead of the image rather than after.

The comment on L30 ("Must sit under the container's WRITABLE_DIRECTORY_PATH (default /usr/src/app/writable in the official image)") becomes wrong at the same moment.

Nothing else in the chart is affected: no emptyDir is mounted at the writable path, so log placement does not change, and the theme mount is immune for the reason given below.

Suggested fix

Set WRITABLE_DIRECTORY_PATH explicitly in templates/deployment.yaml rather than inheriting the image default — dir of provisioning.mountPath derives it with no new values key:

{{- if .Values.provisioning.enabled }}
  -   name: WRITABLE_DIRECTORY_PATH
      value: {{ dir .Values.provisioning.mountPath | quote }}
{{- end }}

This is exactly the shape the theme mount already uses (THEME_DIRECTORY_PATH from theme.mountPath, L58-61), and it is why the theme mount is unaffected by this change while provisioning is not: the theme path is asserted, the provisioning path is inferred. Asserting it makes the chart immune in both directions, so it keeps working against a pinned older image as well as the new one.

Then optionally move the mountPath default to /var/lib/authup/provisioning to match upstream, and refresh the L30 comment either way.

Upstream context

• PR: fix(server-core): writable directory defaults authup/authup#3474
• Upgrade note (mount diff and the WRITABLE_DIRECTORY_PATH=/usr/src/app/writable escape hatch for staying on the old location): docs/src/guide/deployment/upgrading.md
• Same class of issue in the official chart: Writable directory path is hardcoded to /usr/src/app/writable and breaks when appVersion moves past v1.0.0-beta.62 authup/helm#9