Add support for testing charts with post renderer

[paulczar]

This PR adds two new features that allow for testing of charts that have/require the use of post renderer hooks

1. Allow the user to provide a setup script that can be run to install additional tools or packages like ytt or kustomize

2. Allow the user to provide a default path to look for post-renderer hooks. There is an assumption that post-renderer hooks will be in a consistent (relative to the chart) location for charts, it would be overwhelming to try and support different paths for different charts.

Signed-off-by: Paul Czarkowski [email protected]

What this PR does / why we need it:

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #

Special notes for your reviewer:

[unguiculus]

Thanks @paulczar for adding this. I have some concerns regarding the way it is implemented, though.

1. I don't think chart-testing should handle the installation of additional software. Using a post-renderer is an advanced feature. If someone wants to use it they should take care of installing required software upfront, e. g. by creating a custom Docker image.

2. chart-testing is designed such that it automatically runs across any charts that may have changed in the repo. You may want to use a post-renderer for some but not all of them. Using a CLI flag does not consider this. That's why we have values files for testing in a chart's ci folder. We could come up with a similar naming convention for post-renderers and add them to this directory as well. chart-testing would then run any combination of values files and post-renderers it finds for a chart.

[scottrigby]

I also think a good place for that would be the /ci dir. Same as where you put glob pattern '*-values.yaml' files ('post-renderer.sh')?

[paulczar]

1. Makes sense, I was hesitant adding the setup-script as it was.

2. Ahhh yeah my thought was that the owner of the charts repo would decide on a convention for post-renderer hooks and any charts that needs a post-renderer would follow that convention, hence the cli option. So maybe what I should do is have it would look for ./ci/ct-chart-config.yaml where we could allow the chart to specify some config settings, the first of which being post-renderer-path:. If the cli option --post-renderer is true it would then read that config setting.

[unguiculus]

@paulczar Maybe just have a convention similar to what we have for values file, e. g. *-post-renderer*?

[scottrigby]

Agree a glob pattern for this would be good to test combinations as we do now with '*-values.yaml' files

[joejulian]

can this already be done with helm-extra-args?

[github-actions[bot]]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 10 days with no activity.