Ability to test with custom values file

[nvtkaszpir]

Feature request:
add an option to pass custom values file for helm, for example:

--helm-values-file custom.yaml

Right now using --helm-extra-args unfortunately is also passed to helm test command so adding --values custom.yaml ends with error because it renders helm test .... --values custom.yaml which returns error because -values is unknown option for helm test.

This means that --helm-extra-args is actually limited to common helm parameters.

[gofman8]

+1
Also need this functionality. As minimum to pass --set persistence.enabled=false for testing purpose in my local cluster.

[unguiculus]

Custom values files are already supported. See here: https://github.com/helm/charts/blob/master/test/README.md#providing-custom-test-values

[nvtkaszpir]

@unguiculus yes but this is is useful only to certain degree.

What I really want is to provide custom values file which is outside of the chart directory.
Example:

• helm chart has test vaules file named postman-values.yaml which contain vars so that test is executed against Postman public endpoint. This is needed to test if the init containers/tests are working as expected without needing to use real data
• CI system (let say jenkins) has a pipeline to run above helm chart with custom vaules file to provide real pre-production data so that we can actually test the helm chart with what we want in CI process itself.

This way we can catch errors in CI phase, and not in CD phase when code is deployed on pre-prod/prod.

The only workaround for now would be to alter CI pipeline to fetch chart locally, inject custom values files into ci directory in chart and run char tests.
So I think it would be just better to add a new parameter chart-testing instead of hacking pipeline itself.

[rimusz]

+1 for external values.yaml files

[MateusAmin]

I need to pass secrets locally and in CI. What methods are available to me?

[stefan-caraiman]

Any updates regarding this feature @unguiculus ?

[nvtkaszpir]

Another option would be to provide new command flag to select only specific values file from ci/ directory, so that instead of running all ci/*-values.yaml entries it would just run only the specific one.

This could fulfill also requirement described in the first comment of this issue.

Without it user must seek another external solutions to run limited test suite, for example when doing fast iterations I'm interested in testing only specific set of values.yaml, thus speeding up feedback loop during development. At the end I want to run all the tests to be sure other tests are not failing.

[flimzy]

I would really like an additional option to pass a simple --set to helm install. My use case is specifying the image tag to fetch for the test in a CI pipeline. My current approach is to modify the ci/test-values.yaml file to replace the image tag value, before calling ct, but this seems quite cumbersome. Using --helm-extra-args has the same limitation for me as mentioned above: it's not passed only to helm install.

[smlx]

IMO variable values are easy enough to achieve by using a templated values file like this in a CI pipeline:

envsubst < ci/test-values.yaml.tpl > ci/test-values.yaml

It seems difficult to cleanly add command line options for extra args because there may be multiple *-values.yaml files, each of which is used in a separate test run. How does ct know which one to add the --set flags to? All of them?

[flimzy]

IMO variable values are easy enough to achieve by using a templated values file like this in a CI pipeline:

That's "easy", but messy. It means extra steps have to be taken to run the script locally (so you don't accidentally commit a substituted file, for example).

It seems difficult to cleanly add command line options for extra args because there may be multiple *-values.yaml files, each of which is used in a separate test run. How does ct know which one to add the --set flags to? All of them?

Off the cuff: Either apply it to all of them, or only specify a single *-valyes.yaml file at a time.

For the case of an image tag, applying to all of them is probably the most common requirement. When it's not, specifying only a single yaml file at a time probably makes sense.