Using the new(ish) chart-releaser tool would be a better solution than our current process.

If done properly, we should be able to have the same type of CI automation here that we enjoy with our internal charts.

It want to deploy the Helm chart with a proxy setting like this:

proxy:
    enabled: true
    hostname: abc.example.com

This cannot be parsed into a Kubernetes ressource because it generates a result like this:

...
          env:
            - name: SMTP_HOST
              value:
            - name: SMTP_PORT
              value: "25"
            - name: PROXY_BASE_URL
              value:
  https://abc.example.com
            - name: JVM_MAX_MEM
              value: "768"
...

Obviously there is a leading line feed inserted which is not from my values file. Does anybody know, how to fix this?

TLS cert generation fails when using the chart with cert-manager and lets encrypt. cert-manager fails complaining about missing host in the reuqest :

"ingress-shim controller: Re-queuing item "default/archiva-innect-xetusoss-archiva" due to error processing: secret "repo-tls" for ingress "archiva-innect-xetusoss-archiva" has no hosts specified"

The fix is to include hosts section in tls definition in the ingress.yaml template

  {{- if .Values.ingress.tls.enabled }}
  tls:
   - hosts:
      - {{ .Values.proxy.hostname }}
      secretName: {{ .Values.ingress.tls.secretName }} 
  {{- end }}

Overview

The Archiva Deployment does not configure an update strategy, which results in the default update strategy being used. Kubernetes' default update strategy is RollingUpdate with 25% maxUnavailable and 25% maxSurge:

spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  ...

Details

To best handle Archiva's persistence-based design the helm chart makes the opinionated but wise decision to hard-code 1 replica for the deployment. However, the default RollingUpdate maxUnavailable percentage means the following happens on updates to the deployment:

1. The Kubernetes controller notices that there is only 1 replica and does not terminate the existing Archiva pod since doing so would result in 100% unavailability (which is greater than the default 25% max unavailability);
2. The Kubernetes controller starts a new updated replacement pod;
3. The updated replacement pod fails to initialize because the PVC is already claimed by the existing Archiva pod, leading to a broken state that requires manual intervention (rollback).

This effectively means updates that modify the deployment pod require deleting and re-installing the helm release.

Proposal

After some testing I've confirmed this is fixed by setting maxSurge and maxUnavailable to 1. I think as long as the replica count is hardcoded to 1 it's reasonable to hard code the update strategy as well.

During setup in my cluster I followed https://github.com/xetus-oss/helm-charts/blob/master/README.md

There in it points to https://xetus-oss.github.io/helm-charts/

When browsing to https://xetus-oss.github.io/helm-charts/ I found a 404 page. Please assist

When I run a command
helm install --debug --namespace=mbp --set persistence.enabled=false archiva xetusoss/xetusoss-archiva
the relevant error message is:
install.go:173: [debug] Original chart version: "" Error: failed to fetch https://xetus-oss.github.com/helm-charts/xetusoss-archiva-0.2.0.tgz : 404 Not Found helm.go:81: [debug] failed to fetch https://xetus-oss.github.com/helm-charts/xetusoss-archiva-0.2.0.tgz : 404 Not Found

Maybe it is related "Subdomains of github.com are deprecated for GitHub Pages" - this I see, when I open the https://xetus-oss.github.com/helm-charts/xetusoss-archiva-0.2.0.tgz in browser - see attachment

Thanks a lot