chore: use appVersion from chart instead of tag from values yaml

[blumamir]

The PR introduces the following changes:

• use the appVersion entry in Chart.yaml to define the version of odigos, instead of the image.tag in values.yaml.
• add lint workflow on each pull_request
• align chart version with odigos version
• add ci workflow to create release PR on odigos release
• add ci workflow to tag the repo when release pr is merged

[esara]

In general, you are switching the concept of decoupling the helm chart from the odigos version (allowing the same chart to deploy different versions) to a concept of tightly coupling the helm chart version with the odigos version.

An upside is that you force helm chart update to get a newer version of crds, which I am afraid is still a manual process and needs to be taken care of, before the new helm chart is released.

This change makes the odigos version not configurable through helm values as a downside and it forces you to release a new helm chart, even if it does not change just to be able to deploy a newer odigos image

As you explained, you want to add automation to the odigos release process to create a PR for the helm-chart, lets only merge in this change, after the automation is in place (so we dont loose the functionality if being able to deploy the latest odigos version using helm)

[a5r0n]

maybe using the appVersion as the default if image.tag is not provided.
this way we can try out new versions of odigos without the need to wait for new chart release.

[esara]

maybe using the appVersion as the default if image.tag is not provided. this way we can try out new versions of odigos without the need to wait for new chart release.

that would a nice compromise, but in that case, I think we may loose the point (of tightly coupling the helm chart with the odigos version), if you can override the version, we may as well just keep the current chart, which ships with a default image tag, which can be overriden

[blumamir]

Thanks @a5r0n @esara ,

I will first introduce the automation to release new chart for each odigos version, and then make the change ofmigrating to appVersion.

There is no compatibility guarantee if you use a chart with a new version of odigos. The new version might need more RBAC roles, changes in CRDs etc. So I think it makes sense to couple the chart version with a specific odigos version.