feat(rapid-response,sysdig-deploy): Verify that image.tag is a string

[dark-vex]

Signed-off-by: Daniele De Lorenzi daniele.delorenzi@sysdig.com

What this PR does / why we need it:

We give the possibility to our customers to customise Rapid Response image for adding more tools inside it and therefore they will build the image to be hosted on a their repo with a their own image tag.

When specifying rapidResponse.image.tag to a value like 1, 1.0 or 20161216 this gets converted by helm into float64 instead of string and causes to have inside daemonset.yaml manifest a bad image: value, ex:

# Image tag set to 2 inside `values.yaml`
 ➜ helm template -n sysdig-test ./sysdig-charts/charts/rapid-response -f ./sysdig-charts/values-rapid-test.yaml | grep image
          image: quay.io/sysdig/rapid-response-host-component:%!s(float64=2)
          imagePullPolicy: IfNotPresent


# Image tag set to 1.0 inside `values.yaml`
 ➜ helm template -n sysdig-test ./sysdig-charts/charts/rapid-response -f ./sysdig-charts/values-rapid-test.yaml | grep image
          image: quay.io/sysdig/rapid-response-host-component:%!s(float64=1)
          imagePullPolicy: IfNotPresent

This seems to be a known issue on helm, see:
helm/helm#1707
helm/helm#11130
helm/helm#8978

I have updated the helper for verifying that rapidResponse.image.tag is a string and I have updated the values.yaml comments for image.tag parameter. A unit test for this scenario has been added as well.

Potentially this issue is present in all our charts, shall we need to extend this change to all of them? even though usually customer don't customise the other components image they can still upload our image on a their private registry and tag them differently. What are your though on this? @aroberts87 @ironashram @lilx1ao

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Title of the PR starts with type and scope, (e.g. feat(agent,node-analyzer,sysdig-deploy):)
• Chart Version bumped for the respective charts
• Variables are documented in the README.md (or README.tpl in some charts)
• Check GithubAction checks (like lint) to avoid merge-check stoppers
• All test files are added in the tests folder of their respective chart and have a "_test" suffix

Check Contribution guidelines in README.md for more insight.

[legobrick]

lgtm

[lilx1ao]

good to know! thank u