Problem if appVersion is a number in scientific notation

[markusheiden]

Wrong escaping of appVersion if it is a number in scientific notation.

helm repo add..., e.g. for our GitLab pipeline helm repo add --force-update --username gitlab-ci-token --password ${CI_JOB_TOKEN} ${CI_PROJECT_NAME} ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/stable, results in:

Error: looks like "https://gitlab.com/api/v4/projects/12345678/packages/helm/stable" is not a valid chart repository or cannot be reached: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal number into Go struct field ChartVersion.entries.appVersion of type string

index.yaml from the GitLab Helm registry pushed with the ChartMuseum helm-push plugin and reduced to the problematic entry:

---
apiVersion: v1
entries:
  voluminator-backend:
    - name: voluminator-backend
      type: application
      version: 1.0.0+392065e2
      apiVersion: v2
      appVersion: 392065e2
      created: '2023-10-02T12:15:46.313353000Z'
      digest:
      urls:
        - charts/voluminator-backend-1.0.0+392065e2.tgz
generated: '2023-10-16T08:18:04.014125519Z'
serverInfo:
  contextPath: "/api/v4/projects/34739132/packages/helm"

Currently, we are using Helm 3.13.0.

I already reported this as helm/helm#12236 but it seems to be a ChartMuseum problem.

This problem already happened some years ago as #40.

[markusheiden]

I got the problem again with version 63366e78.

[djhoese]

Has there been any update on this? I've run into the same issue where a commit SHA used in appVersion is considered a float and gets similar errors to the ones mentioned above. Why are the version numbers not quoted in the produced index.yaml?

[djhoese]

Apparently this issue is the same as #40 from what I can tell and should have been fixed in #41. That was released (according to github) in v0.8.0.

[markusheiden]

I don‘t know what component exactly causes this problem, but I doubt that the GitLab repo uses that old code. So IMO that problem still persists.

[markusheiden]

A workaround is to add a letter to the appVersion. That triggers the correct escaping. E.g. use v392065e2 instead of just 392065e2.