fix: persist config directory to retain users and tokens (#6)

[robfrank]

Summary

Fixes #6.

The chart's persistence block only covered the database directory (/home/arcadedb/databases). ArcadeDB stores users, tokens, and server settings under /home/arcadedb/config, which had no PVC — so configured users and tokens were lost on pod restart while database data survived.

This adds an opt-in second PVC for the config directory.

Changes

• values.yaml: new arcadedb.configDirectory (default /home/arcadedb/config) and persistence.config.{enabled,size,accessMode,storageClass} sub-section. Disabled by default to preserve existing behavior.
• templates/statefulset.yaml: conditional arcadedb-config volumeMount and VolumeClaimTemplate driven by persistence.config.enabled.
• tests/statefulset_test.yaml: 8 new helm-unittest cases covering disabled-by-default, enabled rendering, size/storageClass/accessMode overrides, custom configDirectory, VCT ordering with the data PVC, and config-only persistence.

Usage

persistence:
  enabled: true       # database directory (existing)
  config:
    enabled: true     # NEW: persist users / tokens / server settings
    size: 1Gi

Note for upgraders

Kubernetes does not allow adding volumeClaimTemplates to an existing StatefulSet in place. Operators enabling persistence.config.enabled on an existing release must delete and recreate the StatefulSet (e.g. kubectl delete sts <name> --cascade=orphan then helm upgrade) for the new PVC to be created.

Test plan

• helm unittest charts/arcadedb — 126/126 pass (57 statefulset suite + 69 others)
• New tests cover both enabled and disabled paths
• No regressions in existing tests
• Manual verification on a kind cluster: deploy with persistence.config.enabled=true, create a user, restart the pod, verify the user survives

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces persistence for the ArcadeDB configuration directory by adding a new volume mount and volume claim template to the StatefulSet, along with corresponding configuration options in values.yaml and a comprehensive suite of unit tests. Feedback indicates that the ArcadeDB process must be explicitly informed of custom configuration paths via a system property in the container command to ensure the mount is utilized correctly. Additionally, it is recommended to update test assertions to avoid fragile hardcoded indices by matching volume claims by name.

[gemini-code-assist]

The mountPath is configurable via .Values.arcadedb.configDirectory, but the ArcadeDB process is not informed of this custom path in the command section. If a user overrides this value, the volume will be mounted at the new path, but the application will still look for configuration in the default /home/arcadedb/config directory. To support custom paths, the -Darcadedb.server.configurationDirectory property should be added to the container's command in templates/statefulset.yaml.

[gemini-code-assist]

The test assertions use hardcoded indices (e.g., spec.volumeClaimTemplates[1]) to verify the configuration PVC. This makes the tests fragile as they depend on the default state of other persistence settings (like persistence.enabled). If the default values change or if other volumes are added, these tests will fail. Consider using assertions that match by name or check the entire list for the expected object.

      - contains:
          path: spec.volumeClaimTemplates
          content:
            metadata:
              name: arcadedb-config
            spec:
              resources:
                requests:
                  storage: 5Gi