Open banjoh opened 5 months ago
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
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
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
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
Output
Describe the feature
version | appVersion
is in between two version ranges.appVersion
>=1.2.x
. We do something similar with our database analysersImplementations considerations
helmAnalyze
analyserDescribe alternatives you've considered
Using a combination of jsonCompare and textAnalyzer to check some fields