Analysing helm releases

[banjoh]

Describe the rationale for the suggested feature.

Now that we collect helm release information, the natural step forward is using this information in analysers where we can have preflight checks for example.

Here is an example of collected release info including the spec

Spec

spec:
  collectors:
  - helm:
      collectValues: true

Output

[
	{
		"releaseName": "foo",
		"chart": "foo",
		"chartVersion": "0.2.0",
		"appVersion": "1.18.0",
		"namespace": "default",
		"releaseHistory": [
			{
				"revision": "1",
				"date": "2024-03-13 11:41:04.668197 +0000 UTC",
				"status": "superseded",
				"values": {
					"imagePullSecrets": [],
					"nameOverride": "",
					"replicaCount": 1
				}
			},
			{
				"revision": "2",
				"date": "2024-03-13 11:41:21.361687 +0000 UTC",
				"status": "deployed",
				"values": {
					"imagePullSecrets": [],
					"nameOverride": "new-added-name",
					"replicaCount": 1
				}
			}
		]
	},
	{
		"releaseName": "tree",
		"chart": "tree",
		"chartVersion": "0.1.0",
		"appVersion": "1.16.0",
		"namespace": "default",
		"releaseHistory": [
			{
				"revision": "1",
				"date": "2024-03-13 11:41:53.469804 +0000 UTC",
				"status": "superseded",
				"values": {
					"fullnameOverride": "",
					"image": {
						"pullPolicy": "IfNotPresent",
						"repository": "nginx",
						"tag": ""
					}
				}
			},
			{
				"revision": "2",
				"date": "2024-03-13 11:42:13.129961 +0000 UTC",
				"status": "deployed",
				"values": {
					"fullnameOverride": "somethingelse",
					"image": {
						"pullPolicy": "IfNotPresent",
						"repository": "nginx",
						"tag": ""
					}
				}
			}
		]
	}
]

Describe the feature

• Version matching analysis
  • version | appVersion is in between two version ranges.
  • Exact match of versions
  • major|minor|patch version match e.g appVersion >= 1.2.x. We do something similar with our database analysers
• Status of an install i.e "status" == "deployed" etc

Implementations considerations

• Creating a helmAnalyze analyser
• Possibly extend jsonCompare to allow more ways of performing comparisons. Pay attention to the last outcome which has a keyword to convert to semver.

    - jsonCompare:
        checkName: Compare JSON Example
        fileName: example.json
        jsonPath: '{[?(@.releaseName == "foo")].appVersion}'
        outcomes:
          - pass:
              when: "== 1.18.0"
              message: Found 1.18.0
          - pass:
              when: "> 1.17.0"
              message: Greater than 1.17.0
          - pass:
              when: ">= 1.17.9"
              message: Greater or equal 1.17.9
          - pass:
              when: "semver > 1.17.x"
              message: Convert to semver then compare

Describe alternatives you've considered

Using a combination of jsonCompare and textAnalyzer to check some fields

[CharlesB2]

Also instead of releaseName, we'd like to filter on chart. Makes sense since the release can be named after customer's will, which isn't the case for chart

[banjoh]

Also instead of releaseName, we'd like to filter on chart. Makes sense since the release can be named after customer's will, which isn't the case for chart

I think you should be able to select a release using this spec

    - jsonCompare:
        checkName: Compare JSON Example
        fileName: helm/default.json
        jsonPath: '{[?(@.releaseName == "foo")].appVersion}'
        value: "1.18.0"
        outcomes:
          - fail:
              when: "false"
              message: Version is not 1.18.0
          - pass:
              when: "true"
              message: Version found

[CharlesB2]

As requested, use case is to be able to get helm version of the app's latest deployed version. Then, in an analyzer, make versions comparison to disallow certain upgrade paths, for example the outcome would be a failure if current deployed version is lower than a defined version.
This would have allowed us to provide similar to the "Prevent this release from being skipped during upgrades" feature in KOTS
This has now lower priority since we implemented this functionality in a pre-upgrade job, but I think better helm collector/analyzer would be beneficial