* add output to get debug info on linter failing
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
* trap cases where the YAML indent is incorrect.
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
A fix introduced in #8631 caused a bug in Windows builds due to
a type difference between POSIX and Windows environments. This
change corrects that problem and provides a code comment to warn
others.
Signed-off-by: Matt Farina <matt@mattfarina.com>
When the engine stored templates in the map the keys were generated
based on path and not filepath. filepath was being used in the linter
when retrieving content from the keys. On Windows the keys ended up
being different.
This change is to use path joins to create the lookup key. Since the
name path was used in the code it needed to be changed in order to
import the package.
Tests already exist and were failing on windows. This got in because
CI is not run on Windows.
Closes#6418
Signed-off-by: Matt Farina <matt@mattfarina.com>
With the release of go 1.15, the test-suite doesn't pass as `go test` got
a new warning for improper `string(x)` usage.
https://golang.org/doc/go1.15#vet
$ make test-unit
# helm.sh/helm/v3/pkg/release
pkg/release/mock.go:56:27: conversion from int to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)
[snip]
make: *** [Makefile:82: test-unit] Error 2
This patch changes ensures we are utilizing `fmt.Sprint` instead as
recommended.
Signed-off-by: Morten Linderud <morten@linderud.pw>
Have update the Common Labels template in the starter chart so that the
value for the `app.kubernetes.io/version` is set to the same value as
the image tag used in the deployment.
Signed-off-by: Thomas O'Donnell <andy.tom@gmail.com>
When #8156 was merged it had the side effect that all hooks were
run all the time. All the hooks were put in the flow of the
content rendered and sent to Kubernetes on every command.
For example, if you ran the following 2 commands the test hooks
would run:
helm create foo
helm install foo ./foo
This should not run any hooks. But, the generated test hook is run.
The change in this commit moves the writing of the hooks to output
or disk back into the template command rather than in a private
function within the actions. This is where it was for v3.2.
One side effect is that post renderers will not work on hooks. This
was the case in v3.2. Since this bug is blocking the release of v3.3.0
it is being rolled back. A refactor effort is underway for this section
of code. post renderer for hooks should be added back as part of that
work. Since post renderer hooks did not make it into a release it
is ok to roll it back for now.
There is code in the cmd/helm package that has been duplicated from
pkg/action. This is a temporary measure to fix the immediate bug
with plans to correct the situation as part of a refactor
of renderResources.
Signed-off-by: Matt Farina <matt@mattfarina.com>
Two things changed in this commit...
1. The Build behavior was restored and the change only impacts
Update. This is a more minimal functionality change thats
a more secure behavior
2. Cleanup from Josh's feedback on the PR to create a const
and comment changes
Signed-off-by: Matt Farina <matt@mattfarina.com>
If a repository was not know to helm (e.g. added using helm repo add)
then Helm would use the range set in the depenencies as the version
in the lock file. Lock files should not have ranges since they are
locked to versions.
Helm did this because the version information for repositories was
not know to Helm. This change fixes that by making the repository
and chart information known to Helm so it can resolve the versions.
Closes#8449
Signed-off-by: Matt Farina <matt@mattfarina.com>
* fix(sdk): Polish the downloader/manager package error return
Close#8471
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* Modify the repositories validation function `resloveRepoNames` and add a
unit test.
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* Remove wrong commit
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
If two `helm upgrade`s are executed at the exact same time, then one of
the invocations will fail with "already exists".
If one `helm upgrade` is executed and a second one is started while the
first is in `pending-upgrade`, then the second invocation will create a
new release. Effectively, two helm invocations will simultaneously
change the state of Kubernetes resources -- which is scary -- then two
releases will be in `deployed` state -- which can cause other issues.
This commit fixes the corrupted storage problem, by introducting a poor
person's lock. If the last release is in a pending state, then helm will
abort. If the last release is in a pending state, due to a previously
killed helm, then the user is expected to do `helm rollback`.
Closes#7274
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>