Set specific version tag lumigo-injector image as default in Helm chart

[mmanciop]

Every time a new tag (except for latest) is released for the injector image, use it to update the default in the Helm chart and publish a new Helm chart release.

[AkshayAwate]

Hi, @mmanciop before implementing want to discuss about the solution, can we keep tag: ""

injectorWebhook:
  lumigoInjector:
    image:
      repository: public.ecr.aws/lumigo/lumigo-autotrace
      tag: ""

whenever user wants to deploy with particular version they can pass as tag: "1.0.0" else latest tag will be used. i have tried with using tag: "1.0.0", image was able to pick tag like this:
LUMIGO_INJECTOR_IMAGE: public.ecr.aws/lumigo/lumigo-autotrace:1.0.0, should i make changes and raise PR ?

[mmanciop]

Thanks for the idea but no, we don't want to use latest as default in the chart. It leaves very inconsistent results in terms of which image will be used on which K8s node, and it would lead to horribly complex bugs to debug. Instead, we are going to always pin a specific version in the Helm chart, release a new Helm chart version when there is an image update, and teach the operator to auto-update itself (see #5).

The goal of this "unusual" way of doing things is that the version of the Helm chart and operator (same version always) tells us pretty much everything we need to know about injector image, and therefore tracers, etc. Much less to ask and check when supporting this way ;-)

[AkshayAwate]

@mmanciop ,Then we can remove default "latest" from here and keep it as
{{ .Values.injectorWebhook.lumigoInjector.image.repository }}:{{ .Values.injectorWebhook.lumigoInjector.image.tag }}. So will use specific tag, does this makes sense ?

[mmanciop]

That's pretty much the idea, but it should be done entirely in the build process, where a regularly-scheduled GitHub workflow checks what is the latest tag on the injector image, runs end-to-end tests, and then opens a PR against main to update. However, before getting to that, I want to improve the test coverage and automate the integration tests, because such advanced automation requires excellent, equally-automated quality assurance :-)

[AkshayAwate]

Yup, sounds good!