These maintainers have made tremendous contributions but are
currently inactive. I have connected with each of them and they
are focused on other work, at present. They all confirmed moving
to an emeritus status. If they ever want to return to active
development/maintainer-ship of Helm, I would be delighted.
The governance has a process for inactive folks and, as there are
items that need to be voted on, inactive maintainer make decision
making difficult.
These maintainers are and will continue to be missed.
Signed-off-by: Matt Farina <matt.farina@suse.com>
What this PR does / why we need it:
This PR was created to improve performance of the dependency update command by
skipping unnecessary downloading and loading of index files that have already
been downloaded and loaded
I believe this would close refs #9865
Signed-off-by: Jeff van Dam <jeff.van.dam@est.tech>
Tests are being run twice in CI. Once with code coverage being
report and once without. Tests only need to be run once.
When Helm previously had testing in CircleCI it was the code
coverage tests so that was retained here.
Signed-off-by: Matt Farina <matt.farina@suse.com>
During the install process there was a place where an install
process could be stuck trying to write to a channel. This would
happen when a context had completed prior to performInstall
finishing. In a short running Helm Client this was not a problem.
But, for long running applications that use Helm as an SDK there
are problems where a memory leak ends up happening due to
goroutines never being able to complete.
This fix provides a means for performInstall to write to its
channel using the method already used to fix the upgrade
issue of the same kind.
Fixes#11805
Signed-off-by: Matt Farina <matt.farina@suse.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
* Fixes Readiness Check for statefulsets using partitioned rolling update.
Fixes#11773
This change updates readiness check in ready.go to correctly
account for statefulsets that are utilizing a partitioned upgrade.
These statefulsets only upgrade a subset of the managed pods with each call
to helm upgrade. This causes the upgrade to legitimately hit the condition where
sts.status.CurrentRevision != sts.Status.UpdateRevision which causes helm to mark
the upgrade has failed when in fact it is successful.
This change fixes that behavior to only check when partition is unspecified or 0.
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
* Adding a unit test to verify that partitioned rolling upgrade for a statefulset works.
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
---------
Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com>
Co-authored-by: Aman Nijhawan <anijhawan@yugabyte.com>
The GOARCH here is 386 not i386. This caused a slightly odd test
suite failure on that architecture:
--- FAIL: TestPlatformPrepareCommand (0.00s)
plugin_test.go:45: Expected arg="os-arch", got "linux-s390x"
plugin_test.go:64: Expected arg="os-arch", got "linux-s390x"
Signed-off-by: Dirk Müller <dirk@dmllr.de>
Go 1.20 introduced DNS/CNAME handling changes. This can cause an
IP address represented in hex, oct, etc to be looked up as DNS and
fail. This change introduces a mock DNS resolver.
Note, with the mock resolver, we don't need to use 0x7f000001 any
longer. Keeping because it was already there.
Signed-off-by: Matt Farina <matt.farina@suse.com>
At this time both Go 1.19 and 1.20 are supported. The version
specified in the go.mod file is the minimum version we expect Helm
to be compiled against. This is the oldest supported version to
support environments where others compile Helm. The Helm project
is using Go 1.20 to build Helm itself.
Updating to Go 1.19 also includes dealing with io/ioutil
deprecation and some additional linting issues around staticcheck.
All the staticcheck issues were in test files so linting was
skipped for those.
Signed-off-by: Matt Farina <matt.farina@suse.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
As the CRDs are installed before the capabilities are gathered, the
current call to invalidate the discovery client is premature and
expensive.
What actually is required is an invalidation of the REST mapper, as
otherwise the Helm install action may later on fail with a `resource
mapping not found` error. More specifically when the caller of the
action is making use of a persisting[1] `RESTClientGetter`.
Which is not something done by the Helm CLI (albeit it could, and this
would potentially save quite some resources?). But is a default
configuration offered by the Helm SDK via `kube.New` when a nil value
is provided as the `getter`.
[1]: https://github.com/kubernetes/cli-runtime/blob/v0.26.2/pkg/genericclioptions/config_flags.go#L118
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Add new CLI flag --fail-on-no-result for failing the helm
search when there is no result found. This works with:
1. helm search repo
2. helm search hub
Signed-off-by: Bhargav Ravuri <bhargav.ravuri@infracloud.io>
Mathias Neerup
Andrew Block
Matt Farina
Yann Soubeyrand
Matt Farina
Dominik Müller
Jeff van Dam
Joe Julian
Tom Wieczorek
dependabot[bot]
Tapas Kapadia
Aman Nijhawan
wujunwei
Dirk Müller
AdamKorcz
willzgli
Scott Rigby
Alex Petrov
Hidde Beydals
Bhargav Ravuri