feat(ci): workflow to lint and test charts

[tthvo]

Fixes #72

• Restructure chart directory
• Add CI jobs to lint and test helm releases. Test procedure includes:
  • Upgrade test (i.e. install version on target branch then try to upgrade to any new version by PR/push).
  • Helm test (i.e. one with annotation helm.sh/hook: test under charts/cryostat/templates/tests).

References:

• https://redhat-cop.github.io/ci/linting-testing-helm-charts.html
• https://github.com/helm/chart-testing

[tthvo]

https://redhat-cop.github.io/ci/linting-testing-helm-charts.html

The charts/*/ci/ Folder

This folder is for testing different values files during the CI process. These values merge with the chart’s values.yaml file and applied to ensure that different combinations of values still result in a successful chart installation across changes. You can create as many values files as you want under this folder using whatever filename you think is necessary to represent the test case. Here’s an example:

charts/my-chart/ci/nodeport-values.yaml
charts/my-chart/ci/pvc-values.yaml

Seems like we can add partial values.yaml (merged with default values) to configure test cases. What test cases do you think we should run? Right now, job only uses the default values.

[ebaron]

https://redhat-cop.github.io/ci/linting-testing-helm-charts.html

The charts/*/ci/ Folder
This folder is for testing different values files during the CI process. These values merge with the chart’s values.yaml file and applied to ensure that different combinations of values still result in a successful chart installation across changes. You can create as many values files as you want under this folder using whatever filename you think is necessary to represent the test case. Here’s an example:
charts/my-chart/ci/nodeport-values.yaml
charts/my-chart/ci/pvc-values.yaml

Seems like we can add partial values.yaml (merged with default values) to configure test cases. What test cases do you think we should run? Right now, job only uses the default values.

I think the most obvious one is minimal and non-minimal. Testing the different networking types could be useful, but I'm not sure if it would test any different code paths with the current test.

[tthvo]

I think the most obvious one is minimal and non-minimal. Testing the different networking types could be useful, but I'm not sure if it would test any different code paths with the current test.

Should this be a separate issue when the test is updated then?

[ebaron]

I think the most obvious one is minimal and non-minimal. Testing the different networking types could be useful, but I'm not sure if it would test any different code paths with the current test.

Should this be a separate issue when the test is updated then?

I'm fine with that. For now minimal & non-minimal seems good.

[tthvo]

Updated to include minimal and non-minimal test scenarios :))

One thing: Partial value files under charts/cryostat/ci/ must be named <anything>-values.yaml for the helm testing tool to pick up despite the guide says "whatever filename".

[ebaron]

Hey @tthvo, I noticed one small thing in the workflow file. Also do you have any test CI runs for this?

[tthvo]

Also do you have any test CI runs for this?

I think because it targets event pull_request so the workflow actually runs on this PR too.

https://github.com/cryostatio/cryostat-helm/actions/runs/5150101449/jobs/9273872792?pr=73

[tthvo]

This PR CI just failed testing once: https://github.com/cryostatio/cryostat-helm/actions/runs/5179579235/attempts/1 but passed later. Might be flanky at times...

[ebaron]

This PR CI just failed testing once: https://github.com/cryostatio/cryostat-helm/actions/runs/5179579235/attempts/1 but passed later. Might be flanky at times...

Oh right! So used to the pull_request_target ones with secrets. I'll take a look at the failure. Maybe it's a timeout we can extend somewhere.

[ebaron]

I reran the checks a few more times and never encountered a failure. Maybe something weird due to the PR. Let's merge this and deal with it if we see it happen again. Thanks @tthvo!