* Introduce docker config.json parameter for kubectl
* Use docker config.json parameter for helm
* Export definition of kube secret parameters
* fix username password existence check
* choose more fitting name for secret spec
* Adopt review suggestions
Co-authored-by: Roland Stengel <r.stengel@sap.com>
* new 'keepFailedDeployments' parameter which removes the --atomic flag
* Update resources/metadata/kubernetesdeploy.yaml
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* go generate
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
* Extends kubernetesDeploy step to support Helm 3
Currently, the kubernetesDeploy step has no support to Helm 3 due to the fact that:
- the initialization command used works only for Helm 2
- the image used when running the helm CLI is based on Helm 2
The need for Helm 3 support comes from the fact that Helm 3 introduces major architectural changes,
more specifically, the removal of its server-side agent called Tiller - thus, being incompatible with
one another.
This commit adds this support by introducing a new configuration field (helmVersion).
By default, its values is set to 2 (Helm 2) to avoid breaking any existing functionalities.
* Use deployTool field to decide between Helm 2 or 3
* Remove helm init and replace wait for atomic in v3
* Update cmd/kubernetesDeploy.go
Nice catch!
Co-Authored-By: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
* Add documentation for kubernetesDeploy step
* Add helm3 example for kubernetesDeploy step using mandatory fields
* Add new line at the end of kubernetesDeploy documentation
* Link kubernetesDeploy step with docs generator
* Add possible values for deployTool in kubernetesDeploy
* dummy change
* Revert "dummy change"
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Co-authored-by: Christopher Fenner <26137398+CCFenner@users.noreply.github.com>
I don't understand why there should be a two dimensional array.
When dealing with envs we have normally a list containing entries like
[]string{"DEBUG=true", "HOME=/home/me"}
Having two dimensional env arrays would mean to have several alternate
environment in the tests at the same time. Don't think there is a need
for that.
