Error validation chart metadata is required - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Helm: Error: validation: chart.metadata is required when using —repo
All 24 comments
Error chart.metadata is required when using modules with same name as helm release #509
Comments
Terraform Version and Provider Version
Provider Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Steps to Reproduce
Error: validation: chart.metadata is required when using —repo #6864
Comments
helm install gitlab gitlab —repo https://charts.gitlab.io does not work (Error: validation: chart.metadata is required) #8349
Comments
Footer

I am trying to upgrade/install a chart in my cluster. I want to load the chart «on the fly» from a remote without configuring the repo beforehand (running this process on CI).

For some reason I get

Downloading the chart first and installing it from local .tgz is working as expected. Also it’s working installing it from a local configured repository. It seems to affect only the —repo approach.index.yaml from the repo seems fine also to me.

Output of helm version :

Output of kubectl version :

is the error message which is displayed if there’s no Chart.yaml file in the working directory. The issue can be reproduced with

This should be improved by making helm say that Chart.yaml does not exist because that’s the cause for the error.

@pniederlag I tried to reproduce this. The only way that worked was — creating a bad chart, one without Chart.yaml (chart metadata); then creating a tar ball using tar as helm package returned error. And then creating an index for it manually as using helm repo index also didn’t work for an invalid chart. And then I tried to run a command similar to what you provided —

and it gave the above error.

So with current experimentation and findings I can only say the chart was probably a bad chart. But you said downloading and installing from local tar ball worked and it also worked with an already configured repo. So, I’m confused, because if it worked that way, it means it wasn’t a bad chart.

Could you help us with more details to reproduce the error?

Thx for taking a look onto it. Unfortunatly the repo and chart are none public.

Here are two more observations

helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz . [WORKS]
helm upgrade chart chart —repo https://repo.example.com/helm-repo —version 0.5.0 [FAILS WITH missing metada]

It’s really puzzling me. Is there any way I can debug helm fetching and scanning the index from the repositiory? As it is working also with another chart one more thing that comes to my mind is:

I am failing on chart «chart», there are also some more, unrelated charts «chart-other» in our repo.

As workaround I’ll just head for the explicit helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz approach.

Thx for your efforts on helm and your prompt feedback.

That’s weird. The commands you showed, look logically the same, as behind the scenes, same chart needs to be installed. Just different ways to do it.

For debugging repo index, you can actually download the repository index using the /index.yaml , in your case, it would be https://someartifactory.example.com/some-helm-repo/index.yaml , here you can look for the chart using find in your editor with the chart name and there will be multiple versions under it. Here’s an example:

in my index, only one version of each chart is present. In your case, more versions will be present. So, just look for the chart name and particular version you are trying to install, and then see what urls are present in it, it has to be ideally — .tgz . I’ll leave it to you debug 😄

I’m also getting this when trying to install the elasticsearch chart from their repo.

It does work when I’m fetching the chart and installing it locally

@eladitzhakian could you also provide which version of helm you are using? And the version of elasticsearch chart by doing a helm search elasticsearch ? This will help us debug the problem further 😄

I was getting the same error when trying to install from a tgz file.
The issue as it turned out was — helm was expecting the file name as «Chart.yaml» .
However the way archive file was packaged , chart was packaged as «dir/Chart.yaml».
This was causing the mismatch failure «Chart.yaml» != «dir/Chart.yaml»
leading to error Error: validation: chart.metadata is required

Hi, I meet this problem of the stable/metrics-server

When I use a local repo cache it works.
helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm install metrics-server stable/metrics-server

However, when I try to use —repo I meet the problem
helm install metrics-server metrics-server —repo https://kubernetes-charts.storage.googleapis.com
Error: validation: chart.metadata is required

@topikachu — Works fine for me

/go/src/helm.sh/helm/bin$ ./helm install metrics-server metrics-server —repo https://kubernetes-charts.storage.googleapis.com
NAME: metrics-server

I found that installing from rancher-stable produces this as well:

Versions of helm and the rancher chart are included above.

However, when I install from a local repo all is fine:
«`
$ helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
$ helm install rancher rancher-stable/rancher —set hostname=rancher.somewhere.com —atomic —namespace cattle-system —version 2.3.3 —set tls=external
NAME: rancher
LAST DEPLOYED: Fri Jan 3 23:21:43 2020
NAMESPACE: cattle-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Rancher Server has been installed.

NOTE: Rancher may take several minutes to fully initialize. Please standby while Certificates are being issued and Ingress comes up.

I dug a little deeper this morning, and started with the repo’s index.yaml:

I also searched for the string chart.metadata is required to find out if the validation is different between the two options.

When the function on line 68 is invoked, md must be nil at that point to cause the line 70 error to be seen. So I hunted for any calls of this function and found:

Since the error is not wrapped with «chart validation», I’m guessing the error I encountered yesterday bubbled up from chart/loader/load.go . At this point, it becomes hard for me to continue to trace where to go. As I am not familiar with Go, figuring out how the —repo switch makes it to the LoadFiles function is something that would take more time than I care to give. I did try to see if any of the install tests cover the —repo option, but I couldn’t find any in https://github.com/helm/helm/blob/v3.0.2/cmd/helm/install_test.go

Hopefully someone more knowledgeable with this project and Go can figure out the issue here.

@eladitzhakian ran into the same issue with a different install and argument order seemed to fix it.

$ helm install elastic/elasticsearch elastic # didn’t work
$ helm install elastic elastic/elasticsearch # did work

Worked for me. It expected case sensitive Chart.yaml file name.

Chart.yaml must be named exactly like this. Chart.yml or chart.yaml will both throw said error.

is the error message which is displayed if there’s no Chart.yaml file in the working directory. The issue can be reproduced with

This should be improved by making helm say that Chart.yaml does not exist because that’s the cause for the error.

I’ve encountered the same issue and in my case having a local folder with the same name as the chart name was the root cause of the issue, looks like —repo will be ignored if helm find a local folder, but local folder doesn’t have the Chart.yaml file.

Same case as @mforutan (thanks for mentioning it). I think the inline repo defined should take precedence and have the local dir as a fallback.

@PCatinean, I raised a bug: #7862 and then created a PR to fix inline repo: #7874, hopefully it will be merged soon

I have pointed out on that issue that changing precedence order is a breaking change, and cannot be done until Helm 4: https://github.com/helm/helm/blob/master/CONTRIBUTING.md#semantic-versioning

I agree that —repo should take precedence. but the fact of the matter is that it does not, and never has. Changing it mid-stream would violate our SemVer constraints.

That covers only part of this issue’s surface area, so I am leaving this issue open for that, and will mark the #7862 bug as deferred until Helm 4.

I can confirm this with rancher server as well and minio.

getting the same on umbrella charts with repository: file://. for command helm dep build .

chart otherwise works fine

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Источник

I am using following project structure:

When i run terraform apply i will get a chart.metadata is required .

When i change the name of the module directory.

. and change the module source.

. and run terraform apply again it works:

Terraform Version and Provider Version

Provider Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Steps to Reproduce

terraform init
terraform apply

The text was updated successfully, but these errors were encountered:

I don’t think it’s related to module, as I have just got the same error without using modules.

I switched away from

to a direct url

Terraform wanted to apply this change (why?)
and now I get this

It seems it is connected to helm/helm#7862.

Here the explanation:

But, inside the function LocateChart that finds the chart it looks on the local filesystem before checking if a repo is explicitly set. If the local chart is there that is used.

I did run helm repo update and then terraform apply again — the issue has gone.
So it most certainly is related to the abovementioned issue.

I got into this again. Apparently, I have a subdirectory named flux in the directory with the rest of the terraform files. And helm_release named flux as well. So I renamed the flux directory and it did the trick.

I got into this again. Apparently, I have a subdirectory named flux in the directory with the rest of the terraform files. And helm_release named flux as well. So I renamed the flux directory and it did the trick.

Exactly, im storing chart in s3 and i had to change the chart name because of a local directory named the same. For me this is utter bullsh. If im pointing to a repository for a place where it should look for a chart im expecting it wont look for it anywhere else. And the error «validation: chart.metadata is required» says nothing 0_o For some reason in mentioned «bug report», few posts above they seem to describe this behavior as intended 0_o

Jumped into the same issue, renaming the folder does the trick! Thanks for saving my day!

Источник

I am trying to upgrade/install a chart in my cluster. I want to load the chart «on the fly» from a remote without configuring the repo beforehand (running this process on CI).

For some reason I get

Output of helm version :

Output of kubectl version :

The text was updated successfully, but these errors were encountered:

@pniederlag I tried to reproduce this. The only way that worked was — creating a bad chart, one without Chart.yaml (chart metadata); then creating a tar ball using tar as helm package returned error. And then creating an index for it manually as using helm repo index also didn’t work for an invalid chart. And then I tried to run a command similar to what you provided —

and it gave the above error.

Could you help us with more details to reproduce the error?

Thx for taking a look onto it. Unfortunatly the repo and chart are none public.

Here are two more observations

helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz . [WORKS]
helm upgrade chart chart —repo https://repo.example.com/helm-repo —version 0.5.0 [FAILS WITH missing metada]

It’s really puzzling me. Is there any way I can debug helm fetching and scanning the index from the repositiory? As it is working also with another chart one more thing that comes to my mind is:

I am failing on chart «chart», there are also some more, unrelated charts «chart-other» in our repo.

As workaround I’ll just head for the explicit helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz approach.

Thx for your efforts on helm and your prompt feedback.

That’s weird. The commands you showed, look logically the same, as behind the scenes, same chart needs to be installed. Just different ways to do it.

Источник

helm install gitlab gitlab —repo https://charts.gitlab.io does not work (Error: validation: chart.metadata is required) #8349

When trying to deploy a chart that needs a specific repo (like gitlab), helm install fails into an error.

If the repo is already present locally (helm repo add https://charts.gitlab.io) , the following command works

Output of helm version :
version.BuildInfo

Cloud Provider/Platform (AKS, GKE, Minikube etc.): kind
kind v0.7.0 go1.13.6 linux/amd64

So it seems that the option —repo has some bug.

It affects currently the use of helm in devspace tool kit.

The text was updated successfully, but these errors were encountered:

Thanks for raising the issue @domrod . I have tried to reproduce the issue as follows:

The —repo flag seems to be working as expected.

The error Error: validation: chart.metadata is required usually relates to an issue with the chart metadata file. When you installed with the repo added to your repo list, you might be installing a different version of the chart which is valid and doesn’t have the issue.

Might be worth asking in gitlab charts.

I attempted to reproduce this with gitlab. I ran..

I did not get an error. It installed.

Could you use the —debug flag to see if there is more information.

I’m experiencing the same problem while installing Rancher.

Installing from the predefined repo ( helm repo add rancher-stable https://releases.rancher.com/server-charts/stable ) work properly:

But the same installation fails when passing the repository as argument ( —repo https://releases.rancher.com/server-charts/stable ):

Output of helm version :

Output of kubectl version :

I’m using the Terraform and the Helm provider to deploy the chart. Since in the background the Helm provider use the —repo argument, I’m not able to predefine the repository as a workaround.
Thus I would be happy to get any help with this problem.

As far as I understood, it depends if you have a Gitlab Helm chart file or directory in the directory of your project.

@hickeyma gave this explanation also here.

For now, it works on my side by removing all previous Gitlab Helm harts I had for reference purpose.

Part of my devspace.yaml has now the following structure.

In the file overlays/dev/gitlab/helm-values.yaml , I just add some custom variables that change from the default values.yaml file from Gitlab Helm chart.

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

I have the full explanation now.

If you have a directory with the same name as the chart you want to deploy (for instance here gitlab) , devspace default behavior will be to take this directory as the chart repository (see https://devspace.sh/cli/docs/configuration/deployments/helm-charts, see Local Chart folder).
The workaround to have custom values is to have a directory with a different root name (for instance ./config/gitlab), and everything will work fine.

Thanks @domrod for the explanation. Is this good to close now, or are there action items still left to resolve here?

I guess we can close this issue now.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

@pniederlag I tried to reproduce this. The only way that worked was — creating a bad chart, one without Chart.yaml (chart metadata); then creating a tar ball using tar as helm package returned error. And then creating an index for it manually as using helm repo index also didn’t work for an invalid chart. And then I tried to run a command similar to what you provided —

$ helm upgrade test test --install --repo http://localhost:5000
Release "test" does not exist. Installing it now.
Error: validation: chart.metadata is required

and it gave the above error.

Could you help us with more details to reproduce the error?

Thx for taking a look onto it. Unfortunatly the repo and chart are none public.

Here are two more observations

helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz … [WORKS]
helm upgrade chart chart —repo https://repo.example.com/helm-repo —version 0.5.0 [FAILS WITH missing metada]

It’s really puzzling me. Is there any way I can debug helm fetching and scanning the index from the repositiory? As it is working also with another chart one more thing that comes to my mind is:

I am failing on chart «chart», there are also some more, unrelated charts «chart-other» in our repo.

As workaround I’ll just head for the explicit helm upgrade chart https://repo.example.com/helm-repo/chart-0.5.0. tgz approach.

Thx for your efforts on helm and your prompt feedback.

That’s weird. The commands you showed, look logically the same, as behind the scenes, same chart needs to be installed. Just different ways to do it.

For debugging repo index, you can actually download the repository index using the <repo-url>/index.yaml , in your case, it would be https://someartifactory.example.com/some-helm-repo/index.yaml, here you can look for the chart using find in your editor with the chart name and there will be multiple versions under it. Here’s an example:

apiVersion: v1
entries:
  blah:
  - apiVersion: v2
    appVersion: "72551e2"
    created: "2019-11-05T22:19:34.854835+05:30"
    description: A Helm chart for Kubernetes
    digest: 63176e7bf7ef6a056b75679e2fee78c168cf8fbc64552e62733b7c0eb3992b0e
    name: blah
    type: application
    urls:
    - blah-0.1.0.tgz
    version: 0.1.0
  meh:
  - apiVersion: v2
    appVersion: abcdef123
    created: "2019-11-05T22:19:34.85567+05:30"
    description: A Helm chart for Kubernetes
    digest: d4a55417c8e6825796c7c588466a264b99f3a7d1db6d71340ed4805e1b4790e2
    name: meh
    type: application
    urls:
    - meh-0.1.0.tgz
    version: 0.1.0
  test-chart:
  - apiVersion: v1
    appVersion: "1.0"
    created: "2019-11-05T22:19:34.856514+05:30"
    description: A Helm chart for Kubernetes
    digest: f3fa81e7ff38f1f3a981f0bf9cc5edab707493effae03007aec5328d89a71dc9
    name: test-chart
    urls:
    - test-chart-0.1.0.tgz
    version: 0.1.0
generated: "2019-11-05T22:19:34.851122+05:30"

I’m also getting this when trying to install the elasticsearch chart from their repo.

$ helm repo add elastic https://helm.elastic.co
"elastic" has been added to your repositories
$ helm install elastic/elasticsearch elastic
Error: validation: chart.metadata is required

It does work when I’m fetching the chart and installing it locally

@eladitzhakian could you also provide which version of helm you are using? And the version of elasticsearch chart by doing a helm search elasticsearch? This will help us debug the problem further 😄

I found that installing from rancher-stable produces this as well:

$ helm version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}
$ helm install rancher rancher --set hostname=rancher.somewhere.com --atomic --repo https://releases.rancher.com/server-charts/stable --namespace cattle-system --version 2.3.3 --set tls=external
Error: validation: chart.metadata is required

Versions of helm and the rancher chart are included above.

NOTE: Rancher may take several minutes to fully initialize. Please standby while Certificates are being issued and Ingress comes up.

Check out our docs at https://rancher.com/docs/rancher/v2.x/en/

Browse to https://rancher.somewhere.com

Happy Containering!«`

I dug a little deeper this morning, and started with the repo’s index.yaml:

apiVersion: v1
entries:
  rancher:
  - apiVersion: v1
    appVersion: v2.3.3
    created: "2019-11-27T19:28:17.774253615Z"
    description: Install Rancher Server to manage Kubernetes clusters across providers.
    digest: b5bcc4c59319f9a096f60f7e6a4637b34f81850c532feb113749c36d7d2fe7f4
    home: https://rancher.com
    icon: https://github.com/rancher/ui/blob/master/public/assets/images/logos/welcome-cow.svg
    keywords:
    - rancher
    maintainers:
    - email: [email protected]
      name: Rancher Labs
    name: rancher
    sources:
    - https://github.com/rancher/rancher
    - https://github.com/rancher/server-chart
    urls:
    - rancher-2.3.3.tgz
    version: 2.3.3
  - apiVersion: v1
    appVersion: v2.3.2
    created: "2019-10-28T23:40:58.578877905Z"

I also searched for the string chart.metadata is required to find out if the validation is different between the two options.

https://github.com/helm/helm/blob/19e47ee3283ae98139d98460de796c1be1e3975f/pkg/chart/metadata.go#L68-L71

When the function on line 68 is invoked, md must be nil at that point to cause the line 70 error to be seen. So I hunted for any calls of this function and found:

https://github.com/helm/helm/blob/19e47ee3283ae98139d98460de796c1be1e3975f/pkg/chart/loader/load.go#L146-L148
https://github.com/helm/helm/blob/19e47ee3283ae98139d98460de796c1be1e3975f/pkg/chartutil/save.go#L89-L100

Since the error is not wrapped with «chart validation», I’m guessing the error I encountered yesterday bubbled up from chart/loader/load.go. At this point, it becomes hard for me to continue to trace where to go. As I am not familiar with Go, figuring out how the --repo switch makes it to the LoadFiles function is something that would take more time than I care to give. I did try to see if any of the install tests cover the --repo option, but I couldn’t find any in https://github.com/helm/helm/blob/v3.0.2/cmd/helm/install_test.go

Hopefully someone more knowledgeable with this project and Go can figure out the issue here.

@eladitzhakian ran into the same issue with a different install and argument order seemed to fix it.

$ helm install elastic/elasticsearch elastic # didn’t work
$ helm install elastic elastic/elasticsearch # did work

Chart.yaml must be named exactly like this. Chart.yml or chart.yaml will both throw said error.

Error: validation: chart.metadata is required

is the error message which is displayed if there’s no Chart.yaml file in the working directory. The issue can be reproduced with

cd $(mktemp -d)
helm dependency update

This should be improved by making helm say that Chart.yaml does not exist because that’s the cause for the error.

I’ve encountered the same issue and in my case having a local folder with the same name as the chart name was the root cause of the issue, looks like --repo will be ignored if helm find a local folder, but local folder doesn’t have the Chart.yaml file.

Same case as @mforutan (thanks for mentioning it). I think the inline repo defined should take precedence and have the local dir as a fallback.

@PCatinean, I raised a bug: #7862 and then created a PR to fix inline repo: #7874, hopefully it will be merged soon

I have pointed out on that issue that changing precedence order is a breaking change, and cannot be done until Helm 4: https://github.com/helm/helm/blob/master/CONTRIBUTING.md#semantic-versioning

I agree that --repo should take precedence… but the fact of the matter is that it does not, and never has. Changing it mid-stream would violate our SemVer constraints.

That covers only part of this issue’s surface area, so I am leaving this issue open for that, and will mark the #7862 bug as deferred until Helm 4.

I can confirm this with rancher server as well and minio.

getting the same on umbrella charts with repository: file://... for command helm dep build ...

chart otherwise works fine

version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"dirty", GoVersion:"go1.14.3"}

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

Источник

Error: validation: chart.metadata.version is required on helm package even though —version is used

Output of helm version:
version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}

Output of kubectl version: n/a

Cloud Provider/Platform (AKS, GKE, Minikube etc.): n/a

helm package always requires the version field to be set in the Chart.yaml, even if the --version flag is set. Otherwise helm exits with Error: validation: chart.metadata.version is required.

Since helm package ignores the version from the Chart.yaml anyway if it is provided via command line it seems unnecessary and a bit confusing to still require it.

There are two roles or parts in this.

First, there is defining a chart (package). This is done by the chart creator. Often times the people who do this are at a different company from those who consume the charts. The charts that are released for consumption need a version and it is supplied here. Think of using apt, yum, or zypper. The packages you consume there are versioned. Same with Helm charts and the version is specified in the _Chart.yamlfilesversion` field. This field is a semantic version.

Second, there is someone consuming a chart. If they use a command like helm install on a chart in a repository and do not specify a version then Helm will pick the most recent semantic version. It uses semantic version rules to determine the latest stable version in that repository. When the --version flag is used you can chose a specific version.

When you specify the version at the command line to use a chart then Helm needs to have the version of the chart available to check the version to determine the right version to use.

The version property is propagated around the Helm tooling. For example, this property is used when generating the index used in a Helm repository.

If the version property were not specified, how would the --version flag be able to work in getting a specific version?

Thanks for the explanation @mattfarina !
And apologies, I just realized that my original issue description was not particularly clear.
My issue is only with helm package. Of course with other commands it doesn’t make much sense.

Basically what I want to do is define the version somewhere else. In my case in a Makefile variable which is then passed to all necessary build steps, among others helm package via the --version flag. This was possible with helm 2 but gives the above mentioned error since I upgraded to helm 3.

I updated the description of the issue accordingly.

It is not just —version though that applies directly to the error but given a chart file that looks like…

apiVersion: v2
name: foo
description: |
  foo
type: application

the following package command fails as follows

$ helm package --app-version <version from build tooling> --version <version from build tooling> -u foo
Error: validation: chart.metadata.version is required

This is also the case if the version and appVersion keys are supplied in the Chart.yaml but left blank, but the command will succeed if any value is provided in those keys.

Leaving these keys blank or absent seems the cleanest setup for a helm chart that will get versioned with the underlying code as it’s built. the values of app-version and version being passed down through the build system.

manno

Feature Request:

helm package should not validate the chart.metadata.version or chart.metadata.appVersion if their «setter» cli flags are passed (as long as the values passed are valid semver).

re-labeling as a bug. I agree that the following use case should be valid:

><> cat Chart.yaml
apiVersion: v2
name: test-9298
description: A Helm chart for Kubernetes
type: application
appVersion: "1.16.0"
><> helm package --version 0.1.0 .
Error: validation: chart.metadata.version is required

Unfortunately I believe this case is blocked because due to security issues with Go’s YAML parser, we had to enable strict validation. If a field is missing, it fails YAML parsing altogether. So we don’t get the opportunity to overlay the version into the parsed object before failing validation.

For reference, the strict parser is in place to prevent cases where a field can be overridden by re-declaring it a second time:

><> cat Chart.yaml
apiVersion: v2
name: test-9298
description: A Helm chart for Kubernetes
type: application
appVersion: "1.16.0"
version: "1.0.0"
version: "2.0.0"
><> helm package .
Successfully packaged chart and saved it to: /tmp/test-9298/test-9298-2.0.0.tgz

This becomes especially dangerous in cases like a plugin.yaml which can define install hooks. Exploiting this flaw can result in RCE attacks.

Currently, there is no way to tell the YAML parser to check for duplicate keys without enabling strict parsing. Fix that, and we can handle cases like the one raised by the OP.

My apologies. It’s actually because when loading the chart from disk, we validate the contents before overlaying things like the --version flag. The UnmarshalStrict case doesn’t come into play with helm package.

if err := c.Validate(); err != nil {

In most cases this makes sense as a chart loaded from disk should have a valid version field present. But perhaps we can handle this case differently… Either by loading the contents from disk, overlay the new values, THEN call .Validate. But this will likely require a new function signature.

urton

Any updates on this? I ran into this issue today after upgrading my client from 3.2.1 to 3.6.2 and trying to package a chart. We use placeholders in our Chart.yaml for version and then set the version when packaging, but this failed with both the 3.6.2 and 3.5.2 clients:

$ helm package . --app-version 2.6.0.1 --version=2.6.4
Error: validation: chart.metadata.version "2.6.x" is invalid

I downgraded to 3.4.2 and was able to package again.

kimba74

@bacongobbler it looks like this issue got introduced with version v3.5.2

The Validate() function in pkg/chart/metadata.go looks like the following in v3.5.1:

func (md *Metadata) Validate() error {
	if md == nil {
		return ValidationError("chart.metadata is required")
	}
	if md.APIVersion == "" {
		return ValidationError("chart.metadata.apiVersion is required")
	}
	if md.Name == "" {
		return ValidationError("chart.metadata.name is required")
	}
	if md.Version == "" {
		return ValidationError("chart.metadata.version is required")
	}
	if !isValidChartType(md.Type) {
		return ValidationError("chart.metadata.type must be application or library")
	}

	// Aliases need to be validated here to make sure that the alias name does
	// not contain any illegal characters.
	for _, dependency := range md.Dependencies {
		if err := validateDependency(dependency); err != nil {
			return err
		}
	}

	// TODO validate valid semver here?
	return nil
}

While the same function in v3.5.2 has the SemVer check built in:

func (md *Metadata) Validate() error {
	if md == nil {
		return ValidationError("chart.metadata is required")
	}

	md.Name = sanitizeString(md.Name)
	md.Description = sanitizeString(md.Description)
	md.Home = sanitizeString(md.Home)
	md.Icon = sanitizeString(md.Icon)
	md.Condition = sanitizeString(md.Condition)
	md.Tags = sanitizeString(md.Tags)
	md.AppVersion = sanitizeString(md.AppVersion)
	md.KubeVersion = sanitizeString(md.KubeVersion)
	for i := range md.Sources {
		md.Sources[i] = sanitizeString(md.Sources[i])
	}
	for i := range md.Keywords {
		md.Keywords[i] = sanitizeString(md.Keywords[i])
	}

	if md.APIVersion == "" {
		return ValidationError("chart.metadata.apiVersion is required")
	}
	if md.Name == "" {
		return ValidationError("chart.metadata.name is required")
	}
	if md.Version == "" {
		return ValidationError("chart.metadata.version is required")
	}
	if !isValidSemver(md.Version) {
		return ValidationErrorf("chart.metadata.version %q is invalid", md.Version)
	}

	...

	return nil
}

While the Run() method of the helm package command would actually respect the provided --version flag:

func (p *Package) Run(path string, vals map[string]interface{}) (string, error) {
        ...

	if p.Version != "" {
		ch.Metadata.Version = p.Version
	}

	if err := validateVersion(ch.Metadata.Version); err != nil {
		return "", err
	}

       ...
}

it never gets to that point because the metadata of the Chart is being parsed AND validated at the time the files are being loaded.

While the early validation certainly works for most of the other, if not all of the other commands it doesn’t work for package where you can provide a version via the --version flag.

To fix this there would only really be two options I could see:

Make the parsing «aware» of what command has been invoked (i.e. disable the version check for package via flag)
Turn it off by default and have the individual command validate it like package is actually trying to do

Cheers,

Kimba

kimba74

Looks like the «Fix» #2bf5c28 is what «broke» it for helm package

@kimba74 yes, however the fix was put in place to fix a security issue. Please have a read through GHSA-c38g-469g-cmgx.

If you can determine a fix without re-introducing that security issue (I mentioned a potential solution in an earlier comment) that would be helpful. But with the current architecture in the code that was the only way to fix the security issue. So a new code path may have to be introduced to provide this feature.

@bacongobbler I’m a little confused, because of 9 and 10 on https://semver.org/ relating to pre-release versions of something.

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

I know I am getting errors, but my pre-release versions follow this pattern, and you link directly to the semver site that states this information here: https://helm.sh/docs/chart_best_practices/conventions/#version-numbers

An example of one of my pre-release versions is: 1.1.25-dev.1-mcp-3583.0874667 , and yet when I try to use the latest versions of helm I get errors like this::

index.go:339: skipping loading invalid entry for chart «webhook-service» «1.1.25-dev.1-mcp-3583.0874667» from https://my.artifactory.url : validation: chart.metadata.version «1.1.25-dev.1-mcp-3583.0874667» is invalid

Pre-release version numbers cannot contain more than ONE hyphen. The Backus-Naur Form Grammar section defines this in pseudo-code.

The relevant sections:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

<pre-release> ::= <dot-separated pre-release identifiers>

<dot-separated build identifiers> ::= <build identifier>
                                    | <build identifier> "." <dot-separated build identifiers>

<build identifier> ::= <alphanumeric identifier>
                     | <digits>

In other words, this is NOT valid:

1.1.25-dev.1-mcp-3583.0874667

But this is:

1.1.25-dev.1.mcp.3583.0874667

Then number 9 is wrong, because one of the examples is clearly, but thanks for the response.

1.0.0-x-y-z.–

I’m sure the semver.org maintainers would appreciate the heads up if you’d like to raise it with them, as that’s in direct conflict with the specification.

Oh, and it looks like numerical values with leading zeroes are invalid too. So you have to remove the leading zero from the last part of the version number.

1.1.25-dev.1.mcp.3583.874667

I noticed that as well just now.

Источник