When range support for OCI went in via #10527 it created a situation
where some lookups for a chart could cause a panic. This change
makes sure the registry client is available to lookup OCI charts
Signed-off-by: Matt Farina <matt.farina@suse.com>
Note, there is OCI handling later in the funtion that should
handle the situation instead.
Closes#10534
Signed-off-by: Matt Farina <matt.farina@suse.com>
Largely borrowed from (IndexFile).Get. However there is not currently a nice
way to make this code also usable to the repo package, as IndexFile depends on
a list of index Entries containing a nexted version.
We could refactor this later to somehow use the same shared function, but for
now keeping separate.
Signed-off-by: Scott Rigby <scott@r6by.com>
Note, there is OCI handling later in the funtion that should
handle the situation instead.
Closes#10534
Signed-off-by: Matt Farina <matt.farina@suse.com>
The partition value can be greater than number of replicas, in that
case no pods are rolled out. The expectedReplicas becomes a negative
number.
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#partitions
In the cases where the update does not change anything in the pod
template, the updatedReplicas value from StatefulSet status remains
unchanged. Such updates can still set some partition value, and
UpdatedReplicas is always greater than expectedReplicas. Basically,
the StatefulSet is ready / rolled-out.
In both the above scenarios, providing `--wait` flag causes it to
timeout waiting indefinitely. Because updatedReplicas can never be
negative, or be equal to the expectedReplicas for the second case.
This commit handles both the scenarios by checking if UpdatedReplicas
is smaller than expectedReplicas. If it is, then the StatefulSet is
not ready yet.
Based on the code from kubectl rollout:
a450ebd59c/pkg/polymorphichelpers/rollout_status.go (L138-L141)Closes#8674
Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.com>
This bug came about because of three issues that this change
corrects:
- The CI scripts run on a pull request did not test building
Helm. This means that a failure to set a variable using LDFLAGS
had no opportunity to be caught.
- #8608 provided a means to match the k8s version used in linting
and chartutil with the version of the package we pull in. With
one problem. It attempts to set a const as if it were a string.
This is ignored and everyone missed it.
- #10325 moved those constants to vars so it could be set. This
looked good and passed tests but missed that you can't set an
int as if it were a string. See first bullet.
This change fixes this by moved the internal representation to
be a string. These are internal variables not exposed in the public
API which makes this change non-breaking to the API.
Closes#10367
Signed-off-by: Matt Farina <matt.farina@suse.com>
When running helm lint, import-values for dependencies are ignored,
also added test for linting chart with import-values
Closes#9658
Signed-off-by: Stuart Drennan <stuart.drennan@gmail.com>
Problem: the warnings don't give enough details about which
values are problematic, only the name of the leaf key. This is
all the more annoying when you have a chart depending on other charts.
```
mainchart
|
+- subchart1
+- subchart2
+- subchart3
```
Here are some warnings I get before the change:
```
coalesce.go:199: warning: destination for credentials is a table. Ignoring non-table value
coalesce.go:160: warning: skipped value for resources: Not a table.
coalesce.go:160: warning: skipped value for googleSheetsServiceAccount: Not a table.
coalesce.go:199: warning: destination for googleSheetsServiceAccount is a table. Ignoring non-table value
coalesce.go:199: warning: destination for resources is a table. Ignoring non-table value []
coalesce.go:199: warning: destination for credentials is a table. Ignoring non-table value
coalesce.go:199: warning: destination for credentials is a table. Ignoring non-table value
coalesce.go:160: warning: skipped value for resources: Not a table.
coalesce.go:160: warning: skipped value for googleSheetsServiceAccount: Not a table.
```
with fix:
```
coalesce.go:162: warning: skipped value for subchart1.resources: Not a table.
coalesce.go:162: warning: skipped value for subchart2.googleSheetsServiceAccount: Not a table.
coalesce.go:211: warning: destination for subchart3.aws.credentials is a table. Ignoring non-table value ()
coalesce.go:211: warning: destination for mainchart.subchart3.aws.credentials is a table. Ignoring non-table value ()
coalesce.go:211: warning: destination for mainchart.subchart2.googleSheetsServiceAccount is a table. Ignoring non-table value ()
coalesce.go:211: warning: destination for mainchart.subchart1.resources is a table. Ignoring non-table value ([])
coalesce.go:162: warning: skipped value for subchart1.resources: Not a table.
coalesce.go:162: warning: skipped value for subchart2.googleSheetsServiceAccount: Not a table.
coalesce.go:211: warning: destination for subchart3.aws.credentials is a table. Ignoring non-table value ()
```
Signed-off-by: Damien Nozay <damiennozay+github@gmail.com>
add tests
Signed-off-by: Damien Nozay <damiennozay+github@gmail.com>
This is a regression accidently introduced in #9957.
A delete call had been used on the Template key of vals. This caused
a condition where Template was not available when rendering via tpl.
The delete happened after ExecuteTemplate so the issue is surpsising.
It may possibly be a race condition. Existing tests did not catch it.
I tried to create a test that directly tested the issue and was
unable to replicate the error seen with real charts. This leads me
to believe it is a race condition in the underlying Go template
package.
The delete call was not there before #9957. It should be safe to
remove and keep that information.
Closes#10082
Signed-off-by: Matt Farina <matt.farina@suse.com>