New users to helm don't always run `helm init` (e.g. if their cluster
already has helm installed). The user's initial interaction with any of
helm's repository commands (e.g. `helm repo list`) will then be an error
message due to a missing repositories.yaml in their local config.
Give the user a little hint about how to fix the error without them having
to hunt through the man/help pages.
* first staging
* Filled out RBAC and TLS
* Finished draft.
* smoothing
* gRPC endpoint tooling moved up and cleaned
* updating install.md
* addressed comments; will continue expanding and iterating
There was an issue with functions not being able to pass to each
other. For example, the output of regex not being able to be
passed to first or last due to type issues. This update fixes
those problems
When 'helm package --app-version foo' is run, this will
set the AppVersion field to 'foo' in the packaged chart.
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
Lets us build a subset of the targets while still using build-cross
To build for multiple linux archs:
TARGETS="linux/amd64 linux/386" make clean build-cross dist APP=helm VERSION=v25.12.2
* support output-dir when running 'helm template'
* add --output-dir to documentation
* when writing to file, dont add additional document
* trigger another ci build. make test-unit works for me
* dont write blank files
* return err instead of panic
k8s client-go closes the ready channel that's passed in (see https://github.com/kubernetes/client-go/blob/master/tools/portforward/portforward.go#L171) This means that Tunnel's Close will always panic, as the client-go library will have closed then channel. This isn't reproducible unless helm.Client is externally, as the helm cli runner doesn't actually invoke Close.
* docs(helm): Document how to update a release idempotently
To use the same command when installing and upgrading a release, using helm upgrade with '--install' works.
Closes#3134
* Upgrade instead of update