The rangeint suggestion is faster.
The maps.Copy and slices.Contains are just syntatic sugar.
Signed-off-by: Mads Jensen <atombrella@users.noreply.github.com>
This is part of HIP 20 which provides a means to have v3 charts
that live alongside v2 charts while having breaking changes.
The plan is to have a different release object for v3 chart
instances for at least a couple reasons:
1. So that the chart object on the release can be fundamentally
different.
2. So that Helm v3 does not detect or try to work with instances
of charts whose apiVersion it does not know about.
Note: it is expected that Helm v3 usage will be used long after
the Helm project no longer supports it. 5 years after Helm v2
had reached end-of-life there was still usage of it.
Note: The release util package is separate from the versioned
elements as it is planned to use generics to handle multiple
release object versions.
Signed-off-by: Matt Farina <matt.farina@suse.com>
The releaseutil package was originally designed to work against a
generated codebase from a protobuf in Helm v2. This is when Helm
used gRPC to communicate to a server side component named Tiller.
When Helm moved everything client side, this package remained and
it supported the release package.
This change moves releaseutil to be a sub-packge of release. This
is part of the change to support apiVersion v3 charts which is
documented in HIP 20
Signed-off-by: Matt Farina <matt.farina@suse.com>
Since Helm is going through breaking changes with Helm v4, the version path to
Helm needs to be updated.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Noteis:
1. This moves golangci scanning to a GitHub action. This will
enable inline pointers to issues in the PR where linting fails.
2. Go 1.21 is specified in the go.mod because Kubernetes libs
require it.
3. The lint issues were removed. Some were fixed while others
were handled by skipping linting or using _ as an argument.
Many of these can be refactored later for better cleanup.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Helm release names are limited to 53 characters. By default, Release information is stored in Kubernetes as secrets, and the secret's name structure follows the pattern "sh.helm.release.v1.<release name up to 53 characters>.v<release revision>." However, in the case of using an SQL backend, this release information key is stored in the release_v1 table, and the table constraint currently limits the key name length to 67 characters. This limitation may not be suitable for release names that are within Helm's 53-character limit and need to accommodate the additional "sh.helm.release.v1." prefix and the release revision suffix.
Signed-off-by: abrarcv170 <78675575+abrarcv170@users.noreply.github.com>
