Idempotent Helm chart install action?

I wonder what stance is on idempotency of the CouchDB Helm chart install action? It seems to be a debated issue in the Helm world, but one which the CouchDB Helm Chart needs to relate to.

From what I can tell, most people treat Helm actions as something which doesn't belong in a CI/CD, for the reason that they cannot interpret if the given chart provides idempotency. Helm as such makes no promises and to my knowledge there's no best practice for Helm chart developers.

Below is presumably (?) the general way to make a helm 'install' action idempotent:

helm upgrade --install couchdb couchdb/couchdb         \
  --version "<fixed-value>"

rather than

helm install couchdb couchdb/couchdb

What is the problem?

With the CouchDB helm chart and with the desire to have the Secret automatically created on first-time install, this will not work. What happens is that the Secret will be updated with new values for every invocation. This will of course create havoc.

I don't know what the best solution is. CI/CD developers would want to put the helm action into their pipeline and as such they are looking for (expecting?) idempotency. At the very least, the CouchDB helm chart can document where it stands on this.

Ideas for improvements on CouchDB helm chart

In terms of making sure the chart action is idempotent, I believe the only potential culprit is the Secret. The other Kubernetes objects are okay to be re-applied (by design). Some ideas on the Secret: Look into the use of immutable Secrets introduced in Kubernetes 1.21 or maybe have a chart option createSecretIfNotExists. Or something.

Workaround

A workaround at the moment would be to do:

#!/bin/bash
# 
# check if already installed
if ! helm status -n $namespace couchdb &> /dev/null; then
  helm install couchdb couchdb/couchdb                           \
    --namespace $namespace                               \
    ...
fi

apache / couchdb-helm